*> 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?* Undeployment is a manual operation that admin must perform *before* restarting neutron server with removed provider. I think it's going to be additional admin-only operation. Noop driver is not capable of anything backend-specific.
Thanks, Eugene. On Wed, Jul 31, 2013 at 11:47 AM, Salvatore Orlando <sorla...@nicira.com>wrote: > More comments on top of your comments! > And one more question: what are we going to do with 'orphaned' logical > instances? Can they be associated with another provider? > > Salvatore > > > On 31 July 2013 09:23, Eugene Nikanorov <enikano...@mirantis.com> wrote: > >> My comments inline >> >> >> On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando >> <sorla...@nicira.com>wrote: >> >>> >>> >>> On 30 July 2013 23:24, Eugene Nikanorov <enikano...@mirantis.com> wrote: >>> >>>> 2) Resources allocated by the provider must be cleaned up - that is >>>> done before neutron server is restarted with new configuration. >>>> I think it's a valid workflow. >>>> >>> >>> What kind of operations would the cleanup involve? >>> >> >> To me it basically means that resources need to be undeployed from >> corresponding devices/hosts. >> 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. >> > > 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. > 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? > > > >> >> >>> >> >>> >>>> >>>> >>> Also, I'd be against such a check which would prevent neutron-server >>>> from starting if some resources reference unknown providers. >>>> Providers may be removed for various reasons, but that would be too >>>> disruptive to bring down whole networking service because of that. >>>> 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. >>>> >>> >>> It might be ok to not prevent the service from starting. >>> Perhaps I am misunderstanding the workflow, which I barely know since >>> the original conversation happened outside of this thread. >>> 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. >>> 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. >>> >> >> 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. >> >> > I am referring to the operational status. I've used the term > 'administratevely down' incorrectly > >> >>> >>>> >>>> The need for Noop driver is direct consequence of the case above. >>>> If we remove requirement (1) and just delete resources which reference >>>> removed provider, than we will not need Noop and unassociated resources. >>>> >>> >>> 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. >>> >> >> 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. >> Regarding DOWN and ERROR - see my comment above. >> > > So the Noop driver will be able to undeploy the service instance? > > >> >> Thanks, >> Eugene. >> >> _______________________________________________ >> OpenStack-dev mailing list >> 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 > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev