Open Stack

Hi,

It is a good idea that we have such option.
Regarding the option name, I prefer enable_new_agents over start_new_agents
because new agent itself starts and is working even if it is disabled.

Akihiro

2015-03-06 17:35 GMT+09:00 Toshikazu Ichikawa
<ichikawa.toshikazu at lab.ntt.co.jp>:
> Hi,
>
>
>
> Here is my additional thought.
>
>
>
> Nova provides "/v2/{tenant_id}/os-services" API[3] which is to block
> scheduling for a service. Cinder also has "/v1/{tenant_id}/os-services"
> API[4]. When a service (nova-compute or cinder-volume) is disabled, the
> service is not selected to accomodate a new VM or volume by scheduler. This
> provides same concept as "admin_state_up=False" of Neutron. (Nova and Cinder
> calls a process "service," where Neutron calls it "agent.")
>
>
>
> The "enable_new_services" of Nova or Cinder is a config option included in
> nova.conf or cinder.conf. The user can't change it through API. (I don't
> think the user have to change it through API.) The default value is "true"
> which means it enables services by default. I believe it's good choice as
> only production environment requires to change it "false" with additional
> setup cost of each service.
>
>
>
> Therefore, I believe adding a config option such as "start_new_agents"
> (default: "true") to neutron's configuration provides consistent experience
> to operators to maintain nodes. The "true" value of "start_new_agents" makes
> the agent status of "admin_state_up" "true" at the addition of agent (this
> is current behavior). The "false" value makes it "false" for production
> environment(new).
>
>
>
> [3]
> http://developer.openstack.org/api-ref-compute-v2-ext.html#ext-os-services
>
> [4] you can call this one by CLI: "cinder service-enable/service-disable"
>
>
>
> Thanks,
>
> Kazu
>
>
>
> From: Toshikazu Ichikawa [mailto:ichikawa.toshikazu at lab.ntt.co.jp]
> Sent: Thursday, March 05, 2015 10:05 AM
> To: openstack-operators at lists.openstack.org
> Subject: [Openstack-operators] Adding network node (Neutron agents) and test
> before deploying customer resource
>
>
>
> Hi,
>
>
>
> I'm looking for the way to test a newly added network node by deploying test
> resource before any customer resource on the node is deployed. I've learned
> in this ML that Nova and Cinder has the setting of "enable_new_services" in
> each conf to disable the initial service status to archive this.
>
>
>
> My question is "Is there any function/configuration to do same thing for
> Neutron?"
>
> I know there is on-going bug fix to implement the function to block
> scheduling for Neutron agent[1].
>
> As mentioned here [2], this fix may enable only administrators deploy
> routers/dhcp-servers for test rather than having customer's one.
>
> However, the initial "admin_state_up" status of agent still remains "true"
> right after the agent or node is added.
>
> That means it still happens the customer routers/dhcp-servers are deployed
> the node before changing the status by manual.
>
> To resolve this, I believe a feature similar to "enable_new_services" of
> Nova/Cinder should be implemented to Neutron to change initial
> "admin_state_up" value.
>
> Do you know any existing function, blueprint or other approach to achieve
> same goal?
>
> Or, Is this the feature what you agree to want and should be proposed as a
> new blueprint?
>
> I'd like to have neutron operators comments and suggestions.
>
>
>
> [1] https://bugs.launchpad.net/neutron/+bug/1408488
>
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-January/054007.html
>
>
>
> Thanks,
>
> Kazu
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Akihiro Motoki <amotoki at gmail.com>