[nova] Improvements in migration tracking via API

Sean Mooney smooney at redhat.com
Tue Jul 27 17:20:01 UTC 2021


On Tue, 2021-07-27 at 09:48 -0700, melanie witt wrote:
> On Tue, 27 Jul 2021, 18:07 +0200, Radosław Piliszek 
> <radoslaw.piliszek at gmail.com> wrote:
> > On Tue, Jul 27, 2021 at 12:59 PM Sean Mooney <smooney at redhat.com> wrote:
> 
> [snip]
> 
> > > > 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.
> > > in nova you cannot make any api chnage without a spec.
> > 
> > That's sensible. Only I could not find it written verbatim. Perhaps it
> > is, somewhere.
> 
> The docs aren't the easiest to navigate, unfortunately.
> 
> It is here, for your reference:
> 
> https://docs.openstack.org/nova/latest/contributor/blueprints.html
i normallly point people to the specs template

https://github.com/openstack/nova-specs/blob/master/specs/yoga-template.rst
   """
       Not all blueprints need a spec. For more information see https://docs.openstack.org/nova/latest/contributor/blueprints.html#specs
       ...
       But, API changes are held to a much higher level of scrutiny. As soon as an API change merges, we must assume it could be in production somewhere, and as such,
       we then need to support that API change forever. To avoid getting that wrong, we do want lots of details about API changes upfront.
   """
it does not state api changes require specs explcitly but it like to the same doc you provided that does.


> 
> 
> > All in all, thanks for the discussion, Melanie and Sean.
> > The spec, as I see it now, would entail:
> > - adding UUID filtering capability to /os-migrations (simple)
> > - adding UUID to the response of evacuate API (simple)
> 
> +1, sounds right to me.
> 
> -melwitt
> 





More information about the openstack-discuss mailing list