Properties
Metadata on Cloud instances can be specified as so-called properties, either at instance creation time, or on existing instances. This can be achieved in Web interface, and via the command line.
This pages describes the different properties that are available.
Setting properties using the command line interface
- At creation time:
openstack server create --property key=value ...
- On an existing instance:
openstack server set --property key=value <VM name>
To unset a property:
Setting properties using the web interface
You can also set these properties at creation time using the Web UI.
In that case, during the launch instance wizard you need to go to the metadata step.
Then to show the available properties please click on the drop down button that will expand those.
Later, you need to click on the + button to specify the properties to use.
And finally in the right hand side, you can specify the value you want for each of the properties selected.
You can also clear properties using the Web UI. In that case click on the update Metadata action for your virtual machine in the Instances view. Then you'll see all the existing properties that you machine has. You can clear existing ones by clicking on the - button. Once you are ok with the changes click save to set the values in the machine.
Properties relevant at instance creation time only
It can be important that instances are registered in the CERN DNS and/or Active Directory before their first boot. For example, this is required for a server to establish a Kerberos identity, or to retrieve an X.509 host certificate.
To accommodate these needs, the CERN Cloud instances are registered (by default) into the LanDB networking database and the Active Directory directory, and a delay is introduced to make sure the information is propagated to DNS. Note that this increases the creation time significantly, to up to 15 minutes.
The property below can be used to deactivate these registrations, which will reduce boot times to less to 2 minutes.
cern-waitdns=<true|false>
Set to true (default) or false in order to wait for DNS propagation before booting the new instance.
cern-activedirectory=<true|false>
Set to true (default) or false in order to register the new instance into Active Directory before boot.
cern-checkdns=<true|false>
Set to true (default) or false in order to check if the name is available in the DNS. If not available means that a previous instance was using that name and it's not removed yet from DNS (DNS propagation can take up to 15 minutes).
Note
If cern-checkdns=false the name resolution can point to a wrong IP until the DNS propagation.
cern-services=<true|false>
This option is deprecated. Please use cern-waitdns and/or cern-activedirectory instead.
Other CERN-specific properties
landb-description
Sets the LanDB description field to the value provided. By default, this string is empty.
landb-mainuser
A User name or e-group name. The primary user of the virtual machine. The syntax for the field is the CERN user name (such as timbell) and not the e-mail address. e-groups are specified by giving the name of the group (i.e. the mailing list address without @cern.ch). Please note, that service accounts can not own resources in LanDB. If a service account is used to set the properties "landb-mainuser" or "landb-responsible" the owner of the service account will be used instead.
landb-responsible
Note
The LanDB-responsible will be notified of all the possible interventions that could affect your instance.
A User name or e-group name. The person responsible for the virtual machine. The syntax is as for mainuser.
Please note, that service accounts can not own resources in LanDB. If a service account is used to set the properties "landb-mainuser" or "landb-responsible" the owner of the service account will be used instead.
landb-os
The operating system to be stored in LanDB. This is a free format field but common values are "LINUX" and "WINDOWS 7".
landb-osversion
The operating system version to be stored in LanDB. This is a free format field. For "LINUX", this is generally set to the release.version of the corresponding version of RHEL.
For "WINDOWS", this is set to the extended version such as "SP1"
landb-alias
Comma separated list of alias names per interface FQDN:
Note
When using multiple interfaces use ";" to separate different interfaces/alias mappings and ":" to map interface fqdn to alias:
$ openstack server set --property landb-alias="INTERFACE_1_FQDN:myalias1,myalias2;INTERFACE_2_FQDN:myalias3,myalias4"
Note
The previous alias list is overwritten by this command.
Thus, if you wish to append a new alias, it is necessary to get the value using openstack server show ... and then add the new alias.
Note
An alias will create a CNAME entry in the DNS.
If you need an "A" entry instead, you can append --LOAD-1- to your alias name.
For example, the alias 'myalias' will create a DNS CNAME entry, an alias called myalias--LOAD-1- will create an "A" entry.
The server will be reachable by 'myalias' in both cases.
Alias list longer than 255 characters
If you have a requirement for more than 255 characters to this field, you can use any property keys that start with landb-alias.
# The following commands are equivalent:
$ openstack server set --property landb-alias="alias1,alias2,alias3" ...
$ openstack server set --property landb-alias="alias1" --property landb-alias2="alias2,alias3" ...
landb-ipv6ready=<true|false>
Please set this value to true if the applications running on the VM can support IPv6.
This property is false by default while testing of applications continues. For details of how to configure your VM with IPv6, see Enabling IPv6 .
landb-internet-connectivity=<true|false>
- Default value:
true - Set to
falseif the VM should have no external connectivity.
If the instance has multiple interfaces attached, the interface needs to be explicitly mentioned:
$ openstack server set --property landb-internet-connectivity="INTERFACE_1_FQDN:true; INTERFACE_2_FQDN:false" ...
landb-set
Adds the VM interface to a LanDB Set:
Similar to landb-alias, you can specify the set for the additional interfaces and also multiple sets:
$ openstack server set --property landb-set="INTERFACE_1_FQDN:MY SET 1, MY SET 2;INTERFACE_2_FQDN:MY OTHER SET"
Note that your LanDB set needs to be configured to allow OpenStack to add/remove VM interfaces:
- The Set "Description" needs to include the OpenStack project that has access to the Set.
- Example:
OPENSTACK_PROJECT=MY_PROJECT_UUID
- Example:
- The egroup for the Set "Responsible" egroup needs to include the "openstack-landb-set-access" egroup as a member.
- It's your egroup that needs to include "openstack-landb-set-access". If you set the "openstack-landb-set-access" egroup directly as the Set responsible you lose access to the lanDB Set.
Notes
-
To update
landb-mainuserandlandb-responsiblefor an instance that is currently registered with an invalid value (ie. a user who has left CERN), please update both properties in a single command:$ openstack server set --property landb-mainuser=<new user name> --property landb-responsible=<new user name> <VM name>to avoid failures like: