Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
After this discussion I'm thinking about not adding comprehensive handling for provider removing case at all. Probably we'll need to document desired workflow and postpone cleanup feature until use cases are more clear. I like the idea of leaving resource in ERROR state. However, If we're not implementing updating pool with provider (reassociating with another provider), such resources will be unusable until provider is reenabled. I suggest the following workflow for provider removal: 1) Admin removes provider from config and restarts neutron 2) Neutron changes state of all related resources to ERROR and removes associations (so we can't just go back and readd provider to conf file) 3) Users are given ability to associate resource with existing provider Still this leaves ability to operate on unassociated resources. IMO that's ok, and can be easily handled with noop driver (this is hidden from user, user thinks he works with logical resource without backend implementation). >From lbaas API change perspective, such workflow results in: 1) adding 'provider' attribute to 'pools' resource. Users can only provide it on pool creation 2) adding special member action 'associate_provider' that can only be run on non-associated pools What do you think? P.S. going back to noop driver role: it's a basic complimentary part of plugin API that must be called. So either noop or other driver must be called when user performs any operation on resource. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
More stuff from me. Salvatore On 31 July 2013 10:36, Eugene Nikanorov wrote: > *> 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. > So disassociating instances from service providers (and therefore de-implementing then) is an admin process, which probably makes sense. I guess if an admin gets the workflow wrong, and removes the provider before deimplementing resources, then resources associated with a deleted provider should go in error as soon as they're used; admins can always recover readding the provider and de-implementing resources. Beyond being a placeholder for a service instance without a provider what would be the role of this noop driver? > > Thanks, > Eugene. > > > On Wed, Jul 31, 2013 at 11:47 AM, Salvatore Orlando > 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 wrote: >> >>> My comments inline >>> >>> >>> On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando >>> wrote: >>> On 30 July 2013 23:24, Eugene Nikanorov 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
Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
*> 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 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 wrote: > >> My comments inline >> >> >> On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando >> wrote: >> >>> >>> >>> On 30 July 2013 23:24, Eugene Nikanorov 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? > > >> >> T
Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
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 wrote: > My comments inline > > > On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando wrote: > >> >> >> On 30 July 2013 23:24, Eugene Nikanorov 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
Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
My comments inline On Wed, Jul 31, 2013 at 1:53 AM, Salvatore Orlando wrote: > > > On 30 July 2013 23:24, Eugene Nikanorov 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. > > >> >> > 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. > >> >> 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. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
Hi Eugene, 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. Salvatore On 30 July 2013 23:24, Eugene Nikanorov wrote: > Salvatore, thanks for your feedback. > > Let me comment on some of your statements > *> 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.* > Nachi initially raised a concern about the case when cloud operator > decides to remove some provider. > A few considerations for such operation: > 1) IMO, removing the provider should not result in losing logical > configuration for users > 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? > > 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 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.* > 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. > > Thanks, > Eugene. > > > On Tue, Jul 30, 2013 at 12:06 PM, Salvatore Orlando > wrote: > >> 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'. >> 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. >> >> 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. >> >> Going back to the original issue - removal of a provider, I think we >> should consider whether such an action is legal or not. >> 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. >> 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. >> >> Salvatore >> >> >> On 29 July 2013 16:
Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
Salvatore, thanks for your feedback. Let me comment on some of your statements *> 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.* Nachi initially raised a concern about the case when cloud operator decides to remove some provider. A few considerations for such operation: 1) IMO, removing the provider should not result in losing logical configuration for users 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. 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. *> 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.* 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. Thanks, Eugene. On Tue, Jul 30, 2013 at 12:06 PM, Salvatore Orlando wrote: > 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'. > 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. > > 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. > > Going back to the original issue - removal of a provider, I think we > should consider whether such an action is legal or not. > 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. > 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. > > Salvatore > > > On 29 July 2013 16:34, Eugene Nikanorov wrote: > >> Hi folks, >> >> Recently we've been discussing with Nachi Ueno some specific use case of >> deployments with multiple providers for particular advanced service. >> >> What If admin wants to remove certain provider from configuration file? >> The following handling was proposed: >> 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. >> >> 2) Removal of a provider should not result in resource deletion. >> E.g. user's logical resources are preserved, and they can be associated >> with other service providers later on. >> >> 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. >> 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. >> >> The conclusion from (3) is that users themselves may want to create such >> resources. >> The workflow would be to create resource with no provider, configure it, >> and then deploy at once. >> >> And I have an API question regarding such use case. >> 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. >> Then if we w
Re: [openstack-dev] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
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'. 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. 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. Going back to the original issue - removal of a provider, I think we should consider whether such an action is legal or not. 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. 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. Salvatore On 29 July 2013 16:34, Eugene Nikanorov wrote: > Hi folks, > > Recently we've been discussing with Nachi Ueno some specific use case of > deployments with multiple providers for particular advanced service. > > What If admin wants to remove certain provider from configuration file? > The following handling was proposed: > 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. > > 2) Removal of a provider should not result in resource deletion. > E.g. user's logical resources are preserved, and they can be associated > with other service providers later on. > > 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. > 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. > > The conclusion from (3) is that users themselves may want to create such > resources. > The workflow would be to create resource with no provider, configure it, > and then deploy at once. > > And I have an API question regarding such use case. > 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. > Then if we want users to be able to create unassociated resource, what > kind of provider they need to pass to 'create' API call? > > 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. > If resource is unassociated with the driver, then 'Noop' driver must be > used for this logic to work properly. > > 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. > > Please share your thoughts. > > 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] [Neutron][LBaaS][VPNaaS][FWaaS] Dealing with logical logical configurations
Hi folks, Recently we've been discussing with Nachi Ueno some specific use case of deployments with multiple providers for particular advanced service. What If admin wants to remove certain provider from configuration file? The following handling was proposed: 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. 2) Removal of a provider should not result in resource deletion. E.g. user's logical resources are preserved, and they can be associated with other service providers later on. 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. 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. The conclusion from (3) is that users themselves may want to create such resources. The workflow would be to create resource with no provider, configure it, and then deploy at once. And I have an API question regarding such use case. 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. Then if we want users to be able to create unassociated resource, what kind of provider they need to pass to 'create' API call? 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. If resource is unassociated with the driver, then 'Noop' driver must be used for this logic to work properly. 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. Please share your thoughts. Thanks, Eugene. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
