Open Stack

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.

cheers,
Zane.