On 03/13/2017 09:33 AM, Sylvain Bauza wrote: <snip> > > 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. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ 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