Thank you for taking the time to respond to my query. I completely understand. We initially managed instance traffic by setting the bandwidth quota property in the flavor to be handled by Libvirt. However, after upgrading from the Wallaby version to Xena, and with the attaching port now delegated to the os-vif project, we encountered issues. At high load on the compute node, any action that generates or re-generates the instance XML can result in a TC error if the tap interface is created later than expected.
As a result, we had to switch to using Neutron policies and remove the bandwidth quota properties from all flavors. Additionally, we needed to update the instance_extra table for all active instances to remove these properties. This ensures that during the next hard reboot initiated by the client, the changes are applied.
Given the number of instances in the cluster, we do not enforce a policy that requires clients to resize to a new flavor. In such situations, what would you recommend as the best approach?
On Wed, 2024-07-24 at 13:27 +0330, Mia smith wrote:
> Hello OpenStack Community,
>
> In our OpenStack cluster, we recently updated some flavor properties. As a
> result, we need to apply these changes to all currently active instances
> that were created with the old flavor properties. We are looking for a
> solution that allows us to update these instance properties without causing
> any downtime or needing to resize the instances.
that is not supproted by nova.
when an instnace is created we create a copy of the flavor used at the time it was created
to ensure that if an operator ever changes the flavor extra specs it does not break
existing instnaces.
its is considered best practice to never modify the extra specs of a flavor once
that flavor is in use.
>
> Could anyone provide suggestions on how to achieve this? Is there a
> recommended method or ad-hoc command that can be used to safely update the
> properties directly in the database?
the recommended method is to create new flavors with the new properties and then work with the workload
owner to have them resize the instances.
the only way to do this today beyond that is to modify the embded copy in the db.
doing so will not impact the runnign isntance but it will take effect the next time the instnace is
hard rebooted, cold migrated or shelvede and unshled.
note that dependong on what you change you could create an invalid isntance that conflict with the image
properties. you could also create an instance that is involad for the current host based on scheduler
filters.
this is why we do not support in place update of this for existing instance as it invalidates all previous schduling
descisons and may result in differnt resource usage leading to hard to diagnose, seemingly unrelatated failures.
resizeing to a new flavor is the only safe method but that obviously has instnace downtime which is why
we recommend you never modify flavor extra specs if instance are using the flavor.
>
> Thank you for your assistance!