<div dir="ltr">More comments on top of your comments!<div><div>And one more question: what are we going to do with 'orphaned' logical instances? Can they be associated with another provider?</div><div><br></div><div>
Salvatore<br><div class="gmail_extra"><br><br><div class="gmail_quote">On 31 July 2013 09:23, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">My comments inline<div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando <span dir="ltr"><<a href="mailto:sorlando@nicira.com" target="_blank">sorlando@nicira.com</a>></span> wrote:<br>

</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br>
<div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="im">On 30 July 2013 23:24, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>


</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><font face="arial, sans-serif">2) Resources allocated by the provider must be cleaned up - that is done before neutron server is restarted with new configuration.</font></div>




<div><font face="arial, sans-serif">I think it's a valid workflow.</font></div></div></blockquote><div><br></div></div></div><div class="im"><div>What kind of operations would the cleanup involve?</div></div></div></div>
</div></div></blockquote>
<div><br></div><div>To me it basically means that resources need to be undeployed from corresponding devices/hosts.</div><div>Being more specific: if for example cloud admin decides to remove lbaas reference provider for whatever reason, then he would expect haproxy processes to be shut down on all hosts.</div>
</div></div></div></blockquote><div><br></div><div>If I get it right then, this would mean that all the resources (in your case service pools) will have to be scanned at startup to see if their provider has been removed.</div>
<div>I don't think this is the right time to get into performance and scale discussions; on the implementation side, it would be good for me to understand how neutron will be able to undeploy resources - for which it should use a driver which unfortunately has been removed. Are we caching drivers somewhere - or planning to store them back in the database?</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div class="gmail_extra">

<div class="gmail_quote"><div> </div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div dir="ltr"><div> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">

<div><font face="arial, sans-serif">Also, I'd be against such a check which would prevent neutron-server from starting if some resources reference unknown providers.</font></div>


<div><font face="arial, sans-serif">Providers may be removed for various reasons, but that would be too disruptive to bring down whole networking service because of that.</font></div><div><font face="arial, sans-serif">Another option may be to take such decision on per-service basis. At least I don't think having orphaned loadbalancer pools should prevent neutron to start.</font></div>


</div></blockquote><div><br></div></div><div>It might be ok to not prevent the service from starting.</div><div>Perhaps I am misunderstanding the workflow, which I barely know since the original conversation happened outside of this thread.</div>


<div>From the perspective of the API user, I perceive the effect would be that of a service instance which exists as a logical entity, but actually has been de-implemented as its provider has been removed.</div><div>This is probably not very different from the case in which the host where a port is deployed goes down - the status for the port will be DOWN. I hope that the status for the corresponding services will go DOWN as well - otherwise this might result a bit confusing to API users.</div>

</div></div></div></div></blockquote><div> </div></div><div>I think having resource in DOWN state is different from having resource with no provider. Why? Because from API perspective when you update resource from DOWN to UP state, you expect some deployment to happen, and it would not be a case if provider is not associated with the resource. </div>
<div class="im">
<div><br></div></div></div></div></div></blockquote><div><br></div><div>I am referring to the operational status. I've used the term 'administratevely down' incorrectly </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div>

<div><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif">The need for Noop driver is direct consequence of the case above.</span><br></div></div><div><font face="arial, sans-serif">If we remove requirement (1) and just delete resources which reference removed provider, than we will not need Noop and unassociated resources.</font></div>


</div></blockquote><div><br></div></div><div>While a 'noop' driver - assuming this would be the right term - can be used to describe service instances without a provider, I wonder if the best way of describing an instance without a provider is literally a service instance without a provider. Also, correct me if I'm wrong here, if one assumes that such 'orphaned' instances should be in status 'DOWN' or 'ERROR', then probably it does not matter which provider (if any) the service instance is associated with.</div>

</div></div></div></blockquote><div> </div></div><div>In fact,  'Noop' is kind of 'internal' description, not visible to users. That's just a technical need to have such driver which will finish removal operations (I'm speaking about lbaas plugin now, which changes state of objects to PENDING_DELETE and lets drivers to do actual db removal) and will not do any additional stuff.</div>

<div>Regarding DOWN and ERROR - see my comment above.</div></div></div></div></blockquote><div><br></div><div>So the Noop driver will be able to undeploy the service instance?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Thanks,</div><div>Eugene.</div></div></div></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></div></div></div></div>