Open Stack

Hey Mike,

AFAIK, there's no bug/blueprint on LP.

The question I want to raise here is what will happen if I decide to
deploy a cluster with one compute without controllers? It looks like a
bad UX to me, though it may increase speed of CI gates where one node
with one role is enough.

Can we ignore the problem above and remove this limitation? Or should
we improve it somehow so it would work for one nodes, and will be
ignored for others?

Thanks,
Igor

On Wed, Oct 21, 2015 at 9:04 AM, Mike Scherbakov
<mscherbakov at mirantis.com> wrote:
> 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
>
> __________________________________________________________________________
> 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
>