[openstack-dev] [heat] operators vs users for choosing convergence engine
Clint Byrum
clint at fewbar.com
Fri Feb 6 17:13:16 UTC 2015
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.
More information about the OpenStack-dev
mailing list