On 03/13/2017 08:41 AM, Chris Dent wrote:
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
https://github.com/cdent/placement
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
simple.
* 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
small.
* 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
structures.
* 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."
Chris, great work on this over the weekend. It gives us some valuable
data points and information to consider about the split out of the
placement API. Really appreciate the effort.
A few things:
1) Definitely agree on the need to have the Nova-side stuff *not*
reference ovo objects for resource providers. We want the Nova side to
use JSON/dict representations within the resource tracker and scheduler.
This work can be done right now and isn't dependent on anything AFAIK.
2) The FaultWrapper stuff can also be handled relatively free of
dependencies. In fact, there is a spec around error reporting using
codes in addition to messages [1] that we could tack on the FaultWrapper
cleanup items. Basically, make that spec into a "fix up error handling
in placement API" general work item list...
3) While the split of the placement API is not the highest priority
placement item in Pike (we are focused on traits, ironic integration,
shared pools and then nested providers, in that order), I do think it's
worthwhile splitting the placement service out from Nova in Queens. I
don't believe that doing claims in the placement API is something that
needs to be completed before splitting out. I'll respond to Sylvain's
thread about this separately.
Thanks again for your efforts this weekend,
-jay
[1] https://review.openstack.org/#/c/418393/
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
