Re: [openstack-dev] [api] Re: [Neutron][L3] Stop agent scheduling without topping sevices
On Jan 9, 2015, at 8:15 AM, Jay Pipes jaypi...@gmail.com wrote: Adding [api] topic. On 01/08/2015 07:47 PM, Kevin Benton wrote: Is there another openstack service that allows this so we can make the API consistent between the two when this change is made? Kevin, thank you VERY much for asking the above question and caring about consistency in the APIs! There was a discussion on the ML about this very area of the APIs, and how there is current inconsistency to resolve: http://openstack-dev.openstack.narkive.com/UbM1J7dH/horizon-all-status-vs-state You were involved in that thread, so I know you're very familiar with the problem domain :) In the above thread, I mentioned that this really was something that the API WG should tackle, and this here ML thread should be a catalyst for getting that done. What we need is a patch proposed to the openstack/api-wg that proposes some guidelines around the REST API structure for disabling some resource for administrative purposes, with some content that discusses the semantic differences between state and status, and makes recommendations on the naming of resource attributes that indicate an admnistrative state. Of course, this doesn't really address Jack M's question about whether there should be a separate mode (in Jack's terms) to indicate that some resource can be only manually assigned and not automatically assigned. Personally, I don't feel there is a need for another mode. I think if something has been administratively disabled, that an administrator should still be able to manually alter that thing. All the best, -jay I did some preliminary analysis of the current design on state vs status. https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/State_vs_Status So far it doesn’t get into the semantics but identifies which services use state and/or status and counts up how many calls use such a param. Please feel free to add to the analysis. Thanks, Everett __ 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] [api] Re: [Neutron][L3] Stop agent scheduling without topping sevices
Hi all, I think we just power the scheduler API to be able to add and remove candidates is enough. As mentioned this thread, the agent just doesn't receive new request but still keep old service alive. So, just stop schedule new request to it. Direct and simple. Hope my expression is clear enough. Germy On Fri, Jan 9, 2015 at 10:15 PM, Jay Pipes jaypi...@gmail.com wrote: Adding [api] topic. On 01/08/2015 07:47 PM, Kevin Benton wrote: Is there another openstack service that allows this so we can make the API consistent between the two when this change is made? Kevin, thank you VERY much for asking the above question and caring about consistency in the APIs! There was a discussion on the ML about this very area of the APIs, and how there is current inconsistency to resolve: http://openstack-dev.openstack.narkive.com/UbM1J7dH/horizon-all-status- vs-state You were involved in that thread, so I know you're very familiar with the problem domain :) In the above thread, I mentioned that this really was something that the API WG should tackle, and this here ML thread should be a catalyst for getting that done. What we need is a patch proposed to the openstack/api-wg that proposes some guidelines around the REST API structure for disabling some resource for administrative purposes, with some content that discusses the semantic differences between state and status, and makes recommendations on the naming of resource attributes that indicate an admnistrative state. Of course, this doesn't really address Jack M's question about whether there should be a separate mode (in Jack's terms) to indicate that some resource can be only manually assigned and not automatically assigned. Personally, I don't feel there is a need for another mode. I think if something has been administratively disabled, that an administrator should still be able to manually alter that thing. All the best, -jay On Thu, Jan 8, 2015 at 3:09 PM, Carl Baldwin c...@ecbaldwin.net mailto:c...@ecbaldwin.net wrote: I added a link to @Jack's post to the ML to the bug report [1]. I am willing to support @Itsuro with reviews of the implementation and am willing to consult if you need and would like to ping me. Carl [1] https://bugs.launchpad.net/neutron/+bug/1408488 On Thu, Jan 8, 2015 at 7:49 AM, McCann, Jack jack.mcc...@hp.com mailto:jack.mcc...@hp.com wrote: +1 on need for this feature The way I've thought about this is we need a mode that stops the *automatic* scheduling of routers/dhcp-servers to specific hosts/agents, while allowing manual assignment of routers/dhcp-servers to those hosts/agents, and where any existing routers/dhcp-servers on those hosts continue to operate as normal. The maintenance use case was mentioned: I want to evacuate routers/dhcp-servers from a host before taking it down, and having the scheduler add new routers/dhcp while I'm evacuating the node is a) an annoyance, and b) causes a service blip when I have to right away move that new router/dhcp to another host. The other use case is adding a new host/agent into an existing environment. I want to be able to bring the new host/agent up and into the neutron config, but I don't want any of my customers' routers/dhcp-servers scheduled there until I've had a chance to assign some test routers/dhcp-servers and make sure the new server is properly configured and fully operational. - Jack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org 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
[openstack-dev] [api] Re: [Neutron][L3] Stop agent scheduling without topping sevices
Adding [api] topic. On 01/08/2015 07:47 PM, Kevin Benton wrote: Is there another openstack service that allows this so we can make the API consistent between the two when this change is made? Kevin, thank you VERY much for asking the above question and caring about consistency in the APIs! There was a discussion on the ML about this very area of the APIs, and how there is current inconsistency to resolve: http://openstack-dev.openstack.narkive.com/UbM1J7dH/horizon-all-status-vs-state You were involved in that thread, so I know you're very familiar with the problem domain :) In the above thread, I mentioned that this really was something that the API WG should tackle, and this here ML thread should be a catalyst for getting that done. What we need is a patch proposed to the openstack/api-wg that proposes some guidelines around the REST API structure for disabling some resource for administrative purposes, with some content that discusses the semantic differences between state and status, and makes recommendations on the naming of resource attributes that indicate an admnistrative state. Of course, this doesn't really address Jack M's question about whether there should be a separate mode (in Jack's terms) to indicate that some resource can be only manually assigned and not automatically assigned. Personally, I don't feel there is a need for another mode. I think if something has been administratively disabled, that an administrator should still be able to manually alter that thing. All the best, -jay On Thu, Jan 8, 2015 at 3:09 PM, Carl Baldwin c...@ecbaldwin.net mailto:c...@ecbaldwin.net wrote: I added a link to @Jack's post to the ML to the bug report [1]. I am willing to support @Itsuro with reviews of the implementation and am willing to consult if you need and would like to ping me. Carl [1] https://bugs.launchpad.net/neutron/+bug/1408488 On Thu, Jan 8, 2015 at 7:49 AM, McCann, Jack jack.mcc...@hp.com mailto:jack.mcc...@hp.com wrote: +1 on need for this feature The way I've thought about this is we need a mode that stops the *automatic* scheduling of routers/dhcp-servers to specific hosts/agents, while allowing manual assignment of routers/dhcp-servers to those hosts/agents, and where any existing routers/dhcp-servers on those hosts continue to operate as normal. The maintenance use case was mentioned: I want to evacuate routers/dhcp-servers from a host before taking it down, and having the scheduler add new routers/dhcp while I'm evacuating the node is a) an annoyance, and b) causes a service blip when I have to right away move that new router/dhcp to another host. The other use case is adding a new host/agent into an existing environment. I want to be able to bring the new host/agent up and into the neutron config, but I don't want any of my customers' routers/dhcp-servers scheduled there until I've had a chance to assign some test routers/dhcp-servers and make sure the new server is properly configured and fully operational. - Jack ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kevin Benton ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
