Converting 1st Gen Shells into 2nd Gen
As of version 8.0, CloudShell supports 2nd Generation Shells. In this topic we’ll go through the steps needed to convert a 1st Generation Shell into a 2nd Generation Shell.
Overview
CloudShell Shells can be thought of as either 1st Generation Shells (1st Gen) or 2nd Generation Shells (2nd Gen). Both types of Shells can coexist inside the same CloudShell sandbox, but they differ in their structure and in the way that they are managed.
-
1st Gen Shells are imported as CloudShell packages that contain the data model and driver for the intended sandbox element. 1st Gen Shells allow extensive control of the family and model, and therefore are not standardized. While they allow maximal flexibility, when using them, some Shell management capabilities may not be available.
-
2nd Gen Shells are imported through CloudShell Portal’s Shells management page. 2nd Gen Shells are based on standardized models and attributes, which streamlines the creation, maintenance and sharing of Shells.
Prerequisites
Before we start, it is important to understand the requirements:
- To convert a 1st Gen Shell you need access to the Shell’s source code.
- You can only convert a Shell that implements the latest standard version.
It is highly recommended to first learn how to create and model a 2nd Gen Shell before trying to convert from 1st Gen. This is described in detail in previous chapters of this guide.
To convert a 1st Gen Shell to a 2nd Gen Shell:
- Create a 1st Gen Shell
- Create a 2nd Generation Shell
- Edit the Shell’s data model
- Convert the Driver
- Test the conversion
Create a 1st Gen Shell
In the context of this example, we will create a 1st Gen Shell, enable AutoLoad and add additional custom functions.
To prepare the 1st Gen Shell for conversion:
1) Create a 1st Gen switch Shell by running the following command in your Command Line:
This Shell implements the networking standard v 4.0.1.
2) Enable the autoload by updating the following line in the shellconfig.xml file in the datamodel folder:
3) Replace the get_inventory function in the driver.py file with this sample of get_inventory:
4) Add an additional function that prints the ‘vendor’ attribute value:
Create a 2nd Gen Shell
To convert the Shell, we will first create a new 2nd Gen Shell that implements the same standard version. Then we can edit the data model and update the driver.
To prepare the 2nd Gen Shell for conversion:
- Create a 2nd Gen switch Shell by running the following in your Command Line:
It is recommended to change the name of the Shell to enable the 1st Gen Shell and the 2nd Gen Shell to work side by side on the same CloudShell database.
Edit the Shell’s data model
To edit the Shell’s data model:
- In the shell-definition.yaml file, update the metadata section and make sure that the Shell imports the same CloudShell standard version as the 1st Gen shell.
-
If the Shell includes custom attributes, see Modeling the Shell to learn how to model them in 2nd Gen Shell format.
-
If the Shell includes custom attributes in the discovery process, see Auto Discovery For Inventory Shells to learn how to customize the Auto-discovery process.
Convert the Driver
To convert the driver, we need to update the driver files and then update the code.
Updating the driver
To update the driver, we need to copy the 1st Gen driver into the 2nd Gen Shell project. However, since the name of the Shell may be different, we need to copy the files and keep all the references of the Shell’s name.
To update the driver:
1) In a text editor, open the 2nd Gen driver files in the src folder and save the lines that include references to the Shell’s name:
- In the drivermetadata.xml file, copy line #1 (MainClass and Name)
- In the driver.py file, copy the class name
2) Replace the files in the 2nd Gen Shell’s src folder with the files from the 1st Gen Shell’s src folder.
3) To ensure that the original Shell’s name is used, open the files (drivermetadata.xml and driver.py) and replace the relevant lines with the lines we saved.
At this point, it is recommended to install the Shell and make sure that we don’t get any error message. If the installation fails, make sure that the name references match the new Shell’s name and that you copied all the driver files properly.
4) To test the modeling of the 2nd Gen Shell, run the following command in your Command Line to install the Shell:
Updating the Code – The Shell’s data model
To convert the 1st Gen Shell code to 2nd Gen, we need to modify it to match the 2nd Gen Shell’s data model.
To update the driver data model code:
1) Generate the Shell’s data model by running the following command in your Command Line:
2) Add the following to the driver.py file to import the Shell date model into the new driver:
The Shell’s data model should be used in all the places in the driver where we refer to an attribute by name.
- For our example, replace the sample_command with the code below.
This code converts the context object that CloudShell provides to an instance of the Shell’s data model, which is saved in the resource variable, then retrieves the value of the vendor attribute by referring to the resource.vendor property.
Updating the code – Auto-Discovery
To simplify the conversion process, CloudShell provides a special python class that transforms 1st Gen discovery code to the 2nd Gen discovery’s structure without having to rewrite the existing code.
The class is called LegacyUtils and it is automatically generated with the Shell’s data model.
The example below shows how to use the LegacyUtils class:
In this example, you can see that the code creates two arrays: sub_resources and attributes, which are saved in the autoload_details object. This 1st Gen structure is using explicit attribute names and model names in string format and needs to be transformed to 2nd Gen format.
With the LegacyUtils().migrate_autoload_details method, we convert the autoload_details object into a new object migrated_details. Then the function returns the new formatted structure by calling the migrated_details.create_autoload_details() object.
By using LegacyUtils we can avoid rewriting the get_invontory function. However, in the long term, it is recommended to refactor the code to use the Shell’s data model, as defined in Auto Discovery For Inventory Shells
Test the conversion
To test the conversion:
1) Install the Shell by running the following in Command-Line:
2) Log in as administrator to CloudShell Portal, create a Shell resource. Make sure that the Auto-discovery successfully creates the resource with all of its sub-resources.
3) Add the resource to a sandbox and run the sample_command.
4) Check the Output console to see that the command successfully printed the value of the vendor attribute.