Creating options and option choices in the OpenStack Provider

BMC Cloud Lifecycle Management administrators must create options and option choices for the OpenStack Provider service offerings as per the cloud service provided by OpenStack, so that end users can provision a virtual machine (VM) and modify configurations after a VM is provisioned.

This topic contains the following sections:

• • Creating options and option choices for the OpenStack Provider
  • About the options for the OpenStack Provider

Creating options and option choices for the OpenStack Provider

To create an OpenStack Provider option, open the Options Editor and define the OpenStack Provider option, as displayed in the following figure:

You must configure an option choice for the option created for the OpenStack Provider. For detailed steps, see to add options and option choices to service blueprints.

About the options for the OpenStack Provider

You must create the following options for an OpenStack Provider of the corresponding option types:

The following sections describes the options for the OpenStack Provider and the steps to be followed for creating the option choices:

OpenStack Flavor option

Flavors define how many virtual CPUs an instance has, the amount of RAM, and the size of its ephemeral disks. OpenStack provides a number of predefined flavors that you can edit or add to. Users must select from the set of available flavors defined on their cloud.

Defining the OpenStack Flavor option of request definition option type allows you to specify the cloud service sizes that the end user can specify or change during the provisioning of the offering. The cloud administrator uses the OpenStack Flavor option to configure the service offering with all of the available sizes and options for VMs on OpenStack.

You can create VMs in an OpenStack Provider with a minimum memory size of 512 MB (m1.tiny size), and a maximum memory size of 16,384 MB (m1.xlarge size).

When you launch an instance, you must choose a flavor, which represents a set of virtual resources. For the OpenStack Flavor option, you must create the option choices for blueprint configuration as a FunctionalModel parameter. You must create the choices of cloud service size based on the allowed sizes in OpenStack. Following is a list of sample sizes of OpenStack:

1. m1.tiny (1 VCPU, 1 disks, 512 MB memory)
2. m1.small (1 VCPU, 20 disks, 2048 MB memory)
3. m1.medium (2 VCPUs, 40 disks, 4096 MB memory)
4. m1.large (4 VCPUs, 80 disks, 8192 MB memory)
5. m1.xlarge (8 VCPUs, 160 disks, 16384 MB memory)

To create the option choice for the OpenStack Flavor option

1. Define the option choice for the m1.tiny flavor option choice at Blueprint Configuration > Service Definition > Parameters, as shown in the following figure:
   

    

   Note

   For more information, see Option-Choices-available-when-extending-service-blueprints.

2. Specify the following details for configuring an option choice of m1.tiny size, as shown in the following figure:
   

New in 4.6.07In versions earlier than BMC Cloud Lifecycle Management 4.6.07, native OpenStack supports only five fixed flavours (instance flavours) (for example, m1.tiny, m1.small etc.) to be provisioned through BMC Cloud Lifecycle Management, while some of the users or any public cloud provider with OpenStack can support hundreds of instance flavours with different instance type families. Currently, these instance type values are provided as Blueprint configuration parameter during provisioning, (as a parameter “OpenStack Flavour” with value, for example, “m1.small”)

BMC Cloud Lifecycle Management 4.6.07 adds a flexible way of automatically choosing the instance type based on the CPU and memory values (within the  instance family). Users or any public cloud vendors with OpenStack can have hundreds of instance flavours with different instance type families. In order to support any type of instance flavour for openstack for day 2 options, CPU and Memory specification are read from metadata json (for example, OpenStackInstanceTypeMetaData.json) and chose the closest match along with in the same instance family, which is computed while provisioning from metadata.

OpenStack Flavor selection

You can select the OpenStack flavour by using the following ways 

• Based on best match

New in 4.6.07 When meta data file contains information about flavors and family, BMC Cloud Lifecycle Management is using the best match. The flavors is selected based on CPU and memory mentioned against flavors in meta data. Below is a sample implementation flow:

1. Add a Openstack flavourblueprint parameter, for example, ‘c1.medium’
2. Provision VM with flavour with cpu 1, memory 1024mb and c1.medium favour (as added in previous step).
3. After provisioning, external Id is updated as <server_id>|<instanceFamily> (for example, 035b1f3f-f0b2-433b-8f72-0fad639c6df4|GENERAL_PURPOSE). In case of default flavours in openstack (like m1.tiny). family, BMC Cloud Lifecycle Management assumes ‘NATIVE’. BMC Cloud Lifecycle Management is computing instancefamily from metadata file with reference to flavour that is added as blueprint parameter.
4. While day 2 option execution, flavours are selected from same family and not across families.

• 
  
  • While ‘Add CPU’, if you selected 3 CPU, then flavour is selected as “c1.xlarge”, that is next higher size in term of CPU.
  • While ‘Add CPU’, if someone selected 10 CPU (suppose 8 cpu is the highest cpu flavour), then a flavour not found error message is displayed.

The same rule applies for Add Memory option as well.

• Based on exact match

If OpenStackInstanceTypeMetaData.json is empty, corrupted or not found, BMC Cloud Lifecycle Management uses the exact match approach. Flavor (instance type) is selected on the match of CPU, Memory, Disk size, and ephemeral disk in Openstack infrastructure. 

