<div dir="ltr">Hi Eugene,<div><br></div><div>I have some comments on your considerations. I do apologise but perhaps I did not understand correctly the workflow for removal of a service provider.</div><div><br></div><div>Salvatore</div>
<div><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Salvatore, thanks for your feedback.<div><br></div><div>Let me comment on some of your statements</div><div class="im">
<div><i>> <span style="font-family:arial,sans-serif;font-size:13px">The possibility Eugene describes in his post - a service provider being deleted - is probably not a 'regular' use case, but more the consequence of a potentially error-prone operation.</span></i></div>
</div><div><font face="arial, sans-serif">Nachi initially raised a concern about the case when cloud operator decides to remove some provider.</font></div><div><font face="arial, sans-serif">A few considerations for such operation:</font></div>
<div><font face="arial, sans-serif">1) IMO, removing the provider should not result in losing logical configuration for users</font></div><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>What kind of operations would the cleanup involve?</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> </div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">
<div><font face="arial, sans-serif"><br></font></div><div><i><font face="arial, sans-serif">> </font><span style="font-family:arial,sans-serif;font-size:13px"> </span><span style="font-family:arial,sans-serif;font-size:13px">I am not convinced by the idea of having a 'No_op' service provider; I think if an API user wants to create a resource, but does not want it to be 'implemented', the way to go would be to put it administratevely down, regardless of the provider used.</span></i></div>
</div><div><font face="arial, sans-serif">The need for Noop driver is direct consequence of the case above.</font></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>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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Thanks,</font></div><div><font face="arial, sans-serif">Eugene.</font></div><div><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Jul 30, 2013 at 12:06 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">It is my personal opinion that there is no necessary condition between 'having the possibility of leaving a resource without service provider' and 'API users want to create resources without service providers'.<div>
While being able to change the 'provider' associated with a resource is a reasonable use case, albeit not one we might want to implement now, unassociated resources as a valid use case need to be motivated better. The possibility Eugene describes in his post - a service provider being deleted - is probably not a 'regular' use case, but more the consequence of a potentially error-prone operation.<br>
</div><div><br></div><div>Sticking to the concept that Neutron should hide as much as possible details regarding backing technologies - and from what I gather providers map 1:1 with backend technologies - I would say that the default action of associating resource with a 'default' service provider still makes sense; I am not convinced by the idea of having a 'No_op' service provider; I think if an API user wants to create a resource, but does not want it to be 'implemented', the way to go would be to put it administratevely down, regardless of the provider used.</div>
<div><br></div><div>Going back to the original issue - removal of a provider, I think we should consider whether such an action is legal or not.</div><div>If it's not legal, then we might think about adding a check at startup time: if service instances mapped to unknow providers are found, Neutron may fail to start up.</div>
<div>It is also nteresting the case when the provider name is not changed, but the driver is changed. I have reason to believe this might lead to a bit of mayhem; it *might* be manageable, but probably for Havana it might be just worth documenting that this kind of operation should just not be performed.</div>
<div><br></div><div>Salvatore<br></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On 29 July 2013 16:34, Eugene Nikanorov <span dir="ltr"><<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">Hi folks,<div><br></div><div>Recently we've been discussing with Nachi Ueno some specific use case of deployments with multiple providers for particular advanced service.</div>
<div><br></div><div>What If admin wants to remove certain provider from configuration file?</div>
<div>The following handling was proposed:</div><div>1) Before restarting neutron-server to apply new configuration, admin undeploys all resources that were deployed with provider being removed. That's needed to gracefully cleanup devices used by provider being removed.</div>
<div><br></div><div>2) Removal of a provider should not result in resource deletion.</div><div>E.g. user's logical resources are preserved, and they can be associated with other service providers later on.</div><div>
<br></div><div>
3) Having (1) and (2) it's obvious that after those steps are performed, users are left with pure logical resources which don't have physical representation.</div><div>I think such resources are no worse then deployed ones, e.g. could be worked with just the same way as those which have a provider associated.</div>
<div><br></div><div>The conclusion from (3) is that users themselves may want to create such resources.</div><div>The workflow would be to create resource with no provider, configure it, and then deploy at once.</div><div>
<br></div><div>And I have an API question regarding such use case.</div><div>Currently user doesn't specify provider to create resource. For this to continue to work we introduced the notion of 'default provider'. So, If user doesn't specify provider - the default one is used.</div>
<div>Then if we want users to be able to create unassociated resource, what kind of provider they need to pass to 'create' API call?</div><div><br></div><div>One important consideration that appeared while I was implementing multiple providers for lbaas is that a resource always needs to be handled by some provider, even if not associated with any. That is needed to preserve consistency of DB operations, because in current model (for lbaas at least) plugin sets object (pool, vip, etc) status to PENDING_DELETE, and then driver deletes it. </div>
<div>If resource is unassociated with the driver, then 'Noop' driver must be used for this logic to work properly.</div><div><br></div><div>One of the solution to this would be to have special name for the provider to indicate 'Noop' provider. The reason for having special name is that it's better to not specify Noop in configuration as it is essential basic provider that should always be present.</div>
<div><br></div><div>Please share your thoughts.</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div><br></div></div>
<br></div></div>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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>
<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>