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

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:

$ openstack server unset --property key=value <VM name>

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: that 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 in stead.

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

A User name or e-group name. The person responsible for the virtual machine. The syntax is as for mainuser.

Important: the LanDB-responsible will be notified of all the possible interventions that could affect your instance.

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:

$ openstack server set --property landb-alias="alias1,alias2,alias3" ...

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: if not specified, the alias domain defaults to ".cern.ch". The alias domain needs to be the same as the interface."

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.

Note: if you remove the property "landb-alias", all the alias from all the interfaces of the instance will be removed.

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 false if 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-domain

Allows to change the DNS domain of an attached interface:

$ openstack server set --property landb-domain="INTERFACE_HOSTNAME_1"."NEW_DOMAIN_NAME" ...

If you would like to change the domain of multiple interfaces use ";" to separate them. If an entry is removed from the list the interface will be moved back to the ".cern.ch" domain.

landb-set

Adds the VM interface to a LanDB Set:

$ openstack server set --property landb-set="MY 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
• 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-mainuser and landb-responsible for 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:

$ openstack server set --property landb-responsible=my-e-group-name my-vm
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
<class 'nova.exception.CernLanDBUpdate'> (HTTP 500) (Request-ID: req-7f50bb27-b9e7-4821-8a9d-da991525174d)