Re: [openstack-dev] [Puppet] Proposed Change in Nova Service Defaults
I'd like them to default to enabled as well since it matches the other modules as you said. Was the intent here to allow bringing up new compute hosts without them being enabled? If so there's another flag that could be set to manage that state. As for the patch itself, we need to change it for all the other services in nova too, not just API. On Fri, May 29, 2015 at 8:20 AM, Richard Raseley rich...@raseley.com wrote: We are currently reviewing a patch[0] which will result in a change to the way Nova services are managed by default. Previously services were set to 'Disabled' by default, and had to be manually enabled in the manifests, this change will make the default value 'Enabled'. The consensus is that this will bring the Nova module more in-line with the other modules, but we understand this could result in some undesirable behavior for some implementations. If you have a strong opinion on the matter, or want to make sure your use-case is considered, please comment on the aforementioned review[0]. Regards, Richard Raseley System Operations Engineer @ Puppet Labs [0] - https://review.openstack.org/#/c/184656/ __ 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
Re: [openstack-dev] [Puppet] Proposed Change in Nova Service Defaults
Matt Fischer wrote: Was the intent here to allow bringing up new compute hosts without them being enabled? If so there's another flag that could be set to manage that state. Mathieu posited the following intent in the review: It was used in some active/passive setup (as stated in the bug report) where service state was managed by an external cluster/resource manager. I think it reasonable that people would manage the state of their nodes via the composition layer, but it is also reasonable that we might want to put an additional option in place. I'd love to hear more input on that. As for the patch itself, we need to change it for all the other services in nova too, not just API. Agreed. I will see if Matt wants to do that work and if not will be happy to do so over the weekend. __ 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-dev] [Puppet] Proposed Change in Nova Service Defaults
We are currently reviewing a patch[0] which will result in a change to the way Nova services are managed by default. Previously services were set to 'Disabled' by default, and had to be manually enabled in the manifests, this change will make the default value 'Enabled'. The consensus is that this will bring the Nova module more in-line with the other modules, but we understand this could result in some undesirable behavior for some implementations. If you have a strong opinion on the matter, or want to make sure your use-case is considered, please comment on the aforementioned review[0]. Regards, Richard Raseley System Operations Engineer @ Puppet Labs [0] - https://review.openstack.org/#/c/184656/ __ 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
