Open Stack

On Fri, 2019-01-18 at 10:40 -0800, Dan Smith wrote:
> > * There will be a second new microversion (probably in Train) that will 
> > enable move operations for server having resource aware ports. This 
> > microversion split will allow us not to block the create / delete 
> > support for the feature in Stein.
> > 
> > * The new microversions will act as a feature flag in the code. This 
> > will allow merging single use cases (e.g.: server create with one ovs 
> > backed resource aware port) and functionally verifying it before the 
> > whole generic create use case is ready and enabled.
> > 
> > * A nova-manage command will be provided to heal the port allocations 
> > without moving the servers if there is enough resource inventory 
> > available for it on the current host. This tool will only work online 
> > as it will call neutron and placement APIs.
> > 
> > * Server move operations with the second new microversion will 
> > automatically heal the server allocation.
> 
> I wasn't on this call, so apologies if I'm missing something important.
> 
> Having a microversion that allows move operations for an instance
> configured with one of these ports seems really terrible to me. What
> exactly is the point of that? To distinguish between Stein and Train
> systems purely because Stein didn't have time to finish the feature?
the intent of the second micro version was primarily discoverablity 
the option of have 1 vs 2 micro versions was discussed. no one really
pushed strongly for only one on the call so i think we  just converged
on two mainly becaue of the discoverablity aspect.
> 
> IMHO, we should really avoid abusing microversions for that sort of
> thing. I would tend to err on the side of "if it's not ready, then it's
> not ready" for Stein, but I'm sure the desire to get this in (even if
> partially) is too strong for that sort of restraint.
so dont merge it at all for stien and merge it all in train.
its an option, but yes i think a lot of people woudl like to see at least
some support in Stein. it would not be the only
nova feature that does not support move operations but maybe it will cause
operator more headache the it solves if we enable the feature with out move
support.
> 
> Can we not return 403 in Stein, since moving instances is disable-able
> anyway, and just make it work in Train? Having a new microversion with a
> description of "nothing changed except we finished a feature so you can
> do this very obscure thing now" seems like we're just using them as an
> experimental feature flag, which was definitely not the intent. I know
> returning 403 for "you can't do this right now" isn't *as* discoverable,
> but you kinda have to handle 403 for operations that could be disabled
> anyway, so...
ya i guess that is a fair point. microversions are not like neutrons api
extention, you cant mix and match micorverions in the same way.
in neutron the presence of the extension tell you the feature is availble and enabled.
the nova microversion just tell you the code support it not that its configured
so ya you would have to handel 403s if move operations were disabled even if
we had two microverions.
> 
> --Dan
>