Open Stack

On Mon, Jul 26, 2021 at 10:36 PM melanie witt <melwittt at gmail.com> wrote:
>

Hello Melanie,

First of all, thank you for your response.

> On Sun, 25 Jul 2021, 18:39 +0200, Radosław Piliszek
> <radoslaw.piliszek at gmail.com> wrote:
> > Sorry for the premature send. I include extra missed details below.
> >
> > On Sun, Jul 25, 2021 at 6:36 PM Radosław Piliszek
> > <radoslaw.piliszek at gmail.com> wrote:
> >>
> >> Dears,
> >>
> >> In Masakari we have a spec [0] to track the issued evacuations.
> >> It could greatly use having more insight into the migrations details
> >> that Nova saves in its database.
> >> It seems there are two issues here.
> >> One is quite cosmetic one, in that Nova API does not allow getting
> >> migrations by UUID but just ID [1] (while UUIDs seem to be called the
> >> future and the internal objects support them as well).
> >> I think this one can be easily tackled by making that endpoint [1]
> >> more flexible.
>
> Note that you would also have to change the API to allow showing a
> migration that is not of migration_type "live-migration". Currently it
> only allows showing an in-progress live migration.

Ah, I see the description. But I am pretty sure I got it to retrieve
an arbitrary ID migration though. But the relevant listing was
filtered for sure. Could you confirm that?
Should we treat that as a bug then? I hope not because I wanted to
rely on it. :-)

> >> The other issue is a more complex one, but still not introducing a
> >> great deal of change to Nova, and it is that the Nova API returns
> >> neither migration ID nor UUID when asked to evacuate an instance [2]
> >> (to be more general, it does not do it for migrations and live
> >> migrations either).
> >
> > So my idea would be to extend the API response here to include the
> > migration UUID which is all we would need.
> > It seems the Migration object is created and saved on request so it's
> > only a matter of wiring it up.
>
> You are correct that the Migration object is written to the database
> before the API response occurs, so it would be technically possible to
> add UUID to the response in a new API microversion.

Thank you for confirming.

> >> It seems, otherwise, we would have to call the
> >> listing API [3] and find the latest entry there but this is possibly
> >> error-prone and wasting resources.
>
> You wouldn't have to use/assume the latest entry because you can pull
> the evacuations for a server using:
>
> GET
> http://192.168.33.10/compute/v2.1/os-migrations?instance_uuid=f1aece4e-e7f7-436b-9faf-799129503dcc&migration_type=evacuation

Yeah, I meant to use that endpoint. It is highly unlikely that we have
another evacuation in between but still it's less reliable than just
getting the UUID directly.


To sum up, since this is introducing a new API microversion, the next
step for me is to create a Nova spec, right?
I read https://docs.openstack.org/nova/latest/contributor/microversions.html
but it was not clear to me whether some changes could do a new API
microversion without speccing it all up upfront or not.

-yoctozepto


> HTH,
> -melwitt
>
> > And here I was going to ask you, Nova cores, for your insights and opinions.
> > So here I am doing it now. ;-)
> >
> > Again, sorry for the premature send.
> >
> >> [0] https://review.opendev.org/c/openstack/masakari-specs/+/789432
> >> [1] https://docs.openstack.org/api-ref/compute/?expanded=show-migration-details-detail#show-migration-details
> >> [2] https://docs.openstack.org/api-ref/compute/?expanded=evacuate-server-evacuate-action-detail#evacuate-server-evacuate-action-detail
> >> [3] https://docs.openstack.org/api-ref/compute/?expanded=id312-detail#id312-detail
> >>
> >> -yoctozepto
> >
> > -yoctozepto
> >
>