Hi Akihiro, Thanks for your comment. I agree your suggestion of the name.
Thanks, Kazu -----Original Message----- From: Akihiro Motoki [mailto:[email protected]] Sent: Friday, March 06, 2015 7:07 PM To: Toshikazu Ichikawa Cc: [email protected] Subject: Re: [Openstack-operators] Adding network node (Neutron agents) and test before deploying customer resource 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 <[email protected]>: > 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-serv > ices > > [4] you can call this one by CLI: "cinder service-enable/service-disable" > > > > Thanks, > > Kazu > > > > From: Toshikazu Ichikawa [mailto:[email protected]] > Sent: Thursday, March 05, 2015 10:05 AM > To: [email protected] > 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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operator > s > -- Akihiro Motoki <[email protected]> _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
