Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
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
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
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. __ 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
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
Excerpts from Zane Bitter's message of 2015-02-03 10:00:44 -0800: > On 02/02/15 19:52, Steve Baker wrote: > > A spec has been raised to add a config option to allow operators to > > choose whether to use the new convergence engine for stack operations. > > For some context you should read the spec first [1] > > > > Rather than doing this, I would like to propose the following: > > I am strongly, strongly opposed to making this part of the API. > > > * Users can (optionally) choose which engine to use by specifying an > > engine parameter on stack-create (choice of classic or convergence) > > * Operators can set a config option which determines which engine to use > > if the user makes no explicit choice > > * Heat developers will set the default config option from classic to > > convergence when convergence is deemed sufficiently mature > > We'd also need a way for operators to prevent users from enabling > convergence if they're not ready to support it. > This would be relatively simple to do by simply providing a list of the supported stack versions. > > I realize it is not ideal to expose this kind of internal implementation > > detail to the user, but choosing convergence _will_ result in different > > stack behaviour (such as multiple concurrent update operations) so there > > is an argument for giving the user the choice. Given enough supporting > > documentation they can choose whether convergence might be worth trying > > for a given stack (for example, a large stack which receives frequent > > updates) > > It's supposed to be a strict improvement; we don't need to ask > permission. We have made major changes of this type in practically every > Heat release. When we switched from creating resources serially to > creating them in parallel in Havana we didn't ask permission. We just > did it. We when started allowing users to recover from a failed > operation in Juno we didn't ask permission. We just did it. We don't > need to ask permission to allow concurrent updates. We can just do it. > 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, and letting users fall back to the old one means that when things break they can solve their own problem while the operator and devs figure it out. The operator may know what is breaking their side, but they may have very little idea of what is happening on the end-user's side. > The only difference here is that we are being a bit smarter and > uncoupling our development schedule from the release cycle. There are 15 > other blueprints, essentially all of which have to be complete before > convergence is usable at all. It won't do *anything at all* until we are > at least 12 blueprints in. The config option buys us time to land them > without the risk of something half-finished appearing in the release > (trunk-chasers will also thank us). It has no other legitimate purpose IMO. > The config option only really allows an operator to go forward. If the users start expecting concurrent updates and resiliency, and then all their stacks are rolled back to the old engine because #reasons, this puts pressure on the operator. This will make operators delay the forward progress onto convergence for as long as possible. I'm also not entirely sure rolling the config option back to the old setting would even be possible without breaking any in-progress stacks. > The goal is IN NO WAY to maintain separate code paths in the long term. > The config option is simply a development strategy to allow us to land > code without screwing up a release and while maintaining as much test > coverage as possible. > Nobody plans to maintain the Keystone v2 domainless implementation forever too. But letting users consider domains and other v3 options for a while means that the ecosystem grows more naturally without giving up ground to instability. Once the v3 adoption rate is high enough, people will likely look at removing the old code because nobody uses it. In my opinion OpenStack has been far too eager to deprecate and remove things that users rely on, but I do think this will happen and should happen eventually. > > Operators likely won't feel they have enough knowledge to make the call > > that a heat install should be switched to using all convergence, and > > users will never be able to try it until the operators do (or the > > default switches). > > Hardly anyone should have to make a call. We should flip the default as > soon as all of the blueprints have landed (i.e. as soon as it works at
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
On 02/02/15 19:52, Steve Baker wrote: A spec has been raised to add a config option to allow operators to choose whether to use the new convergence engine for stack operations. For some context you should read the spec first [1] Rather than doing this, I would like to propose the following: I am strongly, strongly opposed to making this part of the API. * Users can (optionally) choose which engine to use by specifying an engine parameter on stack-create (choice of classic or convergence) * Operators can set a config option which determines which engine to use if the user makes no explicit choice * Heat developers will set the default config option from classic to convergence when convergence is deemed sufficiently mature We'd also need a way for operators to prevent users from enabling convergence if they're not ready to support it. I realize it is not ideal to expose this kind of internal implementation detail to the user, but choosing convergence _will_ result in different stack behaviour (such as multiple concurrent update operations) so there is an argument for giving the user the choice. Given enough supporting documentation they can choose whether convergence might be worth trying for a given stack (for example, a large stack which receives frequent updates) It's supposed to be a strict improvement; we don't need to ask permission. We have made major changes of this type in practically every Heat release. When we switched from creating resources serially to creating them in parallel in Havana we didn't ask permission. We just did it. We when started allowing users to recover from a failed operation in Juno we didn't ask permission. We just did it. We don't need to ask permission to allow concurrent updates. We can just do it. The only difference here is that we are being a bit smarter and uncoupling our development schedule from the release cycle. There are 15 other blueprints, essentially all of which have to be complete before convergence is usable at all. It won't do *anything at all* until we are at least 12 blueprints in. The config option buys us time to land them without the risk of something half-finished appearing in the release (trunk-chasers will also thank us). It has no other legitimate purpose IMO. The goal is IN NO WAY to maintain separate code paths in the long term. The config option is simply a development strategy to allow us to land code without screwing up a release and while maintaining as much test coverage as possible. Operators likely won't feel they have enough knowledge to make the call that a heat install should be switched to using all convergence, and users will never be able to try it until the operators do (or the default switches). Hardly anyone should have to make a call. We should flip the default as soon as all of the blueprints have landed (i.e. as soon as it works at all), provided that a release is not imminent. (Realistically, at this point I think we have to say the target is to do it as early as in Lizard as we can.) That means for those chasing trunk they get it as soon as it works at all, and for those using stable releases they get it at the next release, just like every other feature we have ever added. As a bonus, trunk-chasing operators who need to can temporarily delay enabling of convergence until a point of their choosing in the release cycle by overriding the default. Anybody in that position likely has enough knowledge to make the right call for them. So I believe that all of our stakeholders are catered to by the config option: operators & users who want a stable, tested release; operator/users who want to experiment on the bleeding edge; and operators who chase trunk but whose users require stability. The only group that benefits from enshrining the choice in the API - users who want to experiment with the bleeding edge, but who don't control their own OpenStack deployment - doesn't actually exist, and if it did then this would be among the least of their problems. Finally, there are also some benefits to heat developers. Creating a whole new gate job to test convergence-enabled heat will consume its share of CI resource. I'm hoping to make it possible for some of our functional tests to run against a number of scenarios/environments. Being able to run tests under classic and convergence scenarios in one test run will be a great help (for performance profiling too). I think this is the strongest argument in favour. However, I'd like to think it would be possible to run the functional tests twice in the gate, changing the config and restarting the engine in between. But if the worst comes to the worst, then although I think it's preferable to use one VM for twice as long vs. two VMs for the same length of time, I don't think the impact on resource utilisation in the gate of choosing one over the other is likely to be huge. And I don't see this situation persisting for a long
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
Excerpts from Angus Salkeld's message of 2015-02-03 02:40:44 -0800: > On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker wrote: > > > A spec has been raised to add a config option to allow operators to choose > > whether to use the new convergence engine for stack operations. For some > > context you should read the spec first [1] > > > > Rather than doing this, I would like to propose the following: > > * Users can (optionally) choose which engine to use by specifying an > > engine parameter on stack-create (choice of classic or convergence) > > * Operators can set a config option which determines which engine to use > > if the user makes no explicit choice > > * Heat developers will set the default config option from classic to > > convergence when convergence is deemed sufficiently mature > > > > I realize it is not ideal to expose this kind of internal implementation > > detail to the user, but choosing convergence _will_ result in different > > stack behaviour (such as multiple concurrent update operations) so there is > > an argument for giving the user the choice. Given enough supporting > > documentation they can choose whether convergence might be worth trying for > > a given stack (for example, a large stack which receives frequent updates) > > > > Operators likely won't feel they have enough knowledge to make the call > > that a heat install should be switched to using all convergence, and users > > will never be able to try it until the operators do (or the default > > switches). > > > > Finally, there are also some benefits to heat developers. Creating a whole > > new gate job to test convergence-enabled heat will consume its share of CI > > resource. I'm hoping to make it possible for some of our functional tests > > to run against a number of scenarios/environments. Being able to run tests > > under classic and convergence scenarios in one test run will be a great > > help (for performance profiling too). > > > > Hi > > I didn't have a good initial response to this, but it's growing on me. One > issue is the specific option that we expose, it's not nice having > a dead option once we totally switch over and remove "classic". So is it > worth coming up with a real feature that convergence-phase-1 enables > and use that (like enable-concurrent-updates). Then we need to think if we > would actually want to keep that feature around (as in > once "classic" is gone is it possible to maintain > "disable-concurrent-update"). > There are other features of convergence that will be less obvious. Having stack operations survive a restart of the engines is a pretty big one that one might have a hard time grasping, but will be appreciated by users. Also being able to push a bigger stack in will be a large benefit, though perhaps not one that is realized on day 1. Anyway, I'd prefer that they just be versioned, and not named. The names are too implementation specific. A v1 stack will be expected to work with v1 stack tested templates and parameters for as long as we support v1 stacks. A v2 stack will be expected to work similarly, but may act differently, and thus a user can treat this as another API update that they need to deal with. The features will be a force multiplier, but the recommendation of the team by removing the "experimental" tag will be the primary motivator. And for operators, when they're comfortable with new stacks all going to v2 they can enable that as the default. If they trust the Heat developers, they can just go to v2 as default when the Heat devs say so. Once we get all of the example templates to work with v2 and write some new v2-specific stacks, thats the time to write a migration tool and deprecate v1. So, to be clear, I'm fully in support of Steve Baker's suggestion to let the users choose which engine to use. However, I think we should treat it not as an "engine" choice, but as an "interface" choice. The fact that it takes a whole new engine to support the new features of the interface is the implementation detail that no end-user needs to care about. __ 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
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
I really like some benefits of this approach: - easy use in functional tests (did not require additional job) - every user can try from this moment - we can use both code ways in the same time without service restarting So I really close to give my +1, if someone give answers on questions from other side: - as Angus said, how we plan deprecate it then (when new code will become default) more softer for users? - As I understand the parameter option will have upper priority then config. so operator has not way to block it from users and they should decide themselves what they want (what is more safely)? (and of course choose new, because it sounds better) - I really afraid, that some users will start use new option and will be disappointed, due to they expect a lot of benefits, but the reality will be different. IMO, exposing so young feature looks cool for development part and gathering feedback, but dangerous for "stable" product users + bad example of commercial. If somebody help me to remove these doubts, I will be thankful to him :) Regards, Sergey. On 3 February 2015 at 03:52, Steve Baker wrote: > A spec has been raised to add a config option to allow operators to choose > whether to use the new convergence engine for stack operations. For some > context you should read the spec first [1] > > Rather than doing this, I would like to propose the following: > * Users can (optionally) choose which engine to use by specifying an > engine parameter on stack-create (choice of classic or convergence) > * Operators can set a config option which determines which engine to use > if the user makes no explicit choice > * Heat developers will set the default config option from classic to > convergence when convergence is deemed sufficiently mature > > I realize it is not ideal to expose this kind of internal implementation > detail to the user, but choosing convergence _will_ result in different > stack behaviour (such as multiple concurrent update operations) so there is > an argument for giving the user the choice. Given enough supporting > documentation they can choose whether convergence might be worth trying for > a given stack (for example, a large stack which receives frequent updates) > > Operators likely won't feel they have enough knowledge to make the call > that a heat install should be switched to using all convergence, and users > will never be able to try it until the operators do (or the default > switches). > > Finally, there are also some benefits to heat developers. Creating a whole > new gate job to test convergence-enabled heat will consume its share of CI > resource. I'm hoping to make it possible for some of our functional tests > to run against a number of scenarios/environments. Being able to run tests > under classic and convergence scenarios in one test run will be a great > help (for performance profiling too). > > If there is enough agreement then I'm fine with taking over and updating > the convergence-config-option spec. > > [1] https://review.openstack.org/#/c/152301/2/specs/kilo/ > convergence-config-option.rst > > __ > 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 > __ 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
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
On Tue, Feb 3, 2015 at 10:52 AM, Steve Baker wrote: > A spec has been raised to add a config option to allow operators to choose > whether to use the new convergence engine for stack operations. For some > context you should read the spec first [1] > > Rather than doing this, I would like to propose the following: > * Users can (optionally) choose which engine to use by specifying an > engine parameter on stack-create (choice of classic or convergence) > * Operators can set a config option which determines which engine to use > if the user makes no explicit choice > * Heat developers will set the default config option from classic to > convergence when convergence is deemed sufficiently mature > > I realize it is not ideal to expose this kind of internal implementation > detail to the user, but choosing convergence _will_ result in different > stack behaviour (such as multiple concurrent update operations) so there is > an argument for giving the user the choice. Given enough supporting > documentation they can choose whether convergence might be worth trying for > a given stack (for example, a large stack which receives frequent updates) > > Operators likely won't feel they have enough knowledge to make the call > that a heat install should be switched to using all convergence, and users > will never be able to try it until the operators do (or the default > switches). > > Finally, there are also some benefits to heat developers. Creating a whole > new gate job to test convergence-enabled heat will consume its share of CI > resource. I'm hoping to make it possible for some of our functional tests > to run against a number of scenarios/environments. Being able to run tests > under classic and convergence scenarios in one test run will be a great > help (for performance profiling too). > Hi I didn't have a good initial response to this, but it's growing on me. One issue is the specific option that we expose, it's not nice having a dead option once we totally switch over and remove "classic". So is it worth coming up with a real feature that convergence-phase-1 enables and use that (like enable-concurrent-updates). Then we need to think if we would actually want to keep that feature around (as in once "classic" is gone is it possible to maintain "disable-concurrent-update"). Regards Angus > > If there is enough agreement then I'm fine with taking over and updating > the convergence-config-option spec. > > [1] https://review.openstack.org/#/c/152301/2/specs/kilo/ > convergence-config-option.rst > > __ > 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 > __ 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
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
+1, that would ease the development and also drive adoption IMO, as people could start using/experimenting with it earlier, and more eyes == less bugs. You can never predict all the ways how users would use and abuse your new shiny feature :) Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com On Tue, Feb 3, 2015 at 6:48 AM, Robert Collins wrote: > I think incremental adoption is a great principle to have and this > will enable that. > > So +1 > > -Rob > > On 3 February 2015 at 13:52, Steve Baker wrote: > > A spec has been raised to add a config option to allow operators to > choose > > whether to use the new convergence engine for stack operations. For some > > context you should read the spec first [1] > > > > Rather than doing this, I would like to propose the following: > > * Users can (optionally) choose which engine to use by specifying an > engine > > parameter on stack-create (choice of classic or convergence) > > * Operators can set a config option which determines which engine to use > if > > the user makes no explicit choice > > * Heat developers will set the default config option from classic to > > convergence when convergence is deemed sufficiently mature > > > > I realize it is not ideal to expose this kind of internal implementation > > detail to the user, but choosing convergence _will_ result in different > > stack behaviour (such as multiple concurrent update operations) so there > is > > an argument for giving the user the choice. Given enough supporting > > documentation they can choose whether convergence might be worth trying > for > > a given stack (for example, a large stack which receives frequent > updates) > > > > Operators likely won't feel they have enough knowledge to make the call > that > > a heat install should be switched to using all convergence, and users > will > > never be able to try it until the operators do (or the default switches). > > > > Finally, there are also some benefits to heat developers. Creating a > whole > > new gate job to test convergence-enabled heat will consume its share of > CI > > resource. I'm hoping to make it possible for some of our functional > tests to > > run against a number of scenarios/environments. Being able to run tests > > under classic and convergence scenarios in one test run will be a great > help > > (for performance profiling too). > > > > If there is enough agreement then I'm fine with taking over and updating > the > > convergence-config-option spec. > > > > [1] > > > https://review.openstack.org/#/c/152301/2/specs/kilo/convergence-config-option.rst > > > > > __ > > 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 > > > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > __ > 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 > __ 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
Re: [openstack-dev] [heat] operators vs users for choosing convergence engine
I think incremental adoption is a great principle to have and this will enable that. So +1 -Rob On 3 February 2015 at 13:52, Steve Baker wrote: > A spec has been raised to add a config option to allow operators to choose > whether to use the new convergence engine for stack operations. For some > context you should read the spec first [1] > > Rather than doing this, I would like to propose the following: > * Users can (optionally) choose which engine to use by specifying an engine > parameter on stack-create (choice of classic or convergence) > * Operators can set a config option which determines which engine to use if > the user makes no explicit choice > * Heat developers will set the default config option from classic to > convergence when convergence is deemed sufficiently mature > > I realize it is not ideal to expose this kind of internal implementation > detail to the user, but choosing convergence _will_ result in different > stack behaviour (such as multiple concurrent update operations) so there is > an argument for giving the user the choice. Given enough supporting > documentation they can choose whether convergence might be worth trying for > a given stack (for example, a large stack which receives frequent updates) > > Operators likely won't feel they have enough knowledge to make the call that > a heat install should be switched to using all convergence, and users will > never be able to try it until the operators do (or the default switches). > > Finally, there are also some benefits to heat developers. Creating a whole > new gate job to test convergence-enabled heat will consume its share of CI > resource. I'm hoping to make it possible for some of our functional tests to > run against a number of scenarios/environments. Being able to run tests > under classic and convergence scenarios in one test run will be a great help > (for performance profiling too). > > If there is enough agreement then I'm fine with taking over and updating the > convergence-config-option spec. > > [1] > https://review.openstack.org/#/c/152301/2/specs/kilo/convergence-config-option.rst > > __ > 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 -- Robert Collins Distinguished Technologist HP Converged Cloud __ 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
[openstack-dev] [heat] operators vs users for choosing convergence engine
A spec has been raised to add a config option to allow operators to choose whether to use the new convergence engine for stack operations. For some context you should read the spec first [1] Rather than doing this, I would like to propose the following: * Users can (optionally) choose which engine to use by specifying an engine parameter on stack-create (choice of classic or convergence) * Operators can set a config option which determines which engine to use if the user makes no explicit choice * Heat developers will set the default config option from classic to convergence when convergence is deemed sufficiently mature I realize it is not ideal to expose this kind of internal implementation detail to the user, but choosing convergence _will_ result in different stack behaviour (such as multiple concurrent update operations) so there is an argument for giving the user the choice. Given enough supporting documentation they can choose whether convergence might be worth trying for a given stack (for example, a large stack which receives frequent updates) Operators likely won't feel they have enough knowledge to make the call that a heat install should be switched to using all convergence, and users will never be able to try it until the operators do (or the default switches). Finally, there are also some benefits to heat developers. Creating a whole new gate job to test convergence-enabled heat will consume its share of CI resource. I'm hoping to make it possible for some of our functional tests to run against a number of scenarios/environments. Being able to run tests under classic and convergence scenarios in one test run will be a great help (for performance profiling too). If there is enough agreement then I'm fine with taking over and updating the convergence-config-option spec. [1] https://review.openstack.org/#/c/152301/2/specs/kilo/convergence-config-option.rst __ 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
