Import a Blueprint Package into CloudShell
This procedure describes how to import a blueprint package into CloudShell so that when deployed, the blueprint will work as it did before it was exported. The import procedure also applies to 1st Gen Shells, which are imported into CloudShell the same way.
Before importing a package, make sure to import (into CloudShell Portal) the shells associated with the blueprint's resources.
See Exporting a Blueprint Package to get more information about how to create these packages.
Note: When exporting a package, the complete zip file is exported. However, when preparing the zip file for import, you can change the contents of the package zip file. For instance, you can export a blueprint to generate a package, but remove the Topologies folder from the zip file so that only the resources and data model will be imported.
To import a package use either one of the following:
- From the User menu, select Import Package and then browse to the required zipped package file
- Drag the zipped package file and drop it anywhere in the portal.
The following table describes which elements are imported into CloudShell.
Contents | Process |
|---|---|
metadata.xml | The validation process checks that the metadata.xml file exists, is valid (is of a known package type) and that the server version is less than or equal to the current server version. |
Categories | Categories are updated for the imported blueprint only if these categories are already assigned to the current domain. |
Drivers (1st Gen shells only) | Import all resource drivers (as part of the resource shells) in the package. If drivers that have the same names as existing drivers are added, the existing ones are overwritten, even if the imported package is from an older CloudShell Server version. Note: Resource drivers are supported for backwards compatibility only. |
Data model (1st Gen shells only) | Import new and update existing attributes, new families and models, drivers, and images. Warnings:
|
Resources | Import new and update existing resources and sub resources. IP addresses are only updated if the existing value is NA. Resources are searched for by unique ID. If not found, then the search is performed according to name. Warning: If data models that have the same names as existing data models are added , information that is overwritten includes the default value, description, read-only information and other properties. However, other elements are added, for example model attributes. In most cases information that is set in the database but not in the package is not deleted, like the attributes of a model. In addition, if any of the packaged resources are based on Shells or Shell versions that are missing from CloudShell, you will be prompted to import the required Shells first. |
| App Templates | Import new and update existing App templates. App templates are searched for by name. |
Topologies | Import new and update existing blueprints, including resources, connections, and blueprint properties. Warning: If blueprints that have the same name as existing blueprints are added, the existing blueprints with the same name are overwritten, even if the imported package is from an older CloudShell Server version. |
An indication message is displayed in CloudShell Portal to confirm the import.
Import user permissions
The import process is limited by the user's permissions, as described in the following table:
Role | Permissions |
|---|---|
System Administration | System administrators can import whole packages. |
Domain Administration | Domain administrators can only import blueprints and resources, even if the package contains drivers and data models. |
Regular User | Regular users can only import blueprints. For example, in cases where packages contain a number of different folders and files, only the blueprints are imported. This process might therefore fail if it needs some of the dependencies that are in the package. |
External User | This user has the same permissions as the Regular User. |
Additional information
- Each step in the import process has its own validation process. The import steps that follow do not start until the current step ends successfully.
- If part of the import fails, all the earlier parts are preserved. In this case, the completed part of the package remains in the database.
- L1/Patch panel drivers are not exported or imported.
