Open Stack

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