From b83f2e2931a31f84aa1c59c4b14f08960df6d151 Mon Sep 17 00:00:00 2001 From: "QUALISYSTEMS\\nahum-t" Date: Wed, 9 Sep 2026 17:28:44 +0300 Subject: [PATCH] Tier 1 of the post-2026.1.0.52 sweep: Python 3.13, save-as-blueprint inputs, category validation Documents the three behavior-changing items that landed on 2026.1 after the 2026.1.0.52 pass (#18) and were not covered by #19-#22. Python 3 upgraded to 3.13.15 x64 (Trunk CS 189988/189997/189999, backported in CS 190003). This is the WINDOWS bundled slot only - the Docker ES image still builds Python 3.9.9, and so do the Linux VA and the from-script ES, so every page states the platform split rather than a blanket "CloudShell now uses 3.13". Python 2.7.18 is untouched. Also corrects setting-up-dev-env.md, which #23 had just updated to say the bundled version is 3.9.9 - true when it merged on Sep 6, wrong when the upgrade landed on Sep 8. Global inputs kept on save as blueprint, with the new KeepResourceGlobalInputsOnSaveAsBlueprint key (CS 189903/189905/189914). Default is true, which is a behavior change on upgrade: inputs that fronted a resource requirement used to be dropped and are now visible in the Reserve dialog and the blueprint editor. Documented as a customer-visible key on the Server (AppSettingVisibility.Customer, read by ServiceConfigSettingsLoader). Blueprint import now fails on a category missing from the target domain instead of silently dropping the association (CS 189942). The ExportBlueprint/ImportBlueprint page from #22 already stated this, so it needed no correction - only the release notes did. Co-Authored-By: Claude Opus 5 (1M context) --- .wordlist.txt | 1 + .../blueprint-workspace.md | 31 +++++++++++++++++++ .../getting-started-with-cp-dev.md | 2 +- .../getting-started-with-orch-scripts.md | 2 +- .../developing-shells/getting-started.md | 2 +- docs/devguide/setting-up-dev-env.md | 14 +++++++-- .../third-party-software.md | 7 +++-- docs/release-notes/behavior-change.md | 3 ++ docs/release-notes/whats-new.md | 22 +++++++++++++ 9 files changed, 77 insertions(+), 7 deletions(-) diff --git a/.wordlist.txt b/.wordlist.txt index 634bdb8c90..ea931cfdde 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -1656,3 +1656,4 @@ setFeatureCompatibilityVersion featureCompatibilityVersion Telnet sharded +CPython diff --git a/docs/admin/setting-up-cloudshell/cloudshell-configuration-options/customer-configuration-keys-repository/blueprint-workspace.md b/docs/admin/setting-up-cloudshell/cloudshell-configuration-options/customer-configuration-keys-repository/blueprint-workspace.md index 1bd11b8a53..ca03980015 100644 --- a/docs/admin/setting-up-cloudshell/cloudshell-configuration-options/customer-configuration-keys-repository/blueprint-workspace.md +++ b/docs/admin/setting-up-cloudshell/cloudshell-configuration-options/customer-configuration-keys-repository/blueprint-workspace.md @@ -274,6 +274,37 @@ sidebar_position: 6 +## Keep global inputs when saving a sandbox as a blueprint +When saving a sandbox as a blueprint, keep global inputs that were linked to a resource requirement, even when that resource is saved as a concrete resource. Set to `False` to drop them instead, restoring the behavior of earlier versions. + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Key``
Possible valuesTrue/False
Where to add/change`customer.config` CloudShell Server installation directory
Default valueTrue
Affected CloudShell ComponentCloudShell Server
Version2026.1 and above
+ ## Set the route grouping policy diff --git a/docs/devguide/develop-custom-cloud-provider-shells/getting-started-with-cp-dev.md b/docs/devguide/develop-custom-cloud-provider-shells/getting-started-with-cp-dev.md index 5578595646..1733a247b4 100644 --- a/docs/devguide/develop-custom-cloud-provider-shells/getting-started-with-cp-dev.md +++ b/docs/devguide/develop-custom-cloud-provider-shells/getting-started-with-cp-dev.md @@ -49,7 +49,7 @@ As of version 9.0, CloudShell supports the ability to define custom cloud provid CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following: - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv). - - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. + - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.13.15 — the versions bundled with CloudShell 2026.1 on Windows; use 3.9.9 to match an earlier version or a Linux Execution Server — and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. ::: - **IDE/Text Editor**: Your preferred IDE editor. We recommend using PyCharm (which offers a free community edition) because of the tooling we’ve already created for that IDE, including a CloudShell developer plugin. diff --git a/docs/devguide/develop-orch-scripts/getting-started-with-orch-scripts.md b/docs/devguide/develop-orch-scripts/getting-started-with-orch-scripts.md index 8af148a3b9..c9c26399e6 100644 --- a/docs/devguide/develop-orch-scripts/getting-started-with-orch-scripts.md +++ b/docs/devguide/develop-orch-scripts/getting-started-with-orch-scripts.md @@ -18,7 +18,7 @@ Orchestration scripts can enable automating sandbox workflows. You can use orche CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following: - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv). - - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. + - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.13.15 — the versions bundled with CloudShell 2026.1 on Windows; use 3.9.9 to match an earlier version or a Linux Execution Server — and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. ::: - **IDE/Text Editor:** Your preferred IDE editor. We recommend using PyCharm (which offers a free community edition) because of the tooling we’ve already created for that IDE, including a CloudShell developer plugin. diff --git a/docs/devguide/developing-shells/getting-started.md b/docs/devguide/developing-shells/getting-started.md index cb291ea857..21bd348472 100644 --- a/docs/devguide/developing-shells/getting-started.md +++ b/docs/devguide/developing-shells/getting-started.md @@ -35,7 +35,7 @@ To learn more about the different versions of the Shells used by CloudShell and CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following: - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv). - - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. + - [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.13.15 — the versions bundled with CloudShell 2026.1 on Windows; use 3.9.9 to match an earlier version or a Linux Execution Server — and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. ::: - **IDE/Text Editor**: Your preferred IDE editor. We recommend using PyCharm (which offers a free community edition) because of the tooling we’ve already created for that IDE, including a CloudShell developer plugin. diff --git a/docs/devguide/setting-up-dev-env.md b/docs/devguide/setting-up-dev-env.md index 0299cad8a6..508bbe8786 100644 --- a/docs/devguide/setting-up-dev-env.md +++ b/docs/devguide/setting-up-dev-env.md @@ -12,12 +12,22 @@ In this section we’ll go over the recommended steps for setting up a developme Download and install a current 64-bit version of Python 3 from the [official website](https://www.python.org/downloads/). Shellfoundry, CloudShell's shell development CLI, supports Python 3.9–3.13 (Python 3.13 requires shellfoundry 1.2.29 or later). -Note that shells and scripts *execute* on the Python versions bundled with CloudShell itself — currently Python 3.9.9 (and Python 2.7.18 for legacy shells). Your driver code and its requirements.txt must stay compatible with the bundled version your CloudShell deployment runs, even if your dev machine uses a newer Python. +Note that shells and scripts *execute* on the Python versions bundled with CloudShell itself, not on your dev machine's Python. As of CloudShell 2026.1 that is: + +| Execution Server | Bundled Python 3 | Bundled Python 2 | +| --- | --- | --- | +| Windows | 3.13.15 (64-bit) | 2.7.18 | +| Linux virtual appliance / from script | 3.9.9 | 2.7.18 | +| Docker Execution Server image | 3.9.9 | 2.7.18 | + +Your driver code and its `requirements.txt` must stay compatible with the bundled version your CloudShell deployment runs. If your shells run on both Windows and Linux Execution Servers, they must work on both Python 3.9 and 3.13 — mind the standard-library removals in between, such as the `collections` aliases for the abstract base classes (`collections.Sequence`), which were removed in 3.10 in favor of `collections.abc`. + +Earlier CloudShell versions bundle Python 3.9.9 on Windows as well; see [Behavior Changes](../release-notes/behavior-change.md). :::tip CloudShell components such as Quali Server and the execution servers come with their own Python installation folders. Making changes to these folders may cause unexpected behavior in CloudShell. Therefore, if you plan on doing dev work on a machine that has CloudShell components installed, we recommend doing one of the following: - Configuring dedicated virtual environments for your projects out of these base installations. To do this in PyCharm, see [https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html](https://www.jetbrains.com/help/pycharm/creating-virtual-environment.html). To do this via CLI, see [https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv](https://docs.python-guide.org/dev/virtualenvs/#lower-level-virtualenv). -- [Downloading separate installers](https://www.python.org/downloads/) for Python 2.7.18 and 3.9.9 and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. +- [Downloading separate installers](https://www.python.org/downloads/) for the bundled versions listed above and using these as global installations (by setting the installation folders in the machine’s PATH system variable) for any dev work being done. ::: ## Pick and install an IDE diff --git a/docs/install-configure/cs-system-requirements/third-party-software.md b/docs/install-configure/cs-system-requirements/third-party-software.md index ea438441cf..9967be5551 100644 --- a/docs/install-configure/cs-system-requirements/third-party-software.md +++ b/docs/install-configure/cs-system-requirements/third-party-software.md @@ -20,8 +20,8 @@ If any of the below 3rd Party components are missing from your computer, the Clo - Microsoft Visual C++ 14.0 or greater - Microsoft Windows Installer 4.5 - Node.js 24.14.0 LTS (64-bit only) -- pip 21.2.4 and up for Python 3.7 and pip 19.2.3 for Python 2.7.18 -- Python Python 2.7.18 and 3.9.9 +- pip 21.2.4 and up for Python 3 and pip 19.2.3 for Python 2.7.18 +- Python 2.7.18 and 3.13.15 (64-bit) - RabbitMQ 3.12.0 (installed as part of the Quali Server installation) - Erlang 26.2.3 - VCTools++ (For all users. Required for compiling Python dependencies) @@ -33,10 +33,13 @@ The following bundled prerequisites were updated: - **Node.js**: 22.15.0 → 24.14.0 LTS (used by Sandbox API Gateway and Server Proxy) - **Erlang OTP**: 25.2.3 → 26.2.3 (RabbitMQ prerequisite) - **MongoDB**: 6.0.4 → 7.0.30 +- **Python 3**: 3.9.9 (32-bit) → 3.13.15 (64-bit). The bundled Python 2.7.18 is unchanged. This applies to the Python bundled with CloudShell on Windows; Linux Execution Servers and the Docker Execution Server image still provide Python 3.9.9. The CloudShell installer handles these upgrades automatically. Standalone MongoDB deployments must be upgraded manually to 7.0 before upgrading CloudShell. **Breaking change**: Node.js 24 dropped 32-bit (x86) Windows support. The x86 Node.js prerequisite has been removed from the CloudShell installer. Only 64-bit Windows is supported. + +**Driver compatibility**: shells and scripts running on a Windows Execution Server now execute on Python 3.13. See [Behavior Changes](../../release-notes/behavior-change.md). ::: ## Optional diff --git a/docs/release-notes/behavior-change.md b/docs/release-notes/behavior-change.md index a5ede02df2..9327ecb526 100644 --- a/docs/release-notes/behavior-change.md +++ b/docs/release-notes/behavior-change.md @@ -17,6 +17,9 @@ The following list includes changes in behavior introduced into CloudShell by ve | Editing an active maintenance window | When editing an **active** maintenance window, an end time that is not in the future (at or before the current time) is now rejected — including the former within-grace "ends immediately" behavior. To end an active maintenance window immediately, use the **Stop** action. | 2026.1 | | Custom PyPI repository applied at setup | The `RequirementsRepository`, `RequirementsTrustedHost`, and `RequirementsExtraRepository` keys are now honored during Execution Server setup and default-environment bootstrap, not only at driver-command time. Deployments that set a custom PyPI index will use it earlier; there is no change when no custom repository is configured. | 2026.1 | | Portal session survives app-pool recycle | The Portal now rebuilds a user's session from the sign-in cookie after an application-pool recycle instead of forcing a re-login, and a transient CloudShell Server `MessageSecurityException` no longer signs users out. Controlled by the `EnableSessionRehydration` app setting (default `true`); set it to `false` to restore the previous force-logout behavior. | 2026.1 | +| Bundled Python 3 version (Windows) | The Python 3 interpreter bundled with CloudShell on Windows was upgraded from CPython 3.9.9 (32-bit) to 3.13.15 (64-bit). Drivers and scripts running on a Windows Execution Server now execute on Python 3.13, so driver code and `requirements.txt` must be valid on 3.13 — the most common breakage is the `collections` ABC aliases (for example `collections.Sequence`), removed in Python 3.10 in favor of `collections.abc`. Python 2.7.18 is unchanged. Linux Execution Servers, the Linux virtual appliance and the Docker Execution Server image still provide Python 3.9.9, so shells running on both platforms must stay compatible with 3.9 and 3.13. | 2026.1 | +| Global inputs kept on save as blueprint | Saving a sandbox as a blueprint now keeps global inputs that were linked to a resource requirement, where previously they were dropped. Where the requirement is carried over to the saved blueprint the input is linked back to it; where the resource was pinned down the input is kept as a plain value linked to nothing. These inputs are visible in the Reserve dialog and in the blueprint editor. Set `KeepResourceGlobalInputsOnSaveAsBlueprint=false` in `customer.config` to drop them instead and restore the previous behavior. | 2026.1 | +| Blueprint import fails on a missing category | Importing a blueprint that references a category that does not exist in the target domain now fails the import with an explicit error. Previously the blueprint imported successfully and the category association was silently dropped. Create the missing categories in the target domain before importing, or remove the category references from the blueprint. | 2026.1 | | Erlang version | To accommodate the upgraded RabbitMQ version (3.12.0) explained in [Breaking Changes](#breaking-changes), Erlang will be upgraded to newer version 25.2.3. This version is the maximum supported Erlang for RabbitMQ 3.12.0. Environment variables will be updated accordingly to suite the new Erlang version. | 2023.2 EA | | Python versions | In 2022.1, we updated CloudShell's Python versions as follows: This may cause unexpected behavior if your automation is constrained to use specific Python versions. | 2022.1 EA | | API tokens | To increase security and to allow time-based token access to the system, CloudShell 2022.1 generates a time-based token for our product APIs. In previous versions, only some of the APIs used such a system. By default, the token validity period is 5 hours. Notes: | 2022.1 EA | diff --git a/docs/release-notes/whats-new.md b/docs/release-notes/whats-new.md index ee294812d4..f7c7708f2c 100644 --- a/docs/release-notes/whats-new.md +++ b/docs/release-notes/whats-new.md @@ -60,6 +60,28 @@ New TestShell API method that returns the list of reservations (current and hist ### Improved Abstract Resource Resolution Diagnostics When a blueprint reservation fails due to unresolvable abstract resources or route conflicts, the error message now includes detailed diagnostics — showing which resources could not be resolved, which routes failed, and the specific conflicts that prevented resolution. +### Bundled Python 3 Upgraded to 3.13 (Windows) +The Python 3 interpreter bundled with CloudShell on Windows has been upgraded from CPython 3.9.9 (32-bit) to **3.13.15 (64-bit)**. Shell drivers and orchestration scripts that run on a Windows Execution Server now execute on Python 3.13. The bundled Python 2.7.18 slot is unchanged and still ships, so legacy Python 2 shells are unaffected. + +:::warning Driver compatibility +Driver code and its `requirements.txt` must be valid on Python 3.13. Modules and aliases removed between 3.9 and 3.13 are the most common cause of breakage — for example the `collections` aliases for the abstract base classes (`collections.Sequence`), which were removed in Python 3.10 and must be imported from `collections.abc` instead. Test your shells against Python 3.13 before upgrading. +::: + +:::note Linux and Docker Execution Servers still use Python 3.9.9 +This upgrade covers the Python bundled with CloudShell on Windows. Linux Execution Servers — including the Linux virtual appliance and the Docker Execution Server image — still provide Python 3.9.9. If your shells run on both Windows and Linux Execution Servers, keep driver code compatible with both 3.9 and 3.13. +::: + +### Global Inputs Kept When Saving a Sandbox as a Blueprint +Saving a sandbox as a blueprint now keeps global inputs that were linked to a resource requirement, instead of dropping them: + +- Where the requirement is carried over to the saved blueprint (the work order flow), the kept global input is linked back to that requirement, so it still drives something. +- Where the resource was pinned down as a concrete resource, there is nothing left to link to, so the input is kept as a plain value. + +Controlled by the `KeepResourceGlobalInputsOnSaveAsBlueprint` key (default `true`). Set it to `false` to drop these inputs instead, which restores the previous behavior. + +### Blueprint Import Validates Categories +Importing a blueprint that references a category that does not exist in the target domain now fails the import with an explicit error, instead of importing the blueprint and silently dropping the category association. This completes the import validation set — family, model, attribute, script, driver and resource references already failed the import when missing. + ### Bug Fixes - Fixed an issue where App deployment could retry unnecessarily on certain internal errors instead of failing fast with clear diagnostics. - Fixed SSO (SAML) users being bounced to the login page in a loop, instead of seeing the maintenance page, when signing in during a maintenance window. Aborted logins no longer leave a half-authenticated session.