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
