Open Stack

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 <ppetit at mirantis.com> wrote:

> Hi Matthew,
>
> That’s useful.
> Thanks
>
> On 20 Oct 2015 at 11:22:07, Matthew Mosesohn (mmosesohn at 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 <
> dmescheryakov at 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 <ppetit at 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-request at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151021/37e39f64/attachment.html>