+1 How about an undocumented config?
Trev On Thu, 2014-01-30 at 09:24 -0500, Matthew Farrellee wrote: > i imagine this is something that can be useful in a development and > testing environment, especially during the transition period from direct > to heat. so having the ability is not unreasonable, but i wouldn't > expose it to users via the dashboard (maybe not even directly in the cli) > > generally i want to reduce the number of parameters / questions the user > is asked > > best, > > > matt > > On 01/30/2014 04:42 AM, Dmitry Mescheryakov wrote: > > I agree with Andrew. I see no value in letting users select how their > > cluster is provisioned, it will only make interface a little bit more > > complex. > > > > Dmitry > > > > > > 2014/1/30 Andrew Lazarev <[email protected] > > <mailto:[email protected]>> > > > > Alexander, > > > > What is the purpose of exposing this to user side? Both engines must > > do exactly the same thing and they exist in the same time only for > > transition period until heat engine is stabilized. I don't see any > > value in proposed option. > > > > Andrew. > > > > > > On Wed, Jan 29, 2014 at 8:44 PM, Alexander Ignatov > > <[email protected] <mailto:[email protected]>> wrote: > > > > Today Savanna has two provisioning engines, heat and old one > > known as 'direct'. > > Users can choose which engine will be used by setting special > > parameter in 'savanna.conf'. > > > > I have an idea to give an ability for users to define > > provisioning engine > > not only when savanna is started but when new cluster is > > launched. The idea is simple. > > We will just add new field 'provisioning_engine' to 'cluster' > > and 'cluster_template' > > objects. And profit is obvious, users can easily switch from one > > engine to another without > > restarting savanna service. Of course, this parameter can be > > omitted and the default value > > from the 'savanna.conf' will be applied. > > > > Is this viable? What do you think? > > > > Regards, > > Alexander Ignatov > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > <mailto:[email protected]> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > <mailto:[email protected]> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
