[Openstack-operators] [Fuel][Nova][Cinder] Operations: adding new nodes in "disabled" state, allowed for test tenant only
Bogdan Dobrelya
bdobrelia at mirantis.com
Fri Feb 27 11:43:03 UTC 2015
On 23.02.2015 15:13, Bogdan Dobrelya wrote:
> + [Fuel] tag
> + openstack-operators ML
>
> Joe Gordon joe.gordon0 at gmail.com
> Thu Dec 4 13:26:59 UTC 2014
>
>> On Wed, Dec 3, 2014 at 3:31 PM, Mike Scherbakov <mscherbakov at
>> mirantis.com>
>> wrote:
>
>>> Hi all,
>>> enable_new_services in nova.conf seems to allow add new compute nodes in
>>> disabled state:
>>>
>>>
>> https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L507-L508,
>>> so it would allow to check everything first, before allowing production
>>> workloads host a VM on it. I've filed a bug to Fuel to use this by
>> default
>>> when we scale up the env (add more computes) [1].
>>>
>>> A few questions:
>>>
>>> 1. can we somehow enable compute service for test tenant first? So
>>> cloud administrator would be able to run test VMs on the node, and
>> after
>>> ensuring that everything is fine - to enable service for all tenants
>>>
>>>
>
>> Although there may be more then one way to set this up in nova, this can
>> definitely be done via nova host aggregates. Put new compute services into
>> an aggregate that only specific tenants can access (controlled via
> scheduler filter).
>
> Looks reasonable, +1 for Nova host aggregates [0].
>
> There is still a question, though, about an enable_new_services
> parameter, cinder and other OpenStack services. It is not clear how to
> use this parameter from an operator perspective, for example:
> 1) While deploying or scaling the OpenStack environment, we should set
> enable_new_services=false for all services which support it.
Just a note, it looks like Nova doesn't honor the
enable_new_services=false setting [0].
[0] https://bugs.launchpad.net/nova/+bug/1426332
> 2) Once the deploy/scale is done, re-enable disabled services. But how
> exactly that should be done?
> * Set enable_new_services=True and restart the schedulers and conductor
> services? Or API services as well?
> * Keep enable_new_services=false in configs, but issue - for nova
> exmaple - 'nova-manage service enable ...' commands for added compute
> nodes? And what about cinder and other ones (there are no *-manage
> service enable commands)?
> * Some another way?
>
> And regarding plans for implementing this improvement in Fuel, I believe
> for nova computes it could be done as a workaround for the 6.1 release
> with the help of enable_new_services configuration parameter and a
> separate Fuel post-deploy granular task which should re-enable the
> disabled compute services. But this should be re-implemented later with
> separate host aggregate for deployment and health checks, see the
> related blueprint [1].
>
> [0]
> http://docs.openstack.org/havana/config-reference/content/host-aggregates.html
> [1] https://blueprints.launchpad.net/fuel/+spec/disable-new-computes
>
>>
>> 1.
>> 2. What about Cinder? Is there a similar option / ability?
>> 3. What about other OpenStack projects?
>>
>> What is your opinion, how we should approach the problem (if there is a
>> problem)?
>>
>> [1] https://bugs.launchpad.net/fuel/+bug/1398817
>> --
>> Mike Scherbakov
>> #mihgen
>>
>
--
Best regards,
Bogdan Dobrelya,
Skype #bogdando_at_yahoo.com
Irc #bogdando
More information about the OpenStack-operators
mailing list