<div dir="ltr">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.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 7, 2015 at 3:30 PM, Miguel Ángel Ajo <span dir="ltr"><<a href="mailto:majopela@redhat.com" target="_blank">majopela@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-family:Helvetica;font-size:14px">You can stop the neutron-dhcp-agent or neutron-l3-agent, <div>the agents should go not-active after reporting timeout.</div><div><br></div><div>The actual network services (routers, dhcp, etc) will stay</div><div>active into the node, but unmanaged. In some cases,</div><div>if you have automatic rescheduling of the resources</div><div>configured, those will be spawned on other hosts.</div><div><br></div><div>Depending on your use case this will be enough or not.</div><div>It’s intended for upgrades and maintenance. But not</div><div>for controlling resources in a node.</div></div>
<div><div><br></div><div><span style="font-size:10pt">Miguel Ángel Ajo</span></div><div><br></div></div>
<p style="color:#a0a0a8">On Thursday, 8 de January de 2015 at 00:20, Itsuro ODA wrote:</p>
<blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px">
<span><div><div><div>Carl,</div><div><br></div><div>Thank you for your comment.</div><div><br></div><div>It seems there is no clear opinion about whether bug report or</div><div>buleprint is better. </div><div>So I submitted a bug report for the moment so that the requirememt</div><div>is not forgotten.</div><div><a href="https://bugs.launchpad.net/neutron/+bug/1408488" target="_blank">https://bugs.launchpad.net/neutron/+bug/1408488</a></div><div><br></div><div>Thanks.</div><div>Itsuro Oda</div><div><br></div><div>On Tue, 6 Jan 2015 09:05:19 -0700</div><div>Carl Baldwin <<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>> wrote:</div><div><br></div><blockquote type="cite"><div><div>Itsuro,</div><div><br></div><div>It would be desirable to be able to be hide an agent from scheduling</div><div>but no one has stepped up to make this happen. Come to think of it,</div><div>I'm not sure that a bug or blueprint has been filed yet to address it</div><div>though it is something that I've wanted for a little while now.</div><div><br></div><div>Carl</div><div><br></div><div>On Mon, Jan 5, 2015 at 4:13 PM, Itsuro ODA <<a href="mailto:oda@valinux.co.jp" target="_blank">oda@valinux.co.jp</a>> wrote:</div><blockquote type="cite"><div><div>Neutron experts,</div><div><br></div><div>I want to stop scheduling to a specific {dhcp|l3}_agent without</div><div>stopping router/dhcp services on it.</div><div>I expected setting admin_state_up of the agent to False is met</div><div>this demand. But this operation stops all services on the agent</div><div>in actuality. (Is this behavior intended ? It seems there is no</div><div>document for agent API.)</div><div><br></div><div>I think admin_state_up of agents should affect only scheduling.</div><div>If it is accepted I will submit a bug report and make a fix.</div><div><br></div><div>Or should I propose a blueprint for adding function to stop</div><div>agent's scheduling without stopping services on it ?</div><div><br></div><div>I'd like to hear neutron experts' suggestions.</div><div><br></div><div>Thanks.</div><div>Itsuro Oda</div><div>--</div><div>Itsuro ODA <<a href="mailto:oda@valinux.co.jp" target="_blank">oda@valinux.co.jp</a>></div><div><br></div><div><br></div><div>_______________________________________________</div><div>OpenStack-dev mailing list</div><div><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></blockquote><div><br></div><div>_______________________________________________</div><div>OpenStack-dev mailing list</div><div><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></blockquote><div><br></div><span class="HOEnZb"><font color="#888888"><div>-- </div><div>Itsuro ODA <<a href="mailto:oda@valinux.co.jp" target="_blank">oda@valinux.co.jp</a>></div><div><br></div><div><br></div><div>_______________________________________________</div><div>OpenStack-dev mailing list</div><div><a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a></div><div><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></font></span></div></div></span>
</blockquote>
<div>
<br>
</div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div>Kevin Benton</div></div>
</div>