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
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,
+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
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
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
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
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
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
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
