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
