<div dir="ltr">My comments inline<div class="gmail_extra"><br><br><div class="gmail_quote">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>
<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 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>

<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>What kind of operations would the cleanup involve?</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><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 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> </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>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><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 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>

<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>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><br></div><div>Thanks,</div><div>Eugene.</div></div></div></div>