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/ but can still issue a GET on /loadbalancers//usage. If /loadbalancers/ 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" wrote: > >On Jul 4, 2014, at 5:27 PM, Brandon Logan >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
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/ but can still issue a GET on /loadbalancers//usage. If /loadbalancers/ 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" wrote: > >On Jul 4, 2014, at 5:27 PM, Brandon Logan >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
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 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
On Jul 4, 2014, at 5:27 PM, Brandon Logan 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
+1 to QUEUED status. On Fri, Jul 4, 2014 at 5:27 PM, Brandon Logan 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" > > 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" > 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
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" > 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" 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
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" 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" 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
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" 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" 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
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" 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] [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
