Le 13/03/2017 14:59, Jay Pipes a écrit : > 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 >
To be honest, one of the things I think we're missing yet is a separate client that deployers would package so that Nova and other customer projects would use for calling the Placement API. At the moment, we have a huge amount of code in nova.scheduler.report module that does smart things and I'd love to see that being in a separate python package (maybe in the novaclient repo, or something else) so we could ask deployers to package *that only* The interest in that is that it wouldn't be a separate service project, just a pure client package at a first try, and we could see how to cut placement separately the cycle after that. -Sylvain > [1] https://review.openstack.org/#/c/418393/ > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
