Open Stack

On 03/13/2017 10:02 AM, Eoghan Glynn wrote:
>>> 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).

The scheduler decision-making cutover *was* a user-visible benefit from 
the placement service. :)

Just because we could have done a better job with functional integration 
testing and documentation of the upgrade steps doesn't mean we should 
slow down progress here. We've learned lessons in Ocata around the need 
to be in a tighter feedback loop with the deployment teams.

Sean (and I) are merely suggesting to get the timeline for a split-out 
hammered out and ready for Queens so that we get ahead of the game and 
actually plan meetings with deployment folks and make sure docs and 
tests are proper ahead of the split-out.

That said, as mentioned in the previous email, the priorities for Pike 
(and likely Queens) will continue to be, in order: traits, ironic, 
shared resource pools, and nested providers.

Best,
-jay