Hi all, is there a plan to remove this restriction permanently? Any bug/blueprint covering it?
On Tue, Oct 20, 2015 at 5:07 AM Patrick Petit <ppe...@mirantis.com> wrote: > Hi Matthew, > > That’s useful. > Thanks > > On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (mmoses...@mirantis.com) > wrote: > > Hi Patrick, > > During the 7.0 development cycle we made a lot of enhancements to what > environment characteristics can be modified through a plugin. One item that > plugins cannot directly modify is the default Fuel roles and their > metadata. That having been said, there is an open-ended post_install.sh > script you can use for your plugin to "hack" this value. I know of one > project that currently disables the requirement for controller role in a > deployment. This may be helpful in testing a given standalone role that > doesn't depend on a controller. > > Here's a link to the script: http://paste.openstack.org/show/476821/ > Note that this doesn't reflect "enabled" status of a plugin. It will make > controller min count 0 for all environments. That won't break them, but it > just removes the restriction. > > Best Regards, > Matthew Mosesohn > > On Mon, Oct 19, 2015 at 3:29 PM, Dmitry Mescheryakov < > dmescherya...@mirantis.com> wrote: > >> Hello folks, >> >> I second Patrick's idea. In our case we would like to install standalone >> RabbitMQ cluster with Fuel reference architecture to perform destructive >> tests on it. Requirement to install controller is an excessive burden in >> that case. >> >> Thanks, >> >> Dmitry >> >> 2015-10-19 13:44 GMT+03:00 Patrick Petit <ppe...@mirantis.com>: >> >>> Hi There, >>> >>> There are situations where we’d like to deploy only Fuel plugins in an >>> environment. >>> That’s typically the case with Elasticsearch and InfluxDB plugins of LMA >>> tools. >>> Currently it’s not possible because you need to at least have one >>> controller. >>> What exactly is making that limitation? How hard would it be to have it >>> removed? >>> >>> Thanks >>> Patrick >>> >>> >>> __________________________________________________________________________ >>> 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 >> >> > __________________________________________________________________________ > 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 > -- Mike Scherbakov #mihgen
__________________________________________________________________________ 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
