Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-08 Thread Kevin Benton
Is there another openstack service that allows this so we can make the API
consistent between the two when this change is made?

On Thu, Jan 8, 2015 at 3:09 PM, Carl Baldwin 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 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
  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




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-08 Thread Carl Baldwin
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 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
 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


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-08 Thread McCann, Jack
+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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-08 Thread Kyle Mestery
On Thu, Jan 8, 2015 at 8:49 AM, McCann, Jack 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.

 These are all solid reasons for adding this, and it makes sense to me as
well. From a deployers perspective, these would be a big win.

Given we have already filed a bug, hopefully we can get this addressed soon.

Thanks,
Kyle


 - Jack

 ___
 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


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-08 Thread Tim Bell
There must be other OpenStack services which have also faced this ‘stop 
scheduling but keep replying’ issues. Can we make the names for the various 
states and transitions consistent ?

Tim

From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: 08 January 2015 16:26
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without 
topping sevices

On Thu, Jan 8, 2015 at 8:49 AM, McCann, Jack 
jack.mcc...@hp.commailto: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.
These are all solid reasons for adding this, and it makes sense to me as well. 
From a deployers perspective, these would be a big win.
Given we have already filed a bug, hopefully we can get this addressed soon.

Thanks,
Kyle

- Jack

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orgmailto: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


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-07 Thread Miguel Ángel Ajo
Totally correct, that’s what I was meaning with “will remain active”
but “unmanaged”.

Yes, it would be good to have something to tell the schedulers to ban a host.  

Miguel Ángel Ajo


On Thursday, 8 de January de 2015 at 00:52, Kevin Benton wrote:

 The problem is that if you just stop the service, it not only removes it from 
 scheduling, but it stops it from receiving updates to floating IP changes, 
 interface changes, etc. I think it would be nice to have a way to explicitly 
 stop it from being scheduled new routers, but still act as a functioning L3 
 agent otherwise.
  
 On Wed, Jan 7, 2015 at 3:30 PM, Miguel Ángel Ajo majop...@redhat.com 
 (mailto:majop...@redhat.com) wrote:
  You can stop the neutron-dhcp-agent or neutron-l3-agent,  
  the agents should go not-active after reporting timeout.
   
  The actual network services (routers, dhcp, etc) will stay
  active into the node, but unmanaged. In some cases,
  if you have automatic rescheduling of the resources
  configured, those will be spawned on other hosts.
   
  Depending on your use case this will be enough or not.
  It’s intended for upgrades and maintenance. But not
  for controlling resources in a node.
   
   
  Miguel Ángel Ajo
   
   
  On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:
   
   Carl,

   Thank you for your comment.

   It seems there is no clear opinion about whether bug report or
   buleprint is better.  
   So I submitted a bug report for the moment so that the requirememt
   is not forgotten.
   https://bugs.launchpad.net/neutron/+bug/1408488

   Thanks.
   Itsuro Oda

   On Tue, 6 Jan 2015 09:05:19 -0700
   Carl Baldwin c...@ecbaldwin.net (mailto:c...@ecbaldwin.net) wrote:

Itsuro,
 
It would be desirable to be able to be hide an agent from scheduling
but no one has stepped up to make this happen. Come to think of it,
I'm not sure that a bug or blueprint has been filed yet to address it
though it is something that I've wanted for a little while now.
 
Carl
 
