Open Stack

On 13/07, Nguyễn Hữu Khôi wrote:
> hello.
> Thank you for your valuable information, I got this problem.
> Can you help me see how nova will be updated? I ask about something which I
> can touch or modify at nova manually,
>
> Nguyen Huu Khoi
>

Hi,

This is not something that can be easily fixed in the OpenStack code.

There's always the manual hacking mechanism of changing things manually
in libvirt using virsh without Nova knowing about it.  I don't know the
exact commands to run because I work on Cinder, but it's probably
related to this old spec [1].

Making the code changes in OpenStack is non trivial, as it would
require:

- Add a new external event type to the Nova code to change the QoS for
  an instance.

- Changing Cinder to do the following when QoS is updated:

    - Check volume types that use the updated QoS
    - Check volumes using those volume types
    - Check which volumes are connected to instances
    - For each of those volumes:
      - Update the connection information in the DB
      - Call Nova with the new external event type to update the
        instance.
      - If it's multi attached it may require making multiple calls
        for the same volume.

Cheers,
Gorka.

[1]: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/enhanced-kvm-storage-qos.html

>
> On Thu, Jul 13, 2023 at 5:10 PM Gorka Eguileor <geguileo at redhat.com> wrote:
>
> > On 27/06, Nguyễn Hữu Khôi wrote:
> > > Hello guys.
> > > I am trying to use cinder qos.
> > > But i have question.
> > > - I added qos after a volume was create and I see that qos did not apply
> > to
> > > this volume.
> > > - i create new volume with assosiate qos then it is ok but when i changed
> > > extra specs in qos, volume keep old specs.
> > > Is there any way to make qos apply with two above cases.
> > > Many thanks.
> >
> > Hi,
> >
> > I'm surprised you can even do it, I would expect this would be similar
> > to changing a volume type when there's already a volume using it, which
> > is not allowed.
> >
> > I assume you are using 'front-end' or 'both' QoS provider, because the
> > situation is even worse for 'back-end' QoS providers.
> >
> > For front-end qos the values will NOT be updated in Nova until a new
> > attachment is created, but it must be one that creates new connection
> > information.
> >
> > Changing that would be a new feature requiring changes in Cinder and
> > Nova, since Cinder would need to go through all the volumes that use
> > volumes types associated with that QoS, check which ones are currently
> > attached, update their connection_information in the cinder DB, and then
> > report to Nova the new values (this API doesn't exist).
> >
> > For back-end QoS it would be driver dependent. I assume in most cases a
> > retype would be necessary, but in some drivers they may be updating the
> > QoS on the backed for all volumes once a new volume with that volume
> > type or QoS is created.
> >
> > Cheers,
> > Gorka.
> >
> >
> >