> > We are close to the first milestone in Pike, right ? We also have > > priorities for Placement that we discussed at the PTG and we never > > discussed about how to cut placement during the PTG. > > > > Also, we haven't discussed yet with operators about how they would like > > to see Placement being cut. At least, we should wait for the Forum about > > that. > > > > For the moment, only operators using Ocata are using the placement API > > and we know that most of them had problems when using it. Running for > > cutting Placement in Queens would then mean that they would only have > > one stable cycle after Ocata for using it. > > Also, discussing at the above would then mean that we could punt other > > disucssions. For example, I'd prefer to discuss how we could fix the > > main problem we have with the scheduler about scheduler claims *before* > > trying to think on how to cut Placement. > > It's definitely good to figure out what challenges people were having in > rolling things out and document them, to figure out if they've been > addressed or not. One key thing seemed to be not understanding that > services need to all be registered in the catalog before services beyond > keystone are launched. There is also probably a keystoneauth1 fix for > this make it a softer fail. > > The cut over can be pretty seamless. Yes, upgrade scenarios need to be > looked at. But that's honestly not much different from deprecating > config options or making new aliases. It should be much less user > noticable than the newly required cells v2 support. > > The real question to ask, now that there is a well defined external > interface, will evolution of the Placement service stack, and addressing > bugs and shortcomings related to it's usage, work better as a dedicated > core team, or inside of Nova. My gut says Queens is the right time to > make that split, and to start planning for it now.
>From a downstream perspective, I'd prefer to see a concentration on deriving *user-visible* benefits from placement before incurring more churn with an extraction (given the proximity to the churn on deployment tooling from the scheduler decision-making cutover to placement at the end of ocata). Just my $0.02 ... Cheers, Eoghan __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
