Open Stack

Hi Akihiro,

Thanks for your comment.
I agree your suggestion of the name.

Thanks,
Kazu

-----Original Message-----
From: Akihiro Motoki [mailto:amotoki at gmail.com] 
Sent: Friday, March 06, 2015 7:07 PM
To: Toshikazu Ichikawa
Cc: openstack-operators at lists.openstack.org
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
<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-serv
> ices
>
> [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-operator
> s
>



--
Akihiro Motoki <amotoki at gmail.com>