[openstack-dev] [Fuel] Cluster reconfiguration scenarios

Dmitriy Shulyak dshulyak at mirantis.com
Tue Oct 7 15:41:33 UTC 2014


We are definitely able to parse all this information at the time of
deployment and generate deployment info
accordingly, but my idea was that additional status will provide more
visibility for operator.
It just wont be obivious - you added controllers/ceph-osd and suddenly your
computes/controllers are in deployment mode.

On Tue, Oct 7, 2014 at 6:17 PM, Evgeniy L <eli at mirantis.com> wrote:

> Hi,
>
> I'm not sure if we should add the new state in this case, it looks like
> you can get this
> information dynamically, you already have the state of env which tells you
> that
> there are new ceph nodes, and there are no ready ceph nodes in the cluster
> hence you should install ceph-mon on the controllers.
>
> The same for rabbitmq, if there is new controller, run rabbit
> reconfiguration on
> non-controllers nodes.
>
> Thanks,
>
> On Tue, Oct 7, 2014 at 6:14 PM, Dmitriy Shulyak <dshulyak at mirantis.com>
> wrote:
>
>> Hi folks,
>> I want to discuss cluster reconfiguration scenarios, i am aware of 2 such
>> bugs:
>>
>> - ceph-mon not installed on controllers if cluster initially was deployed
>> without ceph-osd
>> - config with rabbitmq hosts not updated on non-controlles nodes after
>> additional controllers is added to cluster [1]
>>
>> In both cases we need to track node state and change it accordingly to
>> some event
>> (additonal ceph-osd, additional controller added to cluster, etc..).
>> I think that it is generic scenario and our api should support such
>> modifications.
>>
>> To track state of node we need to introduce new state - something in
>> lines of "requires_update".
>> And extend deployment selection logic to include nodes with this state,
>> if deploy action will be invoked.
>>
>> What do you think about such feature? I would be grateful for any other
>> cases.
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1368445
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141007/f5eca1cd/attachment.html>


More information about the OpenStack-dev mailing list