This article defines the following terms:
Abstract resources are blueprint components that comprise the required settings of the resources you want to use in the sandbox. For example, device model, Firmware version, minimum number of ports, etc. When reserving a blueprint, CloudShell scans the inventory for matching candidates and dynamically allocates them to the sandbox. For details, see Abstract Resources Overview.
The CloudShell admin is responsible for setting up CloudShell, creating resources, services and App templates, and providing all the necessary components and assets required to create blueprints and sandboxes. CloudShell has two types of admins: the sysadmin, or Global admin, has full access to all CloudShell domains and the Domain Admin has admin permission in specific domains.
An App is a sandbox component that provides the definition of an application hosted on a specific cloud provider. When run in the sandbox, the App deploys a virtual machine (VM) and performs the specified configuration management on it. For details, see Apps Overview.
Script and driver processes/commands that are performed on the sandbox and/or the sandbox components. Examples include resource commands and orchestration scripts that run sandbox setup/teardown processes. For details, see Automation Overview.
A blueprint is a template of an IT environment that can be reserved (i.e. brought online). It typically includes the required components (resources, services, Apps) and configurations, automation and networking. When reserving a blueprint, CloudShell creates a sandbox for the specified duration. For details, see Blueprints.
The blueprint designer is a CloudShell user or admin who is responsible for creating and managing blueprints.
CloudShell categories are elements that are used to organize and display different CloudShell assets. There are two types of categories in CloudShell:
- Blueprint categories organize blueprints in the Blueprint Catalog.
- Service categories perform two functions.
- Expose specific services and Apps to specific domains. This requires assigning, to the component, a service category that is linked to the domain.
- Organize services and Apps in the App / Service catalog. By default, Apps are assigned the Applications category while services are assigned the category defined in their Shell. The Applications and default service categories are linked to the Global domain.
For details, see Managing Categories.
Cloud providers are used by CloudShell Apps to deploy and manage VMs as part of the sandbox.
CloudShell provides out-of-the-box support for public cloud providers AWS EC2 and Microsoft Azure, and private cloud providers VMware vCenter and OpenStack. In addition, community developers can extend support for additional cloud providers using our Custom Cloud Provider shell. For details, see Supported Cloud Providers in CloudShell.
CloudShell Portal is the CloudShell web client in which admins, designers and end-users operate.
Connectivity routes represent a connectivity request between two components in the blueprint or sandbox workspace, which is resolved with the reservation of the blueprint. The type of connectivity can be a direct or indirect physical connection between two devices (route), or a network link (connector). CloudShell supports P2P connections (layer 1, 2, and 3) and many to many connections using VLAN or subnet services. Once the sandbox is torn down, all routes are disconnected.
CloudShell domains are pools of CloudShell blueprints, resources, Apps and services, which allow their members to access and use these assets. By default, CloudShell provides the Global domain but additional domains can be created to logically isolate different teams in the organization or geographically-distributed sites and centers.
Email notifications can be used to alert the admin, sandbox owner and permitted users of different sandbox lifecycle events. In addition, email notifications for customers using automation suites are also available, For details. See Email Notifications Overview.
See Sandbox end-user.
Execution Servers run automation on sandboxes and sandbox components, including scripts and shell driver commands. Additionally, Execution Servers execute tests as part of automation suites - this requires the Job Scheduling add-on. For details, see Managing Execution Servers.
CloudShell Insight is CloudShell's BI and analytics tool. It provides visibility and business intelligence into CloudShell's inventory and user activity in the form of easy-to-understand graphs, charts and tables. For details, see CloudShell Insight BI Overview.
In CloudShell Help, the term "instance" may refer to:
- Attribute instance: When you associate a global attribute to a shell, that attribute is called an attribute instance. You can modify the settings for that attribute on that particular shell, including default value and value constraints.
- AWS/OpenStack instance: "instance" is the standard term for "VM" in AWS and OpenStack
- Automation suite instance: In this context, "instance" indicates a live execution of an automation suite or automation suite template.
Driver instance: As illustrated below, when a python command runs in CloudShell, the Execution Server running the command creates an instance of the command's driver and a dedicated python virtual environment for that instance on the Execution Server, and loads the command's required packages and dependencies into this virtual environment.
That command as well as all future command executions for that resource, service or App will run on that instance as long as the instance is alive. Once the instance is live, subsequent commands will take less time to run, as the instance already exists and has the required dependencies. The instance idle time is 10 minutes. For additional information, see Execution Servers - Executions Page and Virtual environment (venv).
CloudShell License Server is the CloudShell component that contains the purchased CloudShell licenses and provides access tokens to the client computers in order to enable CloudShell software to run.
PyPi Server is a CloudShell component, which manages and serves python packages and dependencies to python drivers and scripts that are running in CloudShell sandboxes. It is installed on the Quali Server machine and requires access to the Quali Server and Execution Servers. For details, see PyPi Server - Managing Python Driver and Script Dependencies.
Quali Server, which is also called CloudShell Server, is the "brain" of the CloudShell suite. It contains CloudShell's configurations, provides user access to CloudShell and processes queries and requests from CloudShell Portal and the APIs.
QualiX is a CloudShell program that allows in-browser connections to sandbox devices and VMs using a remote connection protocol such as RDP, Telnet and SSH. For details, see the QualiX Installation and Configuration Guide.
A resource is a sandbox component that models a physical or virtual device. For example, a switch, router, bridge or static VM. For details, see Resources Overview.
Resource Manager Client is a CloudShell desktop application that is used for CloudShell administration operations, including managing domains, users and global attributes. It also allows admins to share resources and blueprints across mutliple domains. For details, see the CloudShell Resource Manager Help.
A sandbox is an active, isolated instance of a blueprint, within a specific domain, which has been reserved for a specific period. For details, see Sandboxes.
The sandbox end-user is the consumer of the sandbox. This user typically logs into CloudShell Portal, finds the appropriate blueprint and reserves it.
CloudShell scripts are Python scripts that provide automation commands that can run on the sandbox and on the component level. For details, see Managing Scripts.
- Blueprint scripts: Blueprint scripts are scripts that run on the sandbox. For example, running a traffic test that involves several components, including the traffic generator chassis, controller service and DUT.
- Orchestration scripts: Orchestration scripts are blueprint scripts that run automatically as part of the sandbox's lifecycle. You can use orchestration scripts to create setup and teardown procedures as well as other custom workflows that can be made available in the sandbox. CloudShell includes several out-of-the-box orchestration scripts, which are provided with our default blueprint template. For details about our out-of-the-box orchestration scripts, see CloudShell Sandbox Template.
- Resource scripts: Resource scripts allow you to add automation to specific sandbox components. These scripts are intended to add simple functionality, or to be used for testing and debugging activities. Note that in order to add automation to a shell, the best practice is to use the component’s driver.
A service is a sandbox component that models a public cloud service or SaaS product. For details, see Services Overview.
A shell enables CloudShell users to interact with different sandbox elements, like physical devices and virtual appliances. A shell models the sandbox element in CloudShell and provides commands that CloudShell users and automation processes can run on it, like Power On and Health Check. For details, see Shells Overview.
Unlike CloudShell Apps, static VMs are VMs that are loaded into CloudShell as is from the cloud provider. CloudShell does not manage their lifecycle and the out of the box Setup and Teardown processes do not apply to these types of components. In CloudShell, static VMs are represented by resources. For details, see Static VMs Overview.
Virtual environments are folders that contain a python driver or script's packages and dependencies. CloudShell creates a dedicated virtual environment on the Execution Server machine whenever a resource or script command is executed and downloads the command's dependencies to this virtual machine from the public PyPi repository. For details, see What are Python Virtual Environments?.