[openstack-dev] [nova] [placement] experimenting with extracting placement
sean at dague.net
Mon Mar 13 13:21:03 UTC 2017
On 03/13/2017 09:16 AM, Sylvain Bauza wrote:
> Le 13/03/2017 13:41, Chris Dent a écrit :
>> From the start we've been saying that it is probably right for the
>> placement service to have its own repository. This is aligned with
>> the long term goal of placement being useful to many services, not
>> just nova, and also helps to keep placement contained and
>> comprehensible and thus maintainable.
>> I've been worried for some time that the longer we put this off, the
>> more complicated an extraction becomes. Rather than carry on
>> worrying about it, I took some time over the weekend to experiment
>> with a slapdash extraction to see if I could identify what would be
>> the sticking points. The results are here
>> My methodology was to lay in the basics for being able to run the
>> functional (gabbi) tests and then using the failures to fix the
>> code. If you read the commit log (there's only 16 commits) in
>> reverse it tells a little story of what was required.
>> All the gabbi tests are now passing (without them being changed)
>> except for four that verify the response strings from exceptions. I
>> didn't copy in exceptions, I created them anew to avoid copying
>> unnecessary nova-isms, and didn't bother (for now) with replicating
>> keyword handling.
>> Unit tests and non-gabbi functional tests were not transferred over
>> (as that would have been something more than "slapdash").
>> Some observations or things to think about:
>> * Since there's only one database and all the db query code is in
>> the objects, the database handling is simplified. olso_db setup
>> can be used more directly.
>> * The objects being oslo versioned objects is kind of overkill in
>> this context but doesn't get too much in the way.
>> * I collapsed the fields.ResourceClass and objects.ResourceClass
>> into the same file so the latter was renamed. Doing this
>> exploration made a lot of the ResourceClass handling look pretty
>> complicated. Much of that complexity is because we had to deal
>> with evolving through different functionality. If we built this
>> functionality in a greenfield repo it could probably be more
>> * The FaultWrapper middleware is turned off in the WSGI stack
>> because copying it over from nova would require dealing with a
>> hierarchy of classes. A simplified version of it would probably
>> need to be stuck back in (and apparently a gabbi test to exercise
>> it, as there's not one now).
>> * The number of requirements in the two requirements files is nicely
>> * The scheduler report client in nova, and to a minor degree the
>> filter scheduler, use some of the same exceptions and ovo.objects
>> that placement uses, which presents a bit of blechiness with
>> regards to code duplication. I suppose long term we could consider
>> a placement-lib or something like that, except that the
>> functionality provided by the same-named objects and exceptions
>> are not entirely congruent. From the point of view of the external
>> part of the placement API what matters are not objects, but JSON
>> * I've done nothing here with regard to how devstack would choose
>> between the old and new placement code locations but that will be
>> something to solve. It seems like it ought to be possible for two
>> different sources of the placement-code to exist; just register
>> one endpoint. Since we've declared that service discovery is the
>> correctly and only way to find placement, this ought to be okay.
>> I'm not sure how or if we want to proceed with this topic, but I
>> think this at least allows us to talk about it with less guessing.
>> My generally summary is "yeah, this is doable, without huge amounts
>> of work."
> Please don't.
> Having a separate repository would mean that deployers would need to
> implement a separate package for placement plus discussing about
> how/when to use it.
> For the moment, I'd rather prefer to leave operators using the placement
> API by using Nova first and then after like 3 or 4 cycles, possibly
> discussing with them how to cut it.
> At the moment, I think that we already have a good priority for
> placement in Nova, so I don't think it's a problem to still have it in Nova.
Given that the design was always to split (eventually), and part of that
means that we get to start building up a dedicated core team, I'm not
sure why waiting 3 or 4 additional cycles makes sense here.
I get that Pike is probably the wrong release to do this cut, given that
it only *just* became mandatory. But It feels like saying this would be
a Queens goal, and getting things structured in such a way that the
split is easy (like any renaming of binaries, any things that should
deprecate), would seem to be good goals for Pike.
More information about the OpenStack-dev