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 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev