On Wed, 2024-07-24 at 14:48 +0330, Mia smith wrote:
> 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.
the creation of the dap device did not change with the delegation to os.vif
the tap device is create by libvirt/qemu at the same time regardless of which approch we
took. what changed is we create the port in ovs before we define the domain when we delegate
to os-vif. in the older approch libvirt created the port in ovs after it created the tap.

>
> 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.
i see we have consdierd all flaovr based quotas as "soft deprecated" for several release
i say soft deprecated as we have dicusssed removing them several time spricicaly the
nic quotas but also the others but never had the time to do that.

in generally i would advise agaisnt using them as they are effectivly unmaintianed.
>
> 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?

in your specific case the only real option for you is db surgrery to directly remove the
falvor quota limit in the embeded flavor and allow your workload to naturly have that change
applied the next time the xml is regenerated.


there is no tool for that so you will directly need to update it in the db.
>
> On Wed, Jul 24, 2024 at 1:55 PM <smooney@redhat.com> wrote:
>
> > 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!
> >
> >