Excerpts from Zane Bitter's message of 2015-02-06 06:25:57 -0800:
> On 03/02/15 14:12, Clint Byrum wrote:
> > The visible change in making things parallel was minimal. In talking
> > about convergence, it's become clear that users can and should expect
> > something radically different when they issue stack updates. I'd love to
> > say that it can be done to just bind convergence into the old ways, but
> > doing so would also remove the benefit of having it.
> >
> > Also allowing resume wasn't a new behavior, it was fixing a bug really
> > (that state was lost on failed operations). Convergence is a pretty
> > different beast from the current model,
> That's not actually the case for Phase 1; really nothing much should 
> change from the user point of view, except that if you issue an update 
> before a previous one is finished then you won't get an error back any more.
> In any event, I think Angus's comment on the review is correct, we 
> actually have two different problems here. One is how to land the code, 
> and a config option is indisputably the right choice here: until many, 
> many blueprints have landed then the convergence code path will do 
> literally nothing at all. There is no conceivable advantage to users for 
> opting in to that.
> The second question, which we can continue to discuss, is whether to 
> allow individual users to opt in/out once operators have enabled the 
> convergence flow path. I'm not convinced that there is anything 
> particular special about this feature that warrants such a choice more 
> than any other feature that we have developed in the past. However, I 
> don't think we need to decide until around the time that we're preparing 
> to flip the default on. By that time we should have better information 
> about the level of stability we're dealing with, and we can get input 
> from operators on what kind of additional steps we should take to 
> maintain stability in the face of possible regressions.

All good points and it seems like a plan is forming that will help
operators deploy rapidly without forcing users to scramble too much.

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to