Open Stack

On Mon, 2021-11-15 at 10:21 +0000, Steven Relf wrote:
> Hello List,
> 
> I have the following situation and would be thankful for any help or suggestions.
> 
> We provide images to our customers, upon which we set the os_type metadata. We use this to help schedule instances to host aggregates, so we can control where certain OS's land. This works great for new instances, that are created from our images.
> 
> We have the following problems though.
> 
> 
>   1.  Instances created prior to the introduction of the os_type metadata existing on the image, this metadata is not flowed down, and as such these instances have NULL
This is the expected behaivor.
we snapshot/copy the image metadata at the time the instnace was created into the instance_system_metadata table to ensure the change to the image after the fact do
not affect existing vms.
>   2.  Instances created from a snapshot do not seem to get the os_type flowed down
>   3.  Instances imported using our migration tool do not end up with the os_type being set either.
likely because the meataddata was not set on the image or volume before the vm was created.
> 
> Currently the only way I can see to set os_type on an instance is to manually (yuk) update the database for each and every instance, which is missing it.
os_type on the instance is not used anymore and should not be set at all
https://github.com/openstack/nova/blob/master/nova/objects/instance.py#L170
the os_type filed in the instance tabel was replaced with the os_type filed in the image_metatdata
https://github.com/openstack/nova/blob/master/nova/objects/image_meta.py#L552-L555
which is stored in teh instance_system_metadata table in the db.


 
> 
> Does anyone have any ideas how this can be updated without manually modifying the database.
> 
> My second thought was to maybe make use of the instance metadata that you can set via the CLI or API, but then I run in to the issue that there is not a nova filter that is able to use instance metadata, and in my brief play with the code, it looks like (user) metadata is not passed in as part of the instance spec dict that is used to schedule instances.
we do have nova manage command that allow operators to set some fo the image metadata that coudl be extended to allow any image metadta to be set however the
operator would then be resposible for ensureing that the chagne to the metadata do not invalide the placment of the current vm or rectifying it if it would.

The only way i see to do this via the api would be a resize to same flavor which would update the flavor and image metadta and find a new host to move the vm to that is vaild
for the new requiremetns. we had discussed added a new recreate api for this usecase previously but the feedback was to just extend resize.
> 
> I was thinking of writing a custom filter, but I'm not sure how compliant it would be to have a function making a call to try and collect the instance metadata.
> 
> In summary, I need to solve two things.
> 
> 
>   1.  How do I set os_type on instances in a way that doesn't involve editing the database.
the only way to do this today would be a rebuild, a nova manage command would be inline with what we have done for machine_type.
allowing the image metadata to be change via an api is likely not approriate unless its a new instance action like recreate which would use the updated image
metadta and move the instance(optionally to the same host).
https://github.com/openstack/nova/commit/c70cde057d20bb2c05a133e52b9ec560bd792698

for now i think that is the best approch to take.
ensure that all image have the correct os_type set perhaps using a glance import plugin to also update update user submitted images
then via an sql script or a new nova manage command update all existing images.

>   2.  Or How can I use another piece of metadata that I can set via the api, which also is exposed to the filter scheduler.
you wont be able to use any metadata in the flavor or image since both are cahced at instance create.
you might be able to use server metadata or a server tag. there is no intree filetr however that would work.
in tree filters are not allwo to make api calls or RPC calls and should avoid making db queires in the filter.
the request spec does not currently contaien any instnace tag or server metadata https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L60-L116
as such there is no efficnet way to implement this as a custom filter.

> 
> Rgds
> Steve.
> 
> The future has already arrived. It's just not evenly distributed yet - William Gibson
>