On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp 
(mailto:o...@valinux.co.jp) wrote:
 Neutron experts,
  
 I want to stop scheduling to a specific {dhcp|l3}_agent without
 stopping router/dhcp services on it.
 I expected setting admin_state_up of the agent to False is met
 this demand. But this operation stops all services on the agent
 in actuality. (Is this behavior intended ? It seems there is no
 document for agent API.)
  
 I think admin_state_up of agents should affect only scheduling.
 If it is accepted I will submit a bug report and make a fix.
  
 Or should I propose a blueprint for adding function to stop
 agent's scheduling without stopping services on it ?
  
 I'd like to hear neutron experts' suggestions.
  
 Thanks.
 Itsuro Oda
 --
 Itsuro ODA o...@valinux.co.jp (mailto:o...@valinux.co.jp)
  
  
 ___
 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
 


   --  
   Itsuro ODA o...@valinux.co.jp (mailto:o...@valinux.co.jp)


   ___
   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 (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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-07 Thread Miguel Ángel Ajo
You can stop the neutron-dhcp-agent or neutron-l3-agent,  
the agents should go not-active after reporting timeout.

The actual network services (routers, dhcp, etc) will stay
active into the node, but unmanaged. In some cases,
if you have automatic rescheduling of the resources
configured, those will be spawned on other hosts.

Depending on your use case this will be enough or not.
It’s intended for upgrades and maintenance. But not
for controlling resources in a node.


Miguel Ángel Ajo


On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:

 Carl,
  
 Thank you for your comment.
  
 It seems there is no clear opinion about whether bug report or
 buleprint is better.  
 So I submitted a bug report for the moment so that the requirememt
 is not forgotten.
 https://bugs.launchpad.net/neutron/+bug/1408488
  
 Thanks.
 Itsuro Oda
  
 On Tue, 6 Jan 2015 09:05:19 -0700
 Carl Baldwin c...@ecbaldwin.net (mailto:c...@ecbaldwin.net) wrote:
  
  Itsuro,
   
  It would be desirable to be able to be hide an agent from scheduling
  but no one has stepped up to make this happen. Come to think of it,
  I'm not sure that a bug or blueprint has been filed yet to address it
  though it is something that I've wanted for a little while now.
   
  Carl
   
  On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp 
  (mailto:o...@valinux.co.jp) wrote:
   Neutron experts,

   I want to stop scheduling to a specific {dhcp|l3}_agent without
   stopping router/dhcp services on it.
   I expected setting admin_state_up of the agent to False is met
   this demand. But this operation stops all services on the agent
   in actuality. (Is this behavior intended ? It seems there is no
   document for agent API.)

   I think admin_state_up of agents should affect only scheduling.
   If it is accepted I will submit a bug report and make a fix.

   Or should I propose a blueprint for adding function to stop
   agent's scheduling without stopping services on it ?

   I'd like to hear neutron experts' suggestions.

   Thanks.
   Itsuro Oda
   --
   Itsuro ODA o...@valinux.co.jp (mailto:o...@valinux.co.jp)


   ___
   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
   
  
  
 --  
 Itsuro ODA o...@valinux.co.jp (mailto:o...@valinux.co.jp)
  
  
 ___
 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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-07 Thread Kevin Benton
The problem is that if you just stop the service, it not only removes it
from scheduling, but it stops it from receiving updates to floating IP
changes, interface changes, etc. I think it would be nice to have a way to
explicitly stop it from being scheduled new routers, but still act as a
functioning L3 agent otherwise.

On Wed, Jan 7, 2015 at 3:30 PM, Miguel Ángel Ajo majop...@redhat.com
wrote:

 You can stop the neutron-dhcp-agent or neutron-l3-agent,
 the agents should go not-active after reporting timeout.

 The actual network services (routers, dhcp, etc) will stay
 active into the node, but unmanaged. In some cases,
 if you have automatic rescheduling of the resources
 configured, those will be spawned on other hosts.

 Depending on your use case this will be enough or not.
 It’s intended for upgrades and maintenance. But not
 for controlling resources in a node.

 Miguel Ángel Ajo

 On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:

 Carl,

 Thank you for your comment.

 It seems there is no clear opinion about whether bug report or
 buleprint is better.
 So I submitted a bug report for the moment so that the requirememt
 is not forgotten.
 https://bugs.launchpad.net/neutron/+bug/1408488

 Thanks.
 Itsuro Oda

 On Tue, 6 Jan 2015 09:05:19 -0700
 Carl Baldwin c...@ecbaldwin.net wrote:

 Itsuro,

 It would be desirable to be able to be hide an agent from scheduling
 but no one has stepped up to make this happen. Come to think of it,
 I'm not sure that a bug or blueprint has been filed yet to address it
 though it is something that I've wanted for a little while now.

 Carl

 On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp wrote:

 Neutron experts,

 I want to stop scheduling to a specific {dhcp|l3}_agent without
 stopping router/dhcp services on it.
 I expected setting admin_state_up of the agent to False is met
 this demand. But this operation stops all services on the agent
 in actuality. (Is this behavior intended ? It seems there is no
 document for agent API.)

 I think admin_state_up of agents should affect only scheduling.
 If it is accepted I will submit a bug report and make a fix.

 Or should I propose a blueprint for adding function to stop
 agent's scheduling without stopping services on it ?

 I'd like to hear neutron experts' suggestions.

 Thanks.
 Itsuro Oda
 --
 Itsuro ODA o...@valinux.co.jp


 ___
 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


 --
 Itsuro ODA o...@valinux.co.jp


 ___
 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




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron][L3] Stop agent scheduling without topping sevices