CPU and Memory details specified for a resource set are used to select the closest match for instance type. To maintain the consistency, Instance type selection mechanism used is same as the one used for AWS or Azure, where selected instance type is closest match ( on higher side) for provided memory and cpu details. This selection criteria first filters instance type based on memory and then on CPU.

To provide more flexibility to select instance type, you should provide instance family (instance type series) details in Blueprint configuration parameters. This ensures that created instance type belongs to provided instance family. There are more than one instance types which have same CPU and memory combination. Hence, providing instance family details helps in selecting desirable instance type.

Parameters for instance flavour

To support family based provisioning and Day2 for CPU/RAM, which in turn triggers the flavour change on open stack infra, the metadata json file must be  pre-populated by client with all the existing flavour in the open stack infra with proper family name and other flavour information.

BMC Cloud Lifecycle Management provides the empty or filled with dummy data metadata file inside the configuration directory and also sample data file with name OpenStackInstanceTypeMetaData_<patch number>.json. Sample file contains information with different kind of famility and native OpenStack flavours – m1.tiny, m1.small,m1.medium,m1.large,m1.xlarge and their family is defined as native.

In case of exact match, if you try to perform day2 with a particular CPU and RAM combination, it works only if exact match exist on OpenStack infrastructure. For example, the matching combination of CPU/RAM/DISK should exist on OpenStack infrastructure. If such combination doesnot exist on OpenStack infrastructure, you receive no matching flavour error message.

If BMC Cloud Lifecycle Management administrators want to use OpenStack family concept , they should populate the file with proper data before provisioning and day2. Also, if any flavour is getting added to OpenStack side this file needs to be modified if you want to use the new flavour. If file is populated with proper data of family and flavour, OpenStack will perform the best match(equal/next higher combination with in the same family) to find a flavour required. If metadata.json file is populated by administrators and few of the flavours are missing in the file, BMC Cloud Lifecycle Management wouldnot be able to recognise such flavours and you receive no matching flavour error message while provisioning . For day2 such flavours are not available/considered while performing best match. 

The following parameters are used for instance flavour selection:

Update CPU and Memory option

The Update CPU and Memory option of Post-Deploy Action type allows you to increase the CPU core and memory size of a provisioned VM.

Following are the option choices for Update CPU and Memory option in OpenStack:

• For the memory option, you can create choices of memory size based on allowed memory sizes in the OpenStack Provider. For example, you can create Microsoft Windows VMs in the OpenStack Provider with a minimum memory size of 256 MB and a maximum memory size of 16,384 MB. Each choice must be a multiple of 4, so you can have 256 MB, 1,024 MB, 2,048 MB, or 3,072 MB.
• For the CPU option, you can create option choices for 1, 2, 4, and 8 VCPUs.

Steps to create the option choice for the Update CPU and Memory option

1. Define the option choice for the Update CPU and Memory option at Blueprint Configuration > CPU Count or Memory Size, as shown in the following figure:
   
   
   

   Note

   For more information, see Option-Choices-available-when-extending-service-blueprints.

2. Specify the following details for configuring an option choice of m1.tiny size:

• 
  
  • CPU count, as shown in the following figure:
    
  • Memory Size, as shown in the following figure:
    

Add Disk option

The Add Disk option of Post-Deploy Action  type allows you to increase the disk volume of a provisioned VM.

For the Add Disk option, you must create the option choices for blueprint configuration as Additional System Disk.

Steps to create the option choice for the Add Disk option

1. Define the option choice for the Add Disk option at Blueprint Configuration > Additional System Disk, as shown in the following figure:
   
   
   

   Note

   For more information, see Option-Choices-available-when-extending-service-blueprints.

2. Specify details for configuring an option choice for the Add Disk option, as shown in the following figure:
   

Install Software option

The Install Software option allows you to install software on a provisioned server. You can specify the software details to be installed on a provisioned server.

For the Install Software option, you must create the option choices for blueprint configuration as Software Packages.

Steps to create the option choice for the Install Software option

1. Define the option choice for the Install Software option at Blueprint Configuration > Software Packages, as shown in the following figure:
   
   
   

   Note

   For more information, see Option-Choices-available-when-extending-service-blueprints.

2. Specify the following details for configuring an option choice for the Install Software option, as shown in the following figure:
   

Add Local User option

The Add Local User option allows you to add local user on a provisioned server. You must specify the User Name and Password parameters to enable user provisioning on the OpenStack server. 

For the Add Local User option, you must create the Create User option choice with the following blueprint configuration details:

• A  BLPackage having the local properties defined in it for user provisioning (For example: Linux Add User or Windows Add User BLPackage)  as Software Packages.
• A parameter for user name (UNIX_USER or WINDOWS_USER) as Deployment Model Parameter.
• A parameter for user password (UNIX_USER_PASSWORD or WINDOWS_USER_PASSWORD) as Deployment Model Parameter.

See Creating-a-BLPackage-for-adding-local-users-in-the-OpenStack-Provider for details.

The following figure illustrates the blueprint configuration details to be defined for the Create User option choice:

Steps to create the option choice for the Add Local User option

1. Define the option choice for the Add Local User option at Blueprint Configuration > Software Packages, as shown in the following figure:
   
   
   Note: For more information, see Option-Choices-available-when-extending-service-blueprints.
2. Specify the following details for configuring an option choice for the Add Local User option, as shown in the following figure: