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.toshik...@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.toshik...@lab.ntt.co.jp] > Sent: Thursday, March 05, 2015 10:05 AM > To: openstack-operators@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Akihiro Motoki <amot...@gmail.com> _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators