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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
