From bedf1baa8f1479b2c091e549a5986650fa72322d Mon Sep 17 00:00:00 2001 From: "QUALISYSTEMS\\nahum-t" Date: Mon, 27 Jul 2026 11:50:29 +0300 Subject: [PATCH 1/2] Track 3 Tier 2: flesh out partial how-tos - Maintenance Window by Domain: document the real mechanism (a window scoped to a domain via its domain association, not a named domain setting) - New: Managing Resource Application Links (the four TestShell API methods) - MongoDB 6.0->7.0 upgrade guidance (+ Node 24 / Erlang 26 notes) - Smart Route Creation with L1 Priority: expand into a how-to - Add an L1-port filter entry to the Find Resources articles Grounded in the server code and integration tests; adversarially verified. Co-Authored-By: Claude Opus 4.8 (1M context) --- .wordlist.txt | 4 + .../maintenance-window.md | 31 +++++-- .../assembly-lab/index.md | 30 +++++++ .../manage-resource-application-links.md | 85 ++++++++++++++++++ .../how-to-upgrade-4.2-6.md | 86 ++++++++++++++++++- .../select-database-type/index.md | 4 +- .../resources/find-resources.md | 3 + .../resources/find-resources.md | 3 + 8 files changed, 236 insertions(+), 10 deletions(-) create mode 100644 docs/api-guide/shell-dev-blueprint-design-api/manage-resource-application-links.md diff --git a/.wordlist.txt b/.wordlist.txt index 431bf53482..2013cb65ba 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -1648,3 +1648,7 @@ undeploys paginated pagination UndeployApps +FCV +setFeatureCompatibilityVersion +featureCompatibilityVersion +Telnet diff --git a/docs/admin/cloudshell-manage-dashboard/maintenance-window.md b/docs/admin/cloudshell-manage-dashboard/maintenance-window.md index cdd5a8f3ec..5317d60069 100644 --- a/docs/admin/cloudshell-manage-dashboard/maintenance-window.md +++ b/docs/admin/cloudshell-manage-dashboard/maintenance-window.md @@ -69,19 +69,38 @@ The maintenance window's areas are arranged as follows: *New in CloudShell 2026.1* -In addition to the system-wide maintenance window described above, administrators can define maintenance windows scoped to individual domains. During a domain-scoped maintenance window, sandbox creation and modifications are restricted in that domain, while other domains continue operating normally. +In addition to the system-wide maintenance window described above, administrators can define maintenance windows scoped to individual domains. During a domain-scoped maintenance window, the same restrictions described in [About the maintenance window](#about-the-maintenance-window) (login, sandbox reservation, and automation) apply only to the selected domain. Other domains keep operating normally. -This is useful for planned infrastructure maintenance, upgrades, or other activities that require temporarily restricting access to specific lab resources without affecting other teams. +This is useful for planned infrastructure maintenance, upgrades, or other activities that require temporarily restricting access in a specific domain without affecting other teams. + +A domain-scoped maintenance window uses exactly the same schedule, notification duration, and messages (**Message on Login**, **Notification Message**, **Error on Reserve**, and **Warning on Reserve**) as a system-wide window. The only difference is the domain the window applies to: + +- A window associated with the **Global** domain is system-wide and applies to all domains (this is the default for windows created from the **Global** domain, as described in [Setting a maintenance window](#setting-a-maintenance-window)). +- A window associated with a specific domain applies only to that domain. + +Each domain can have at most one active or planned maintenance window at a time, independently of other domains. ### Configuring a Domain Maintenance Window -To set a maintenance window for a specific domain, use the API: +A domain maintenance window is configured the same way as a system-wide one — by adding a maintenance window and associating it with the target domain, rather than with the **Global** domain. -- **UpdateDomainSetting** — Set maintenance window parameters for a specific domain -- **GetDomainSettings** — Retrieve current domain settings including maintenance window configuration +**To set a maintenance window for a specific domain:** + +1. As system administrator, open the **Manage** dashboard. +2. In the page navigation bar, click **Maintenance Window**. +3. Click the **Add New Maintenance Window** button. +4. Associate the window with the domain you want to place under maintenance (instead of the **Global** domain). +5. Enter the schedule, notification duration, and messages, as described in [Navigating the maintenance window](#navigating-the-maintenance-window). These fields behave identically to a system-wide window. +6. Click **Save**. + +The window follows the same lifecycle as a system-wide window (**NEW** → **PLANNED** → **ACTIVE**), and can be extended, stopped, or deleted the same way. The restrictions take effect only for users of the associated domain. + +:::note +The values you provide are the same as for a system-wide window: a schedule (start time and duration), a notification duration (how long before the start time to display the **Notification Message**), and the four maintenance messages. The maintenance window is not configured through a per-domain "domain setting" value — associating the window with a domain is what scopes it. The exact placement of the domain selection in the UI may vary by version. +::: :::note -The system-wide maintenance window (configured from the **Manage** dashboard) takes precedence over domain-level maintenance windows. If both are active, the system-wide restrictions apply. +The system-wide maintenance window (a window associated with the **Global** domain) takes precedence over domain-level maintenance windows. If both a Global and a domain-scoped window are active, the system-wide (Global) restrictions apply. ::: ## Related Topics diff --git a/docs/admin/setting-up-cloudshell/assembly-lab/index.md b/docs/admin/setting-up-cloudshell/assembly-lab/index.md index 59b0f8bb88..3394102568 100644 --- a/docs/admin/setting-up-cloudshell/assembly-lab/index.md +++ b/docs/admin/setting-up-cloudshell/assembly-lab/index.md @@ -29,6 +29,36 @@ When creating routes between concrete devices in the sandbox, the system priorit If no valid route can be established through existing L1 infrastructure, a provisional direct connection (device-to-device) is created. This placeholder route can later be refined by selecting appropriate connections through Layer 1 switches or patch panels. +#### How the system chooses the route + +When you connect two concrete devices, the system evaluates the physical topology and resolves the connection in this order of preference: + +1. **A path through existing Layer 1 infrastructure.** If the two devices are wired into the same L1 switch or reachable across the L1 fabric through patch panels and Layer 1 switches, the system builds the route along that physical path. This reuses the cabling that is already in place rather than requiring a dedicated direct link. +2. **A provisional direct (device-to-device) connection.** If no valid physical path can be found through the L1 infrastructure, the system still creates the connection as a provisional direct link between the two devices. This lets you proceed with the sandbox even when the L1 route is not yet available, consistent with the Assembly Lab principle that a sandbox is always created even if not all requirements are met. + +A provisional direct connection is a placeholder. You can refine it later (see below) once the appropriate L1 path exists or once you decide which L1 segments the route should traverse. + +#### Creating a route between two devices + +Work in the sandbox (or in the blueprint's diagram editor) that contains both concrete devices: + +1. Open the sandbox or blueprint that contains the two devices you want to connect. +2. In the diagram, select the first device, then draw a connection to the second device to request a route between them. +3. Confirm the connection. The system automatically evaluates the L1 topology and either establishes the route through the existing Layer 1 infrastructure or creates a provisional direct connection if no such path is available. +4. Inspect the resulting connection in the diagram to see whether it was resolved through L1 infrastructure or created as a provisional direct link. + +#### Refining a provisional direct connection + +If the system created a provisional direct connection because no L1 path was available, you can refine it later: + +1. Locate the provisional connection between the two devices in the diagram. +2. Once the required cabling exists — for example, after both devices are connected to the same Layer 1 switch or reachable through a patch panel — re-evaluate the connection so the system can resolve it through the L1 infrastructure. +3. Verify that the refined route now traverses the intended Layer 1 switches or patch panels. + +:::note +When a route already exists between the resources, the route itself is not solved (Layer 1 ports are not reserved). This behavior is described under [Route Handling](#route-handling) above; the system still prefers resources that are connected to Layer 1 switches when selecting devices. +::: + ### L1 Port Auto-Add on Solve When solving an abstract requirement that is part of a route, if the solution resource is connected to a Layer 1 port, that port is automatically added to the route and reservation. This eliminates the need to manually manage L1 port assignments when resolving abstract requirements within routes. diff --git a/docs/api-guide/shell-dev-blueprint-design-api/manage-resource-application-links.md b/docs/api-guide/shell-dev-blueprint-design-api/manage-resource-application-links.md new file mode 100644 index 0000000000..ff39fd34cb --- /dev/null +++ b/docs/api-guide/shell-dev-blueprint-design-api/manage-resource-application-links.md @@ -0,0 +1,85 @@ +--- +sidebar_position: 3 +--- + +# Managing Resource Application Links + +Application links are the remote-access shortcuts (such as **SSH**, **Telnet**, and **RDP**) that CloudShell displays for a resource that allows remote connections. Starting in CloudShell 2026.1, the TestShell API lets administrators control which of these links are available, either on an individual resource or as a default for an entire resource family. This is useful when you want to hide connection methods that are not relevant, not permitted, or not supported for certain equipment. + +The feature is exposed through four TestShell API methods: + +| Method | Purpose | +| --- | --- | +| `SetResourceApplicationLinks` | Set which application links are disabled for a specific resource. | +| `GetResourceApplicationLinks` | Get the current application links configuration for a resource. | +| `SetFamilyDefaultApplicationLinks` | Set the default disabled application links for an entire resource family. | +| `GetFamilyDefaultApplicationLinks` | Get the family-level default configuration. | + +These methods are TestShell API methods, available across the TestShell API library, C#, TCL, and XML RPC implementations described in [TestShell API](./testshell-api.md). They are administrator operations and require an administrator session. + +## How disabled links are identified + +An application link is identified by its **application name** — the name of the remote-access application, for example `SSH`, `Telnet`, or `RDP`. Both `Set` methods take an array of these application names. The array is a list of the links you want to **disable**; any link whose application name is not in the array remains enabled. + +The set of link names that actually exist for a resource comes from the application links configured in your CloudShell system, and depends on the resource's attributes (for example, a link is only shown if the attributes it needs, such as address and credentials, are present) and on the resource's family allowing remote connections. Rather than assume a fixed list, retrieve the current configuration first (see [Get the links currently configured on a resource](#get-the-links-currently-configured-on-a-resource)) to discover the exact application names available in your environment before disabling them. + +:::note +Setting the disabled links is a **replace-all** operation. The array you pass completely replaces the previous list of disabled links — it is not merged with it. To change one link, send the full list of links that should be disabled after the change. +::: + +## Resource-level configuration + +`SetResourceApplicationLinks(resourceFullPath, disableApplicationLinks)` controls the disabled links for a single resource, where: + +- `resourceFullPath` — the full path of the resource (as with other TestShell API resource methods, you can also pass just the resource name without its folders). +- `disableApplicationLinks` — an array of application names to disable. + +A resource has three possible states, determined by the value you pass: + +| Value passed | Meaning | +| --- | --- | +| An array of application names | Those links are disabled on this resource; all other links are enabled. This overrides the family default. | +| An empty array | All links are enabled on this resource, overriding the family default. | +| No value (null) | The resource clears its own setting and inherits the family default. | + +## Family-level default configuration + +`SetFamilyDefaultApplicationLinks(familyName, disableApplicationLinks)` sets a default for the whole family, where: + +- `familyName` — the name of the resource family. +- `disableApplicationLinks` — an array of application names to disable by default. + +The family default applies to any resource in the family that has not been individually configured (that is, a resource still inheriting from its family). Passing an empty array (or no value) clears the family default, so that by default no links are disabled for the family. + +A resource-level setting always takes precedence over the family default. Once you call `SetResourceApplicationLinks` on a resource with an array (including an empty array), that resource stops following the family default until you explicitly return it to the inheriting state. + +## Reading the current configuration + +`GetResourceApplicationLinks(resourceFullPath)` and `GetFamilyDefaultApplicationLinks(familyName)` both return a response containing: + +- `DisabledApplicationLinks` — the list of application names that are currently disabled. For a resource that is inheriting, this reflects the family default that is in effect. +- `InheritingFromFamily` — for `GetResourceApplicationLinks`, indicates whether the resource is currently inheriting the family default (`true`) or using its own explicit setting (`false`). + +## Common tasks + +The parameter names and values below are the same regardless of which TestShell API implementation (library, C#, TCL, or XML RPC) you use. When calling through XML RPC, wrap the `disableApplicationLinks` array as a string vector according to the XML RPC conventions of your CloudShell version. + +### Get the links currently configured on a resource + +Call `GetResourceApplicationLinks` with the resource's `resourceFullPath` (for example, `MyRouter`). Do this first, both to see which links are disabled and to discover the exact application names available for the resource. In the response, `DisabledApplicationLinks` lists the currently disabled application names, and `InheritingFromFamily` tells you whether the resource is following its family default. + +### Disable a single link on a resource + +Call `SetResourceApplicationLinks` and pass the full list of links that should be disabled. To disable only the SSH link, pass `resourceFullPath` = `MyRouter` and `disableApplicationLinks` = `["SSH"]`. Because this is a replace-all operation, the array must contain every link you want disabled, not just the one you are changing. + +### Enable all links on a resource (override the family default) + +Call `SetResourceApplicationLinks` with `resourceFullPath` = `MyRouter` and an empty `disableApplicationLinks` array. This enables every link on the resource and stops it from inheriting the family default. + +### Set a family-wide default + +Call `SetFamilyDefaultApplicationLinks` with `familyName` = `Router` and `disableApplicationLinks` = `["Telnet"]` to disable the Telnet link by default for every resource in the `Router` family that has not been individually configured. New resources created in the `Router` family, and existing resources still inheriting from the family, will have their Telnet link disabled. Any resource that already has its own resource-level setting is unaffected. + +:::note +These methods require an administrator session. If the resource or family cannot be found, the call returns an "entity not found" error. +::: diff --git a/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/how-to-upgrade-4.2-6.md b/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/how-to-upgrade-4.2-6.md index 67bf9b3b12..e021872b18 100644 --- a/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/how-to-upgrade-4.2-6.md +++ b/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/how-to-upgrade-4.2-6.md @@ -2,14 +2,30 @@ sidebar_position: 2 --- -# How to Upgrade MongoDB From 4.2 to 6.0 +# How to Upgrade MongoDB From 4.2 to 7.0 -Following security risks in MongoDB 4.2, it was about time to update the version used by Cloudshell. +Following security risks in earlier MongoDB versions, the MongoDB version bundled with CloudShell has been updated over successive releases. CloudShell 2026.1 bundles **MongoDB Server 7.0.30**. ## Disclaimer The below instructions are for Cloudshell default installation with a standalone MongoDB installation only. +:::info Standalone vs. installer-managed MongoDB +When MongoDB was installed as part of the CloudShell installation (the **Local MongoDB instance** option), the CloudShell installer upgrades the bundled MongoDB Server automatically during a standard CloudShell upgrade — you do not need to run the steps in this article. + +Follow this article only if you use a **standalone (non-installer-managed) MongoDB** deployment (the **Mongo DB Server or cluster** option), or an external MongoDB instance/cluster. In that case, you are responsible for upgrading MongoDB yourself before upgrading CloudShell. +::: + +:::note MongoDB feature compatibility version +MongoDB requires upgrading through each major release in sequence (for example, 5.0 → 6.0 → 7.0). You cannot skip a major version. After each step, set the feature compatibility version (FCV) to the version you just moved to before proceeding to the next one, using: + +```js +db.adminCommand( { setFeatureCompatibilityVersion: "" } ) +``` + +Only after MongoDB is running on 7.0 with its FCV set to `"7.0"` should you upgrade CloudShell to 2026.1. The CloudShell MongoDB .NET driver is unchanged in 2026.1, so no application-side database changes are required. +::: + :::note MongoDB does not support Windows Server 2012. For details, see [Windows OS requirements](../../../../cs-system-requirements/min-requirements-for-cs.md). ::: @@ -225,6 +241,72 @@ MongoDB does not support Windows Server 2012. For details, see [Windows OS requi +## Upgrade from 6.0 to 7.0 + +CloudShell 2026.1 uses MongoDB Server 7.0. If your standalone MongoDB is on 6.0, upgrade it to 7.0 before upgrading CloudShell to 2026.1. + +:::warning +Before starting, confirm that MongoDB is running on 6.0 and that its feature compatibility version (FCV) is already set to `"6.0"` (the last step of the previous section). MongoDB 7.0 refuses to start against data whose FCV is lower than `"6.0"`. +::: + +The procedure mirrors the earlier steps — stop CloudShell and MongoDB, replace the `mongod.exe` binary with the 7.0 version, restart, verify, then raise the FCV — using the official MongoDB 7.0 binaries. + +1. Obtain the official MongoDB 7.0 Windows binaries and a compatible MongoDB Shell (`mongosh`) from the MongoDB Download Center: [https://www.mongodb.com/try/download/community](https://www.mongodb.com/try/download/community). CloudShell 2026.1 is validated with MongoDB Server **7.0.30**. + +2. Start the MongoDB shell and connect to `localhost`. + +3. Validate the current feature compatibility version: + ```js + db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } ) + // Expected response: { version: '6.0' }, ok: 1 + ``` + +4. Open **Task Manager > Services** and stop the **Quali Server** process (if running). + +5. Shut down MongoDB by running: + ```js + use admin + db.adminCommand( { shutdown: 1 } ) + // The shell connection closes. Close the shell window. + ``` + +6. In File Explorer, open the extracted MongoDB 7.0 `bin` folder from your downloads. + +7. In a second File Explorer window, open the `bin` folder of your MongoDB installation (for a default CloudShell install this is `C:\Program Files\MongoDB\Server\4.2\bin`). + +8. Delete the existing `mongod.exe` from the MongoDB installation's `bin` folder. + +9. Copy the `mongod.exe` from the MongoDB 7.0 `bin` folder into the MongoDB installation's `bin` folder. + +10. Open **Task Manager > Services** and start the **MongoDB** service. + +11. Start the MongoDB shell and verify the upgrade: + ```js + db.version() + // Confirm a 7.0.x version is reported + use Quali + db.Reservation.countDocuments() + // Confirm the reservation count matches the pre-upgrade count + ``` + +12. (Optional) Start **Quali Server** and open the **Sandboxes** dashboard in CloudShell Portal to confirm data is intact, then stop **Quali Server** again. + +13. Raise the feature compatibility version to 7.0: + ```js + db.adminCommand( { setFeatureCompatibilityVersion: "7.0", confirm: true } ) + ``` + :::note + MongoDB 7.0 requires the additional `confirm: true` argument for `setFeatureCompatibilityVersion`. If your build of MongoDB 7.0 rejects `confirm`, rerun the command without it. + ::: + +14. MongoDB is now on 7.0. Proceed to upgrade CloudShell to 2026.1. + +For the authoritative, version-specific steps (including replica-set and sharded-cluster scenarios that are out of scope for this article), always follow MongoDB's official procedure: [Upgrade a Standalone to 7.0](https://www.mongodb.com/docs/manual/release-notes/7.0-upgrade-standalone/). + +:::info Related 2026.1 prerequisite upgrades +Alongside MongoDB, CloudShell 2026.1 also upgrades other bundled prerequisites, which the CloudShell installer handles automatically: Node.js 22 → 24 LTS, Erlang OTP 25 → 26, and Apache httpd to 2.4.66. Note that Node.js 24 dropped 32-bit (x86) Windows support, so the x86 Node.js prerequisite has been removed from the installer; components requiring Node.js now run only on 64-bit Windows. For details, see [3rd Party Software](../../../../cs-system-requirements/third-party-software.md). +::: + ## Related Topics - [Select the Database Type](../select-database-type/index.md) diff --git a/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/index.md b/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/index.md index 4ef98e1ab0..6501a7c044 100644 --- a/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/index.md +++ b/docs/install-configure/cloudshell-suite/complete-install/install-cloudshell/select-database-type/index.md @@ -30,10 +30,10 @@ For more information, see [New Job Scheduling Architecture](../../../new-jss-ins - If your system administrator has a centralized MongoDB instance or cluster that can be utilized for CloudShell, select the **Mongo DB Server or cluster** option (Supported for MongoDB 4.2 and above). :::tip - If you want to use a higher version of MongoDB, make sure to first upgrade to the relevant MongoDB version, as explained in [How to Upgrade MongoDB From 4.2 to 6.0](./how-to-upgrade-4.2-6.md). + If you want to use a higher version of MongoDB, make sure to first upgrade to the relevant MongoDB version, as explained in [How to Upgrade MongoDB From 4.2 to 7.0](./how-to-upgrade-4.2-6.md). CloudShell 2026.1 uses MongoDB Server 7.0; if you manage MongoDB yourself, upgrade it to 7.0 before upgrading CloudShell. ::: - - If there is no external MongoDB, select **Local MongoDB instance** to enable CloudShell installer to use an existing instance of MongoDB. If you don't have an existing MongoDB instance or cluster, select **Install MongoDB Server 6.0.4** to install and configure a local MongoDB Server 6.0.4 instance (Community edition). + - If there is no external MongoDB, select **Local MongoDB instance** to enable CloudShell installer to use an existing instance of MongoDB. If you don't have an existing MongoDB instance or cluster, select the option to install a local MongoDB Server instance (Community edition). The CloudShell installer bundles and installs the MongoDB Server version certified for the release you are installing (MongoDB Server 7.0.30 in CloudShell 2026.1). :::tip For high load systems, we recommend using a cluster/instance that is hosted on a separate machine (not Quali Server). For additional information, see [Best Practices for MongoDB](./best-practices-for-mongodb.md). diff --git a/docs/portal/blueprints/creating-blueprints/resources/find-resources.md b/docs/portal/blueprints/creating-blueprints/resources/find-resources.md index 1eac5b031e..60887122cb 100644 --- a/docs/portal/blueprints/creating-blueprints/resources/find-resources.md +++ b/docs/portal/blueprints/creating-blueprints/resources/find-resources.md @@ -41,9 +41,12 @@ After search results are returned, you can further filter results in order to lo - By connectivity - By domain +- By L1 ports Additional filters are provided in order to further narrow results by connectivity or domain. Choose the connectivity filter to find resources which are currently disconnected, currently connected, or choose "any status" to locate resources of either status. Choose the domain filter to find resources in the current domain, all domains corresponding to the current user, or resources which are not yet allocated to a domain. +Select the **L1 Connectable** check box to limit the results to resources that have L1 (Layer 1) ports, so you can quickly locate resources that can be connected through an L1 switch. Clear the check box to include resources regardless of whether they have L1 ports. + ### Finding the right resources You can use the search to narrow down the query to target specific results. For example, searching for '10G ethernet traffic port' will attempt to match the search phrase as well as subsets of it to resources that may match it and rank them accordingly. diff --git a/docs/portal/sandboxes/sandbox-workspace/resources/find-resources.md b/docs/portal/sandboxes/sandbox-workspace/resources/find-resources.md index a6ff574e9d..8e484289fd 100644 --- a/docs/portal/sandboxes/sandbox-workspace/resources/find-resources.md +++ b/docs/portal/sandboxes/sandbox-workspace/resources/find-resources.md @@ -43,9 +43,12 @@ After search results are returned, you can further filter results in order to lo - By connectivity - By domain +- By L1 ports Additional filters are provided in order to further narrow results by connectivity or domain. Choose the connectivity filter to find resources which are currently disconnected, currently connected, or choose "any status" to locate resources of either status. Choose the domain filter to find resources in the current domain, all domains corresponding to the current user, or resources which are not yet allocated to a domain. +Select the **L1 Connectable** check box to limit the results to resources that have L1 (Layer 1) ports, so you can quickly locate resources that can be connected through an L1 switch. Clear the check box to include resources regardless of whether they have L1 ports. + ### Finding the right resources You can use the search to narrow down the query to target specific results. For example, searching for '10G ethernet traffic port' will attempt to match the search phrase as well as subsets of it to resources that may match it and rank them accordingly. From 415fad27e526e19a4375769472881c35a6e321cc Mon Sep 17 00:00:00 2001 From: "QUALISYSTEMS\\nahum-t" Date: Mon, 27 Jul 2026 11:51:56 +0300 Subject: [PATCH 2/2] Add 'sharded' to spellcheck wordlist Co-Authored-By: Claude Opus 4.8 (1M context) --- .wordlist.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/.wordlist.txt b/.wordlist.txt index 2013cb65ba..3f5defcc73 100644 --- a/.wordlist.txt +++ b/.wordlist.txt @@ -1652,3 +1652,4 @@ FCV setFeatureCompatibilityVersion featureCompatibilityVersion Telnet +sharded