Re: [openstack-dev] [Neutron][LBaaS] status in entities
I agree. the current status can reflect the deployment status and we can add a new attribute to reflect operational status. I also agree that adminstate_up should definitely affect operational status. But driver could choose to unprovision when admin state is set to false. In which case status will also change. If agenda permits, can we discuss this in the upcoming weekly meeting? Sent using CloudMagichttps://cloudmagic.com/k/d/mailapp?ct=pacv=5.0.32pv=4.2.2 On Wed, Aug 06, 2014 at 2:46 AM, Stephen Balukoff sbaluk...@bluebox.netmailto:sbaluk...@bluebox.net wrote: Hi guys, I understood that admin_state_up was a manipulable field which (when working correctly) should change the entity to an operational status of ADMIN_DOWN or something similar to that. In any case, +1 on the deeper discussion of status. How urgent is it to resolve the discussion around status? We could potentially bring the interested parties together via google hangout or webex (to facilitate the high bandwidth). Stephen On Tue, Aug 5, 2014 at 9:05 AM, Brandon Logan brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com wrote: Isn't that what admin_state_up is for? But yes we do need a deeper discussion on this and many other things. On Tue, 2014-08-05 at 15:42 +, Eichberger, German wrote: There was also talk about a third administrative status like ON/OFF... We really need a deeper status discussion - likely high bandwith to work all of that out. German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.commailto:brandon.lo...@rackspace.com] Sent: Tuesday, August 05, 2014 8:27 AM To: openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] status in entities Hello Vijay! Well this is a hold over from v1, but the status is a provisioning status. So yes, when something is deployed successfully it should be ACTIVE. The exception to this is the member status, in that it's status can be INACTIVE if a health check fails. Now this will probably cause edge cases when health checks and updates are happening to the same member. It's been talked about before, but we need to really have two types of status fields, provisioning and operational. IMHO, that should be something we try to get into K. Thanks, Brandon On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote: Hi: I think we had some discussions around ‘status’ attribute earlier, I don’t recollect the conclusion. Does it reflect the deployment status? Meaning, if the status of an entity is ACTIVE, the user has to infer that the entity is deployed successfully in the backend/loadbalancer. Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Neutron][LBaaS] status in entities
Hi: I think we had some discussions around 'status' attribute earlier, I don't recollect the conclusion. Does it reflect the deployment status? Meaning, if the status of an entity is ACTIVE, the user has to infer that the entity is deployed successfully in the backend/loadbalancer. Thanks, Vijay V. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] status in entities
Hello Vijay! Well this is a hold over from v1, but the status is a provisioning status. So yes, when something is deployed successfully it should be ACTIVE. The exception to this is the member status, in that it's status can be INACTIVE if a health check fails. Now this will probably cause edge cases when health checks and updates are happening to the same member. It's been talked about before, but we need to really have two types of status fields, provisioning and operational. IMHO, that should be something we try to get into K. Thanks, Brandon On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote: Hi: I think we had some discussions around ‘status’ attribute earlier, I don’t recollect the conclusion. Does it reflect the deployment status? Meaning, if the status of an entity is ACTIVE, the user has to infer that the entity is deployed successfully in the backend/loadbalancer. Thanks, Vijay V. ___ 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] status in entities
There was also talk about a third administrative status like ON/OFF... We really need a deeper status discussion - likely high bandwith to work all of that out. German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Tuesday, August 05, 2014 8:27 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] status in entities Hello Vijay! Well this is a hold over from v1, but the status is a provisioning status. So yes, when something is deployed successfully it should be ACTIVE. The exception to this is the member status, in that it's status can be INACTIVE if a health check fails. Now this will probably cause edge cases when health checks and updates are happening to the same member. It's been talked about before, but we need to really have two types of status fields, provisioning and operational. IMHO, that should be something we try to get into K. Thanks, Brandon On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote: Hi: I think we had some discussions around ‘status’ attribute earlier, I don’t recollect the conclusion. Does it reflect the deployment status? Meaning, if the status of an entity is ACTIVE, the user has to infer that the entity is deployed successfully in the backend/loadbalancer. Thanks, Vijay V. ___ 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
Re: [openstack-dev] [Neutron][LBaaS] status in entities
Isn't that what admin_state_up is for? But yes we do need a deeper discussion on this and many other things. On Tue, 2014-08-05 at 15:42 +, Eichberger, German wrote: There was also talk about a third administrative status like ON/OFF... We really need a deeper status discussion - likely high bandwith to work all of that out. German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Tuesday, August 05, 2014 8:27 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] status in entities Hello Vijay! Well this is a hold over from v1, but the status is a provisioning status. So yes, when something is deployed successfully it should be ACTIVE. The exception to this is the member status, in that it's status can be INACTIVE if a health check fails. Now this will probably cause edge cases when health checks and updates are happening to the same member. It's been talked about before, but we need to really have two types of status fields, provisioning and operational. IMHO, that should be something we try to get into K. Thanks, Brandon On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote: Hi: I think we had some discussions around ‘status’ attribute earlier, I don’t recollect the conclusion. Does it reflect the deployment status? Meaning, if the status of an entity is ACTIVE, the user has to infer that the entity is deployed successfully in the backend/loadbalancer. Thanks, Vijay V. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] status in entities
Hi guys, I understood that admin_state_up was a manipulable field which (when working correctly) should change the entity to an operational status of ADMIN_DOWN or something similar to that. In any case, +1 on the deeper discussion of status. How urgent is it to resolve the discussion around status? We could potentially bring the interested parties together via google hangout or webex (to facilitate the high bandwidth). Stephen On Tue, Aug 5, 2014 at 9:05 AM, Brandon Logan brandon.lo...@rackspace.com wrote: Isn't that what admin_state_up is for? But yes we do need a deeper discussion on this and many other things. On Tue, 2014-08-05 at 15:42 +, Eichberger, German wrote: There was also talk about a third administrative status like ON/OFF... We really need a deeper status discussion - likely high bandwith to work all of that out. German -Original Message- From: Brandon Logan [mailto:brandon.lo...@rackspace.com] Sent: Tuesday, August 05, 2014 8:27 AM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [Neutron][LBaaS] status in entities Hello Vijay! Well this is a hold over from v1, but the status is a provisioning status. So yes, when something is deployed successfully it should be ACTIVE. The exception to this is the member status, in that it's status can be INACTIVE if a health check fails. Now this will probably cause edge cases when health checks and updates are happening to the same member. It's been talked about before, but we need to really have two types of status fields, provisioning and operational. IMHO, that should be something we try to get into K. Thanks, Brandon On Tue, 2014-08-05 at 09:28 +, Vijay Venkatachalam wrote: Hi: I think we had some discussions around ‘status’ attribute earlier, I don’t recollect the conclusion. Does it reflect the deployment status? Meaning, if the status of an entity is ACTIVE, the user has to infer that the entity is deployed successfully in the backend/loadbalancer. Thanks, Vijay V. ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend
+1 to QUEUED status. On Fri, Jul 4, 2014 at 5:27 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi German, That actually brings up another thing that needs to be done. There is no DELETED state. When an entity is deleted, it is deleted from the database. I'd prefer a DELETED state so that should be another feature we implement afterwards. Thanks, Brandon On Thu, 2014-07-03 at 23:02 +, Eichberger, German wrote: Hi Jorge, +1 for QUEUED and DETACHED I would suggest to make the time how long we keep entities in DELETED state configurable. We use something like 30 days, too, but we have made it configurable to adapt to changes... German -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Thursday, July 03, 2014 11:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend +1 to QUEUED status. For entities that have the concept of being attached/detached why not have a 'DETACHED' status to indicate that the entity is not provisioned at all (i.e. The config is just stored in the DB). When it is attached during provisioning then we can set it to 'ACTIVE' or any of the other provisioning statuses such as 'ERROR', 'PENDING_UPDATE', etc. Lastly, it wouldn't make much sense to have a 'DELETED' status on these types of entities until the user actually issues a DELETE API request (not to be confused with detaching). Which begs another question, when items are deleted how long should the API return responses for that resource? We have a 90 day threshold for this in our current implementation after which the API returns 404's for the resource. Cheers, --Jorge On 7/3/14 10:39 AM, Phillip Toohill phillip.tooh...@rackspace.com wrote: If the objects remain in 'PENDING_CREATE' until provisioned it would seem that the process got stuck in that status and may be in a bad state from user perspective. I like the idea of QUEUED or similar to reference that the object has been accepted but not provisioned. Phil On 7/3/14 10:28 AM, Brandon Logan brandon.lo...@rackspace.com wrote: With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about which driver to use (through provider or flavor). If a Listener, Pool, Member, or Health Monitor is created without a link to a Load Balancer, then what status does it have? At this point it only exists in the database and is really just waiting to be provisioned by a driver/backend. Some possibilities discussed: A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name Entities just remain in PENDING_CREATE until provisioned by a driver Entities just remain in ACTIVE until provisioned by a driver Opinions and suggestions? ___ 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 ___ 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
Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend
On Jul 4, 2014, at 5:27 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi German, That actually brings up another thing that needs to be done. There is no DELETED state. When an entity is deleted, it is deleted from the database. I'd prefer a DELETED state so that should be another feature we implement afterwards. Thanks, Brandon This is an interesting discussion since we would create an API inconsistency around possible status values. Traditionally, status has been be fabric status and we have not always well defined what the values should mean to tenants. Given that this is an extension, I think that adding new values would be ok (Salvatore might have a different opinion than me). Right we’ve never had a deleted state because the record has been removed immediately in most implementations even if the backend has not fully cleaned up. I was thinking for the v3 core we should have a DELETING state that is set before cleanup is dispatched to the backend driver/worker. The record can then be deleted when the backend has cleaned up. For unattached objects, I’m -1 on QUEUED because some will interpret that the system is planning to execute immediate operations on the resource (causing customer queries/complaints about why it has not transitioned). Maybe use something like DEFERRED, UNBOUND, or VALIDATED? mark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend
Hi, For logical objects that were deleted but the backend did not execute on, there is a PENDING_DELETE state. So currently there is PENDING_CREATE -- CREATE, PENDING_UPDATE--UPDATE and PENDING_DELETE--object is removed from the database. If an error occurred that the object is in ERROR state. So in this case if a listener is not yet configured in the backend, it will have a PENDING_CREATE state. -Sam. -Original Message- From: Mark McClain [mailto:mmccl...@yahoo-inc.com] Sent: Monday, July 07, 2014 5:33 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend On Jul 4, 2014, at 5:27 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi German, That actually brings up another thing that needs to be done. There is no DELETED state. When an entity is deleted, it is deleted from the database. I'd prefer a DELETED state so that should be another feature we implement afterwards. Thanks, Brandon This is an interesting discussion since we would create an API inconsistency around possible status values. Traditionally, status has been be fabric status and we have not always well defined what the values should mean to tenants. Given that this is an extension, I think that adding new values would be ok (Salvatore might have a different opinion than me). Right we've never had a deleted state because the record has been removed immediately in most implementations even if the backend has not fully cleaned up. I was thinking for the v3 core we should have a DELETING state that is set before cleanup is dispatched to the backend driver/worker. The record can then be deleted when the backend has cleaned up. For unattached objects, I'm -1 on QUEUED because some will interpret that the system is planning to execute immediate operations on the resource (causing customer queries/complaints about why it has not transitioned). Maybe use something like DEFERRED, UNBOUND, or VALIDATED? mark ___ 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] Status of entities that do not exist in a driver backend
Hey Mark, To add, one reason we have a DELETED status at Rackspace is that certain sub-resources are still relevant to our customers. For example, we have a usage sub-resource which reveals usage records for the load balancer. To illustrate, a user issues a DELETE on /loadbalancers/id but can still issue a GET on /loadbalancers/id/usage. If /loadbalancers/id were truly deleted (i.e a 404 is returned) it wouldn't make RESTful sense to expose the usage sub-resource. Furthermore, even if we don't plan on having sub-resources that a user will actually query I would still like a DELETED status as our customers use it for historical and debugging purposes. It provides users with a sense of clarity and doesn't leave them scratching their heads thinking, How were those load balancers configured when we had that issue the other day? for example. I agree on your objection for unattached objects assuming API operations for these objects will be synchronous in nature. However, since the API is suppose to be asynchronous a QUEUED status will make sense for the API operations that are truly asynchronous. In an earlier email I stated that a QUEUED status would be beneficial when compared to just a BUILD status because it would allow for more accurate metrics in regards to provisioning time. Customers will complain more if it appears provisioning times are taking a long time when in reality they are actually queued do to high API traffic. Thoughts? Cheers, --Jorge On 7/7/14 9:32 AM, Mark McClain mmccl...@yahoo-inc.com wrote: On Jul 4, 2014, at 5:27 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi German, That actually brings up another thing that needs to be done. There is no DELETED state. When an entity is deleted, it is deleted from the database. I'd prefer a DELETED state so that should be another feature we implement afterwards. Thanks, Brandon This is an interesting discussion since we would create an API inconsistency around possible status values. Traditionally, status has been be fabric status and we have not always well defined what the values should mean to tenants. Given that this is an extension, I think that adding new values would be ok (Salvatore might have a different opinion than me). Right we¹ve never had a deleted state because the record has been removed immediately in most implementations even if the backend has not fully cleaned up. I was thinking for the v3 core we should have a DELETING state that is set before cleanup is dispatched to the backend driver/worker. The record can then be deleted when the backend has cleaned up. For unattached objects, I¹m -1 on QUEUED because some will interpret that the system is planning to execute immediate operations on the resource (causing customer queries/complaints about why it has not transitioned). Maybe use something like DEFERRED, UNBOUND, or VALIDATED? mark ___ 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] Status of entities that do not exist in a driver backend
I'll +1 UNBOUND or DEFERRED status. QUEUED does have a kind of implication that it will be provisioned without any further action whereas UNBOUND or DEFERRED imply that another action must take place for it to actually be provisioned. Thanks, Brandon From: Jorge Miramontes [jorge.miramon...@rackspace.com] Sent: Monday, July 07, 2014 12:02 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend Hey Mark, To add, one reason we have a DELETED status at Rackspace is that certain sub-resources are still relevant to our customers. For example, we have a usage sub-resource which reveals usage records for the load balancer. To illustrate, a user issues a DELETE on /loadbalancers/id but can still issue a GET on /loadbalancers/id/usage. If /loadbalancers/id were truly deleted (i.e a 404 is returned) it wouldn't make RESTful sense to expose the usage sub-resource. Furthermore, even if we don't plan on having sub-resources that a user will actually query I would still like a DELETED status as our customers use it for historical and debugging purposes. It provides users with a sense of clarity and doesn't leave them scratching their heads thinking, How were those load balancers configured when we had that issue the other day? for example. I agree on your objection for unattached objects assuming API operations for these objects will be synchronous in nature. However, since the API is suppose to be asynchronous a QUEUED status will make sense for the API operations that are truly asynchronous. In an earlier email I stated that a QUEUED status would be beneficial when compared to just a BUILD status because it would allow for more accurate metrics in regards to provisioning time. Customers will complain more if it appears provisioning times are taking a long time when in reality they are actually queued do to high API traffic. Thoughts? Cheers, --Jorge On 7/7/14 9:32 AM, Mark McClain mmccl...@yahoo-inc.com wrote: On Jul 4, 2014, at 5:27 PM, Brandon Logan brandon.lo...@rackspace.com wrote: Hi German, That actually brings up another thing that needs to be done. There is no DELETED state. When an entity is deleted, it is deleted from the database. I'd prefer a DELETED state so that should be another feature we implement afterwards. Thanks, Brandon This is an interesting discussion since we would create an API inconsistency around possible status values. Traditionally, status has been be fabric status and we have not always well defined what the values should mean to tenants. Given that this is an extension, I think that adding new values would be ok (Salvatore might have a different opinion than me). Right we¹ve never had a deleted state because the record has been removed immediately in most implementations even if the backend has not fully cleaned up. I was thinking for the v3 core we should have a DELETING state that is set before cleanup is dispatched to the backend driver/worker. The record can then be deleted when the backend has cleaned up. For unattached objects, I¹m -1 on QUEUED because some will interpret that the system is planning to execute immediate operations on the resource (causing customer queries/complaints about why it has not transitioned). Maybe use something like DEFERRED, UNBOUND, or VALIDATED? mark ___ 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
Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend
Hi German, That actually brings up another thing that needs to be done. There is no DELETED state. When an entity is deleted, it is deleted from the database. I'd prefer a DELETED state so that should be another feature we implement afterwards. Thanks, Brandon On Thu, 2014-07-03 at 23:02 +, Eichberger, German wrote: Hi Jorge, +1 for QUEUED and DETACHED I would suggest to make the time how long we keep entities in DELETED state configurable. We use something like 30 days, too, but we have made it configurable to adapt to changes... German -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Thursday, July 03, 2014 11:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend +1 to QUEUED status. For entities that have the concept of being attached/detached why not have a 'DETACHED' status to indicate that the entity is not provisioned at all (i.e. The config is just stored in the DB). When it is attached during provisioning then we can set it to 'ACTIVE' or any of the other provisioning statuses such as 'ERROR', 'PENDING_UPDATE', etc. Lastly, it wouldn't make much sense to have a 'DELETED' status on these types of entities until the user actually issues a DELETE API request (not to be confused with detaching). Which begs another question, when items are deleted how long should the API return responses for that resource? We have a 90 day threshold for this in our current implementation after which the API returns 404's for the resource. Cheers, --Jorge On 7/3/14 10:39 AM, Phillip Toohill phillip.tooh...@rackspace.com wrote: If the objects remain in 'PENDING_CREATE' until provisioned it would seem that the process got stuck in that status and may be in a bad state from user perspective. I like the idea of QUEUED or similar to reference that the object has been accepted but not provisioned. Phil On 7/3/14 10:28 AM, Brandon Logan brandon.lo...@rackspace.com wrote: With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about which driver to use (through provider or flavor). If a Listener, Pool, Member, or Health Monitor is created without a link to a Load Balancer, then what status does it have? At this point it only exists in the database and is really just waiting to be provisioned by a driver/backend. Some possibilities discussed: A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name Entities just remain in PENDING_CREATE until provisioned by a driver Entities just remain in ACTIVE until provisioned by a driver Opinions and suggestions? ___ 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 ___ 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] Status of entities that do not exist in a driver backend
With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about which driver to use (through provider or flavor). If a Listener, Pool, Member, or Health Monitor is created without a link to a Load Balancer, then what status does it have? At this point it only exists in the database and is really just waiting to be provisioned by a driver/backend. Some possibilities discussed: A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name Entities just remain in PENDING_CREATE until provisioned by a driver Entities just remain in ACTIVE until provisioned by a driver Opinions and suggestions? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend
If the objects remain in 'PENDING_CREATE' until provisioned it would seem that the process got stuck in that status and may be in a bad state from user perspective. I like the idea of QUEUED or similar to reference that the object has been accepted but not provisioned. Phil On 7/3/14 10:28 AM, Brandon Logan brandon.lo...@rackspace.com wrote: With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about which driver to use (through provider or flavor). If a Listener, Pool, Member, or Health Monitor is created without a link to a Load Balancer, then what status does it have? At this point it only exists in the database and is really just waiting to be provisioned by a driver/backend. Some possibilities discussed: A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name Entities just remain in PENDING_CREATE until provisioned by a driver Entities just remain in ACTIVE until provisioned by a driver Opinions and suggestions? ___ 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] Status of entities that do not exist in a driver backend
+1 to QUEUED status. For entities that have the concept of being attached/detached why not have a 'DETACHED' status to indicate that the entity is not provisioned at all (i.e. The config is just stored in the DB). When it is attached during provisioning then we can set it to 'ACTIVE' or any of the other provisioning statuses such as 'ERROR', 'PENDING_UPDATE', etc. Lastly, it wouldn't make much sense to have a 'DELETED' status on these types of entities until the user actually issues a DELETE API request (not to be confused with detaching). Which begs another question, when items are deleted how long should the API return responses for that resource? We have a 90 day threshold for this in our current implementation after which the API returns 404's for the resource. Cheers, --Jorge On 7/3/14 10:39 AM, Phillip Toohill phillip.tooh...@rackspace.com wrote: If the objects remain in 'PENDING_CREATE' until provisioned it would seem that the process got stuck in that status and may be in a bad state from user perspective. I like the idea of QUEUED or similar to reference that the object has been accepted but not provisioned. Phil On 7/3/14 10:28 AM, Brandon Logan brandon.lo...@rackspace.com wrote: With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about which driver to use (through provider or flavor). If a Listener, Pool, Member, or Health Monitor is created without a link to a Load Balancer, then what status does it have? At this point it only exists in the database and is really just waiting to be provisioned by a driver/backend. Some possibilities discussed: A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name Entities just remain in PENDING_CREATE until provisioned by a driver Entities just remain in ACTIVE until provisioned by a driver Opinions and suggestions? ___ 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
Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend
Hi Jorge, +1 for QUEUED and DETACHED I would suggest to make the time how long we keep entities in DELETED state configurable. We use something like 30 days, too, but we have made it configurable to adapt to changes... German -Original Message- From: Jorge Miramontes [mailto:jorge.miramon...@rackspace.com] Sent: Thursday, July 03, 2014 11:59 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Neutron][LBaaS] Status of entities that do not exist in a driver backend +1 to QUEUED status. For entities that have the concept of being attached/detached why not have a 'DETACHED' status to indicate that the entity is not provisioned at all (i.e. The config is just stored in the DB). When it is attached during provisioning then we can set it to 'ACTIVE' or any of the other provisioning statuses such as 'ERROR', 'PENDING_UPDATE', etc. Lastly, it wouldn't make much sense to have a 'DELETED' status on these types of entities until the user actually issues a DELETE API request (not to be confused with detaching). Which begs another question, when items are deleted how long should the API return responses for that resource? We have a 90 day threshold for this in our current implementation after which the API returns 404's for the resource. Cheers, --Jorge On 7/3/14 10:39 AM, Phillip Toohill phillip.tooh...@rackspace.com wrote: If the objects remain in 'PENDING_CREATE' until provisioned it would seem that the process got stuck in that status and may be in a bad state from user perspective. I like the idea of QUEUED or similar to reference that the object has been accepted but not provisioned. Phil On 7/3/14 10:28 AM, Brandon Logan brandon.lo...@rackspace.com wrote: With the new API and object model refactor there have been some issues arising dealing with the status of entities. The main issue is that Listener, Pool, Member, and Health Monitor can exist independent of a Load Balancer. The Load Balancer is the entity that will contain the information about which driver to use (through provider or flavor). If a Listener, Pool, Member, or Health Monitor is created without a link to a Load Balancer, then what status does it have? At this point it only exists in the database and is really just waiting to be provisioned by a driver/backend. Some possibilities discussed: A new status of QUEUED, PENDING_ACTIVE, SCHEDULED, or some other name Entities just remain in PENDING_CREATE until provisioned by a driver Entities just remain in ACTIVE until provisioned by a driver Opinions and suggestions? ___ 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