2015-01-07 Thread Itsuro ODA
Miguel, Kevin,

Thank you for your comments.

The motivation of this (from our customer) is about
design of network-node reduction procedure.

They prefer stop scheduling for agents on the node
at first then individual services are moved by
*-remove and *-add gradually rather than stopping all
services on the node at once.

As Kevin mentioned, agents must be alive so that 
operations for existing services must be continued. 

Thanks.
Itsuro Oda

On Wed, 7 Jan 2015 15:52:56 -0800
Kevin Benton blak...@gmail.com wrote:

 The problem is that if you just stop the service, it not only removes it
 from scheduling, but it stops it from receiving updates to floating IP
 changes, interface changes, etc. I think it would be nice to have a way to
 explicitly stop it from being scheduled new routers, but still act as a
 functioning L3 agent otherwise.
 
 On Wed, Jan 7, 2015 at 3:30 PM, Miguel Angel Ajo majop...@redhat.com
 wrote:
 
  You can stop the neutron-dhcp-agent or neutron-l3-agent,
  the agents should go not-active after reporting timeout.
 
  The actual network services (routers, dhcp, etc) will stay
  active into the node, but unmanaged. In some cases,
  if you have automatic rescheduling of the resources
  configured, those will be spawned on other hosts.
 
  Depending on your use case this will be enough or not.
  It’s intended for upgrades and maintenance. But not
  for controlling resources in a node.
 
  Miguel Angel Ajo
 
  On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:
 
  Carl,
 
  Thank you for your comment.
 
  It seems there is no clear opinion about whether bug report or
  buleprint is better.
  So I submitted a bug report for the moment so that the requirememt
  is not forgotten.
  https://bugs.launchpad.net/neutron/+bug/1408488
 
  Thanks.
  Itsuro Oda
 
  On Tue, 6 Jan 2015 09:05:19 -0700
  Carl Baldwin c...@ecbaldwin.net wrote:
 
  Itsuro,
 
  It would be desirable to be able to be hide an agent from scheduling
  but no one has stepped up to make this happen. Come to think of it,
  I'm not sure that a bug or blueprint has been filed yet to address it
  though it is something that I've wanted for a little while now.
 
  Carl
 
  On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA o...@valinux.co.jp wrote:
 
  Neutron experts,
 
  I want to stop scheduling to a specific {dhcp|l3}_agent without
  stopping router/dhcp services on it.
  I expected setting admin_state_up of the agent to False is met
  this demand. But this operation stops all services on the agent
  in actuality. (Is this behavior intended ? It seems there is no
  document for agent API.)
 
  I think admin_state_up of agents should affect only scheduling.
  If it is accepted I will submit a bug report and make a fix.
 
  Or should I propose a blueprint for adding function to stop
  agent's scheduling without stopping services on it ?
 
  I'd like to hear neutron experts' suggestions.
 
  Thanks.
  Itsuro Oda
  --
  Itsuro ODA o...@valinux.co.jp
 
 
  ___
  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
 
 
  --
  Itsuro ODA o...@valinux.co.jp
 
 
  ___
  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
 
 
 
 
 -- 
 Kevin Benton

-- 
Itsuro ODA o...@valinux.co.jp


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev