Re: [openstack-dev] [heat] heat delete woes in Juno
Steve, I have two environments now, and although they have some other differences, one of them is Juno.2 and I've also been unable to repro it there. That env also lacks the same scale, load, and HA config so I was trying to figure out whether it was Juno.2 or not, so thanks for the extra data point. I am rolling out stack-abandon soon and will try to also get Juno.2 heat out soon. If I hit more examples, I'll file bugs. Thanks for the assistance all. On Sun, Mar 29, 2015 at 2:35 PM, Steve Baker sba...@redhat.com wrote: On 28/03/15 09:05, Matt Fischer wrote: Pavlo, Here is a link to one of the stacks. It is fairly simple just some routers/nets/subnets. The description is a bit odd perhaps, but legal. I've changed the template to not point at IPs at internal DNS. http://paste.ubuntu.com/10690759/ I've not been able to reproduce with this template running my local Juno 2014.2.2 or a recent devstack, but I'm sure you can. I created and deleted this in a loop about 5 times and it finally failed to delete on the last run. Now that it is stuck in DELETE_FAILED no amount of deleting will help. I'm concerned that a template this simple can get stuck like this. You should be able to delete the underlying resources using the neutron command, then delete the stack. I will have stack_abandon enabled next week as it just landed in Puppet: https://review.openstack.org/#/c/168157/ and will plan on trying that then. We've needed a series of workarounds for neutron resources as there are often implicit dependencies created which are not declared in REST create calls. Its likely you've discovered some more implicit dependencies which we need to handle. Could you please raise a bug [1] with the following? - the above pasted template - the heat event-list of the DELETE_FAILED stack - the heat stack-show of the DELETE_FAILED stack [1] https://bugs.launchpad.net/heat/+filebug On Thu, Mar 26, 2015 at 12:40 PM, Pavlo Shchelokovskyy pshchelokovs...@mirantis.com wrote: Hi Matt, if it would be feasible/appropriate, could you provide us with templates for stacks that show this behavior (try to get them with heat template-show stack-name-or-id)? This would help us to test and understand the problem better. And yes, just the day before I was contacted by one of my colleagues who seems to experience similar problems with Juno-based OpenStack deployment (though I did not had a chance to look through the issue yet). Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com On Thu, Mar 26, 2015 at 8:17 PM, Matt Fischer m...@mattfischer.com wrote: Nobody on the operators list had any ideas on this, so re-posting here. We've been having some issues with heat delete-stack in Juno. The issues generally fall into three categories: 1) it takes multiple calls to heat to delete a stack. Presumably due to heat being unable to figure out the ordering on deletion and resources being in use. 2) undeleteable stacks. Stacks that refuse to delete, get stuck in DELETE_FAILED state. In this case, they show up in stack-list and stack-show, yet resource-list and stack-delete deny their existence. This means I can't be sure whether they have any real resources very easily. 3) As a corollary to item 1, stacks for which heat can never unwind the dependencies and stay in DELETE_IN_PROGRESS forever. Does anyone have any work-arounds for these or recommendations on cleanup? My main worry is removing a stack from the database that is still consuming the customer's resources. I also don't just want to remove stacks from the database and leave orphaned records in the DB. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions)
[openstack-dev] [Sahara] Question about Sahara API v2
Hi all, Recently I have read some contents about Sahara API v2 propose, but I am still a bit confused why we are doing so at this stage. I read the bp https://blueprints.launchpad.net/sahara/+spec/v2-api-impl and the involved gerrit reviews (although already abandoned). However, I did not find anything new than current v1+v1.1 APIs. So why do we want v2 API? Just to combine v1 and v1.1 APIs? Is there any deeper requirement or background needs us to do so? Please let me know that if yes. Btw, I also see some comments that we may want to introduce PECAN to implement Sahara APIs. Will that be soon in Liberty, or not decided yet? Thanks a lot. -Ken __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ceilometer][FFE] Floating IP traffic statistics meters
Hi Megh, Thanks for contributing to Ceilometer. I've left some comment on your patch. Also, ceilometer follows the official blueprint/spec process as described https://wiki.openstack.org/wiki/Blueprints. -Lianhao -Original Message- From: Megh Bhatt [mailto:me...@juniper.net] Sent: Saturday, March 28, 2015 8:56 AM To: openstack-dev@lists.openstack.org Subject: [openstack-dev] [ceilometer][FFE] Floating IP traffic statistics meters Hello, Apologies for the double post, forgot to include FFE in the subject: I'd like to request an exemption for the following to go into the Kilo release. This work is crucial for: Cloud operators need to be able to bill customers based on floating IP traffic statistics. Why this needs an FFE? It's officially new feature adding 4 new meters Status of the work: In summary the patch only introduces 4 new meters - ip.floating.transmit.packets, ip.floating.transmit.bytes, ip.floating.receive.packets, ip.floating.receive.bytes and adds 2 new functions to the neutron_client - a) Function to get list of all floating IPs and 2) Get information about a specific port. - The patch necessary for this is already submitted for the review - https://review.openstack.org/#/c/166491/ - The document impact patch has already been reviewed and is waiting for the ceilometer commit to go through - https://review.openstack.org/#/c/166489/ Thanks Megh __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev- requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [oslo.messaging][zeromq] introduce Request-Reply pattern to improve the stability
Hi all, I'd like to propose a simple but straightforward method to improve the stability of the current implementation. Here's the current implementation: receiver(PULL(tcp)) -- service(PUSH(tcp)) receiver(PUB(ipc)) -- service(SUB(ipc)) receiver(PUSH(ipc)) -- service(PULL(ipc)) Actually, as far as I know, the local IPC method is much more stable than network. I'd like to switch PULL/PUSH to REP/REQ for TCP communication. The change is very simple but effective for stable network communication. I cannot apply the patch for our production systems. I tried it in my lab, and it works well. I know there's another blueprint for REP/REQ pattern [1], but it's not the same, I think. I'd like to discuss it about how to take advantage of REP/REQ of zeromq. [1] https://review.openstack.org/#/c/154094/2/specs/kilo/zmq-req-rep-call.rst Best regards, -- Li Ma (Nick) Email: skywalker.n...@gmail.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?
On 03/27/2015 07:21 AM, Sean Dague wrote: On 03/26/2015 06:46 PM, Robert Collins wrote: On 27 March 2015 at 09:14, Ryan Brown rybr...@redhat.com wrote: Ooof, that's huge. If we can configure it to be less aggressive I love the *idea* of having everything formatted semantically, but that's a pretty major burden for everyone involved. It's huge today. It wouldn't be if we did it :). I suggest that given the other aspects of our code review system, we might treat this like translations as a long term thing - that is setup a job somewhere to run the autoformatter against trunk and submit the result as a patchset. To get over the initial hump, I'd have a human break the patch up into per-file changes or some such. A variation would be to have a config file saying which files are covered, and slowly dial that up, one file at a time. Once everything is covered, and we're dealing with commits that change things async (via the job above), then we can talk about how to help developers submit code using it in the first place. Honestly, is there a problem here that really needs to be solved? I've been a little confused about this thread because I thought we're all actively calling people out for nit picking irrelevant style issues. I feel like building a large system to avoid not being human to each other as completely dysfunctional. In the Nova tree we have many cross cutting efforts that need to touch a lot of things (v3 renames, mox - mock). This seems like giant churn for no real gain. I'm not convinced the answer to white space fights is a tool. I think it's stop being silly, actively call out cores when they are, and actively call out new folks that it is completely unhelpful in the reviewing (and only going to raise ire of core teams, not ingratiate yourself). ++ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Regarding the algorithm parameter mentioned in the POST call to store the secret
Hi All,
What is the importance of mentioning the algorithm type in the POST call ,
since we already have the secret.
Are we trying the encrypt the actual secret using the algorithm mentioned
in the POST call .If yes what is the key that is used to encrypt the secret
since we require the algorithm, key and actual information(payload) to
encrypt the any information.
For ex : Consider the POST CALL below with algorithm aes
POST v1/secrets
Header: content-type=application/json
X-Project-Id: {project_id}
{
name: AES key,
expiration: 2014-02-28T19:14:44.180394,
algorithm: aes,
bit_length: 256,
mode: cbc,
payload: gF6+lLoF3ohA9aPRpt+6bQ==,
payload_content_type: application/octet-stream,
payload_content_encoding: base64,
secret_type: opaque
}
What are the different algorithms supported in this POST CALL.
Any Help would be appreciated .Thanks in advance
--
*Thanks and Regards*
*Asha Seshagiri*
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Barbican : Use of consumer resource
Hi All, Once the consumer resource registers to the containers , how does the consumer resource consume the container resource? Is there any API supporting the above operation. Could any one please help on this? -- *Thanks and Regards,* *Asha Seshagiri* __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Neutron] Status of the nova-network to Neutron migration work
Does the decision about the floating IP have to be based on the use of the private IP in the original destination, or could you get by with rules on the L3 agent to avoid NAT just based on the destination being in a configured set of CIDRs? If you could get by with the latter it would be a much simpler problem to solve. However, I suspect you will want the former to be able to connect to floating IPs internally as well. On Mar 28, 2015 12:24 PM, Steve Wormley openst...@wormley.com wrote: On Sat, Mar 28, 2015 at 1:57 AM, Kevin Benton blak...@gmail.com wrote: You want floating IPs at each compute node, and DVR with VLAN support got you close. Are the floating IPs okay being on a different network/VLAN? I should clarify, the floating IPs are publicly routable addresses, as opposed to instances on RFC1918 space. This is the 'standard' neutron and nova-network floating IP model. Nothing really special there. Which address do you expect the source to be when an instance communicates outside of its network (no existing connection state)? You mentioned having the L3 agent ARP for a different gateway, do you still want the floating IP translation to happen before that? Is there any case where it should ever be via the private address? Instances with assigned floating IP addresses initiating connections are NATted and go out the floating IP. In reality, we special case all RFC 1918 space to not trigger the floating IP. The header mangling is to make up for the fact that traffic coming to the floating IP gets translated by the L3 agent before it makes it to the instance so there is no way to distinguish whether the floating IP or private IP was targeted. Is that correct? Basically. Traffic coming in on a tenant vlan to the instance is mangled by the first OVS rule it hits to indicate it came in via a private interface/subnet/VLAN. It then hits iptables on the instance Linux bridge with turns the header bits onto a conntrack mark. The outbound packets from the instance for connection gets the conntrack mark changed back to a header bit. If this packet then hits iptables in the qrouter namespace where it's turned into a normal fwmark/nfmark. That mark is used to disable NAT for the packet and flags the ip route rules to not send the packet to the FIP namespace but to instead let it flow normally. Of course, all this horribleness is because the veth drivers in Linux wipe the SKB Mark(fwmark/nfmark) so I have no way to persistently track a packet across the OVS-veth-Linux Bridge boundaries. -Steve Wormley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Nominate Irina Povolotskaya for fuel-docs core
+1 /sv On Fri, Mar 27, 2015 at 5:31 PM, Anastasia Urlapova aurlap...@mirantis.com wrote: + 10 On Fri, Mar 27, 2015 at 4:28 AM, Igor Zinovik izino...@mirantis.com wrote: +1 On 26 March 2015 at 19:26, Fabrizio Soppelsa fsoppe...@mirantis.com wrote: +1 definitely On 03/25/2015 10:10 PM, Dmitry Borodaenko wrote: Fuelers, I'd like to nominate Irina Povolotskaya for the fuel-docs-core team. She has contributed thousands of lines of documentation to Fuel over the past several months, and has been a diligent reviewer: http://stackalytics.com/?user_id=ipovolotskayarelease=allproject_type=allmodule=fuel-docs I believe it's time to grant her core reviewer rights in the fuel-docs repository. Core reviewer approval process definition: https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Igor Zinovik Deployment Engineer at Mirantis, Inc izino...@mirantis.com __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] initial OVN testing
Hi, I have added a few comments to the review and have a fixed a few issues that I have encountered along the way. I guess we can discuss on gerrit. Thanks Gary On 3/27/15, 12:54 AM, Russell Bryant rbry...@redhat.com wrote: Gary and Kyle, I saw in my IRC backlog that you guys were briefly talking about testing the Neutron ovn ml2 driver. I suppose it's time to add some more code to the devstack integration to install the current ovn branch and set up ovsdb-server to serve up the right database for this. I'll try to work on that tomorrow. Of course, note that all we can set up right now is the northbound database. None of the code that reacts to updates to that database is merged yet. We can still go ahead and test our code and make sure the expected data makes it there, though. Here's some more detail about the pieces ... When I was writing ovn-nbctl [1], I was testing using ovs-sandbox. It's a script that sets up a handy development environment for ovs. It has ovn support if you pass the -o option [2]. To run it, it would be something like ... $ git clone https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openvswitc h_ovs.gitd=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEsr=VlZxHpZ BmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3_L162t5yzwj7_ElFgaXTUhr 2xEDAk0cs=l4rfZ9jttb06ukaHzMgz_RDzsQDjUEf25puSLaKEZZEe= $ cd ovs $ git checkout ovn $ ./boot.sh $ ./configure $ make $ make SANDBOXFLAGS=-o sandbox From there you can run ovn-nbctl. Here's a script to demonstrate the various commands: https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_russe llb_946953e8675063c0c756d=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtX t-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3_L162t5y zwj7_ElFgaXTUhr2xEDAk0cs=vG12ShRj8kDdsQLwzI-4_s0aG41duG-_wlTwR2jWpmke= To set this up outside of ovs-sandbox, you need to first create the OVN northbound database: $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema Then you need to tell ovsdb-server to use it. By default ovsdb-server will only serve up conf.db. It can take a list of dbs as positional arguments, though. You can see that's what the ovs-sandbox script is doing. So, you can either change the command used to start ovsdb-server on your system, or start up another instance of it with its own unix socket and tcp port. There was also a question on IRC about the format of the database option for the ML2 driver. The value is passed directly to ovn-nbctl. The format is the same as is used for ovs-vsctl (and probably others). When running in ovs-sandbox, ovn-nbctl's help output shows: --db=DATABASE connect to DATABASE (default: unix:/home/rbryant/src/ovs/tutorial/sandbox/db.sock) and further down, it provides some more detail: Active database connection methods: tcp:IP:PORT PORT at remote IP ssl:IP:PORT SSL PORT at remote IP unix:FILE Unix domain socket named FILE Passive database connection methods: ptcp:PORT[:IP] listen to TCP PORT on IP pssl:PORT[:IP] listen for SSL on PORT on IP punix:FILE listen on Unix domain socket FILE [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_piperm ail_dev_2015-2DMarch_052757.htmld=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw- YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3 _L162t5yzwj7_ElFgaXTUhr2xEDAk0cs=NBPDQRkeI_pZKdXfwzZ11QKpjccl2wFKhVZr8rgK KCwe= [2] https://urldefense.proofpoint.com/v2/url?u=http-3A__openvswitch.org_piperm ail_dev_2015-2DMarch_052353.htmld=AwIDaQc=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw- YihVMNtXt-uEsr=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNcm=cQf2n9s_bEj3 _L162t5yzwj7_ElFgaXTUhr2xEDAk0cs=36n_EGBEv4v5nS3DoHsBHfgCoJQxXB176pfnHnbt 8eIe= -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!
On 03/24/2015 09:21 PM, Assaf Muller wrote: Note that https://review.openstack.org/#/c/166888/ has been merged. This means that the option has been deprecated for K and will be removed in L. Anyone using the non-default value of False will be looking at errors in his logs. Well, I have nothing to do with that option, but every time I see how cruel is Openstack toward users, I can't avoid to compare it to Linux. They keep code which is used by userspace forever. Even if it cause programmers feel like they need to work more. I understand that Openstack is growing and there are many 'baby mistakes' in the past. But next time you will be curios why someone still sitting on cactus, remember this case. Every new release of openstack is like new software where you need to learn everything from scratches. Compare this to modern Linux updates, where changes in the kernel almost invisible for userspace and new versions are 'for new features', not for 'oh, now I need to rewrite my libraries to support new version'. I'm not joking. Check out ruby's fog - it simply does not work in modern neutron-based network. Who is to blame? Users, obviously. Lazy bums without any respect to great work to rewrite and obsolete everything. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [heat] heat delete woes in Juno
On 28/03/15 09:05, Matt Fischer wrote: Pavlo, Here is a link to one of the stacks. It is fairly simple just some routers/nets/subnets. The description is a bit odd perhaps, but legal. I've changed the template to not point at IPs at internal DNS. http://paste.ubuntu.com/10690759/ I've not been able to reproduce with this template running my local Juno 2014.2.2 or a recent devstack, but I'm sure you can. I created and deleted this in a loop about 5 times and it finally failed to delete on the last run. Now that it is stuck in DELETE_FAILED no amount of deleting will help. I'm concerned that a template this simple can get stuck like this. You should be able to delete the underlying resources using the neutron command, then delete the stack. I will have stack_abandon enabled next week as it just landed in Puppet: https://review.openstack.org/#/c/168157/ and will plan on trying that then. We've needed a series of workarounds for neutron resources as there are often implicit dependencies created which are not declared in REST create calls. Its likely you've discovered some more implicit dependencies which we need to handle. Could you please raise a bug [1] with the following? - the above pasted template - the heat event-list of the DELETE_FAILED stack - the heat stack-show of the DELETE_FAILED stack [1] https://bugs.launchpad.net/heat/+filebug On Thu, Mar 26, 2015 at 12:40 PM, Pavlo Shchelokovskyy pshchelokovs...@mirantis.com mailto:pshchelokovs...@mirantis.com wrote: Hi Matt, if it would be feasible/appropriate, could you provide us with templates for stacks that show this behavior (try to get them with heat template-show stack-name-or-id)? This would help us to test and understand the problem better. And yes, just the day before I was contacted by one of my colleagues who seems to experience similar problems with Juno-based OpenStack deployment (though I did not had a chance to look through the issue yet). Best regards, Pavlo Shchelokovskyy Software Engineer Mirantis Inc www.mirantis.com http://www.mirantis.com On Thu, Mar 26, 2015 at 8:17 PM, Matt Fischer m...@mattfischer.com mailto:m...@mattfischer.com wrote: Nobody on the operators list had any ideas on this, so re-posting here. We've been having some issues with heatdelete-stack in Juno. The issues generally fall into three categories: 1) it takes multiple calls to heat to delete a stack. Presumably due to heat being unable to figure out the ordering on deletion and resources being in use. 2) undeleteable stacks. Stacks that refuse to delete, get stuck in DELETE_FAILED state. In this case, they show up in stack-list and stack-show, yet resource-list and stack-delete deny their existence. This means I can't be sure whether they have any real resources very easily. 3) As a corollary to item 1, stacks for which heat can never unwind the dependencies and stay in DELETE_IN_PROGRESS forever. Does anyone have any work-arounds for these or recommendations on cleanup? My main worry is removing a stack from the database that is still consuming the customer's resources. I also don't just want to remove stacks from the database and leave orphaned records in the DB. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
