DPM resource Name and/or description field is used to map an OpenStack object to a DPM resource

[Andreas Scheuring]

Somehow a mapping between a DPM resource (e.g. partition or NIC) and the corresponding Openstack object (e.g. server or port) must be stored.

At the moment we're using
* The DPM partition name to store the OpenStakc instance UUID and the cpcsubset name
* The DPM NICs name to store the Neutron ports UUIDs and the description to store the cpcsubset name

Both values are of importance
* Openstack UUID - to map the dpm to the openstack object
* cpcsubset (host) name - to show to which cpcsubet a resource (instance, nic) belongs to.

The problem is, that an HMC user can easily change the name. We should rely on something different here!

For nova it could be the following attribute
# openstack instance show xxx

| OS-EXT-SRV-ATTR:instance_name | instance-00000015
-> this name smells like a libvirt name - maybe we can override and use it somehow with the DPM uuid and cpcsubset?

Or what about having a separate field at each DPM object that can be used for such purposes?

[Markus Zoeller (markus_z) (mzoeller)]

Using the HMC to change OpenStack managed partitions is an forbidden by-passing IMO. That's equivalent of using "virsh edit" on a KVM host to change KVM guest information.

Nevertheless, we might want to rethink the design here.

[Markus Zoeller (markus_z) (mzoeller)]

Doesn't block the release. No opinion on possible backports yet.

[Prabhat Ranjan (pranjank)]

Can we add one column in 'instances' table?
i.e. 'partition_uuid'

Probably this code should work

from nova.db.sqlalchemy import api
query = "ALTER TABLE instances ADD COLUMN partition_uuid VARCHAR(32)"
engine = api.get_engine()
res = engine.execute(query)

I tried reading value from 'services' table it worked fine.
e.g.
from nova.db.sqlalchemy import api
query = "select * from services"
engine = api.get_engine()
res = engine.execute(query)
row = res.fetchone()
LOG.debug("first row %(row)s"%{"row": row})

But still I have to try adding column.

[Andreas Scheuring (andreas-scheuring)]

Changing the nova table is not an option I guess. Nova takes care about them including upgrades and so on. Having a new column there might break upgrades for nova on systems where our code is installed.

The only option would be adding a new table that we maintain. But then we are responsible for doing upgrades...

I feel that the "OS-EXT-SRV-ATTR:instance_name" of Novas extended_server_attributes extension is the right place to store this information. Maybe there is also some other field

Alternatively we could check if we can reuse some other field of the DPM partition object (or request a new one that we could use)....

[Prabhat Ranjan (pranjank)]

I checked "OS-EXT-SRV-ATTR:instance_name" attribute is not storing into the database. It's something like creating at run time probably using id of instance.
1. https://ask.openstack.org/en/question/26295/how-does-nova-maps-the-display-name-of-vm-or-instance-in-openstack-to-instance-name-in-kvmesx-etc/
2. https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/extended_server_attributes.py#L49

Probably we can use follow.
In 'nova' database there is a table called 'instance_extra'.
mysql> show columns from instance_extra;
+-------------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+-------------+------+-----+---------+----------------+
| created_at | datetime | YES | | NULL | |
| updated_at | datetime | YES | | NULL | |
| deleted_at | datetime | YES | | NULL | |
| deleted | int(11) | YES | | NULL | |
| id | int(11) | NO | PRI | NULL | auto_increment |
| instance_uuid | varchar(36) | NO | MUL | NULL | |
| numa_topology | text | YES | | NULL | |
| pci_requests | text | YES | | NULL | |
| flavor | text | YES | | NULL | |
| vcpu_model | text | YES | | NULL | |
| migration_context | text | YES | | NULL | |
| keypairs | text | YES | | NULL | |
| device_metadata | text | YES | | NULL | |
+-------------------+-------------+------+-----+---------+----------------+
13 rows in set (0.00 sec)

My suggestion is we can use column 'device_metadata'.

[Prabhat Ranjan (pranjank)]

That is basically 'instance.device_metadata'. And it will be very easy to use.

[Andreas Scheuring (andreas-scheuring)]

I see - the instance_name is generated along the "instance_name_template" config option, where the id is a counter that gets increased by nova -> the name instance000001 is generated by nova and not by virsh)

Regarding "device_metadata": I guess we need to first figure out what this field was intended for...

It seems like the name of an instance can be generated based on every instance property as well [1]. But not sure which one to use...

What about requesting that we can set the object-id on partition creation in DPM? Then we could set the object-id = uuid of instance.

Maybe we need to get Markus involved here - he might have more Nova insights....

[1] https://github.com/openstack/nova/blob/15.0.0.0rc2/nova/objects/instance.py#L295

[Prabhat Ranjan (pranjank)]

According to Preethi we can not modify 'object-id'. Otherwise we would have done it earlier.

[Andreas Scheuring (andreas-scheuring)]

My point is if we should Request that feature from the DPM team...

[Prabhat Ranjan (pranjank)]

There is a table 'instance_metadata' in 'nova' database. I think this is the table which is made for such purpose.
https://wiki.openstack.org/wiki/Trove-Instance-Metadata

Basically 'instance.metadata' in instance.

[Andreas Scheuring (andreas-scheuring)]

Setting to medium along our discussion in the meeting...