[openstack-dev] Development Issue: Cloud System Security Auditing
To whom it may concern, We are planning to work on the *Cloud System* for our undergraduate thesis. Our main concern is *Cloud System Security* where we want to produce a *auditing tool/software* that can scan a cloud system and test its vulnerability. In this concern we need some feedback about the progress of work in this field. We look forward to any help or suggestions from your side as our terminal goal is to contribute to the community. Thank You, Ahsan Habib Zunayeed Bin Zahir North South University Dhaka Bangladesh ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] os-cloud-config ssh access to cloud
Excerpts from Adam Young's message of 2014-03-12 06:19:47 -0700:
On 03/11/2014 01:20 PM, Clint Byrum wrote:
Excerpts from Adam Young's message of 2014-03-11 07:50:58 -0700:
On 03/11/2014 05:25 AM, Dmitry Mescheryakov wrote:
For what it's worth in Sahara (former Savanna) we inject the second
key by userdata. I.e. we add
echo ${public_key} ${user_home}/.ssh/authorized_keys
to the other stuff we do in userdata.
Dmitry
2014-03-10 17:10 GMT+04:00 Jiří Stránský ji...@redhat.com:
On 7.3.2014 14:50, Imre Farkas wrote:
On 03/07/2014 10:30 AM, Jiří Stránský wrote:
Hi,
there's one step in cloud initialization that is performed over SSH --
calling keystone-manage pki_setup. Here's the relevant code in
keystone-init [1], here's a review for moving the functionality to
os-cloud-config [2].
You really should not be doing this. I should never have written
pki_setup: it is a developers tool: user a real CA and a real
certificate.
This alludes to your point, but also says that keystone-manage can be used:
http://docs.openstack.org/developer/keystone/configuration.html#certificates-for-pki
Yep. And we need to get a better story for certificate management.
Seems that some time should be spent making this more clear if for some
reason pki_setup is weak for production use cases. My brief analysis
of the code says that the weakness is that the CA should generally be
kept apart from the CSR's so that a compromise of a node does not lead
to an attacker being able to generate their own keystone service. This
seems like a low probability attack vector, as compromise of the keystone
machines also means write access to the token backend, and thus no need
to generate ones' own tokens (you can just steal all the existing tokens).
This is a pretty good explanation. I would love to see it submitted as
part of the keystone configuration document above.
Thanks!
https://review.openstack.org/80819
I'd like to see it called out in the section above though, so that
users can know what risk their accepting when they use what looks like a
recommended tool. Another thing would be to log copious warnings when
pki_setup is run that it is not for production usage. That should be
sufficient to scare some diligent deployers into reading the docs closely
and mitigating the risk.
Very good idea.
Anyway, shaking fist at users and devs in -dev for using tools in the
documentation probably _isn't_ going to convince anyone to spend more
time setting up PKI tokens.
The only one I am shaking my fist at is myself...and maybe those that
browbeat me into writing the utility.
I recommend we aim for less fist shaking and beating of all kinds in
OpenStack.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] how to extend port capability using binding:profile
Hi all, I'd like to extend port capability using ML2 binding:profile. I checked the official docs and it seems that there's no guide for it. Is there any CLI support for port binding:profile? Or is there any development guide on how to set up profile? -- --- cheers, Li Ma ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Mistral] Actions design BP
Excerpts from Renat Akhmerov's message of 2014-03-13 01:55:46 -0700: Joshua, Thanks for your interest and feedback. I believe you were able to deliver your message already, we definitely hear you. So no need to the same stuff again and again ;) As I promised before, we are now evaluating what’s been going on with TaskFlow for the last couple of months and preparing our questions/concerns/suggestions on using it within Mistral. But that’s not very easy and quick thing to do since there’s a bunch of details to take into account, especially given the fact that Mistral codebase has become much more solid and Mistral itself now has lots of requirements dictated by its use cases and roadmap vision. So patience would be really appreciated here. If you don’t mind I would prefer to discuss things like that in separate threads, not in threads devoted to daily project activities. So that we can split our conceptual discussions and current work that’s going on according to our plans. Otherwise we have a risk to make spaghetti out of our ML threads. From my perspective, as somebody who is considering Mistral for some important things, the fact that the taskflow people are not aligned with the Mistral people tells me that Mistral is not what I thought it was: taskflow for direct user consumption. So, while it may be annoying to have your day to day project activities questioned, it is pretty core to the discussion considering that this suggests several things that diverge from taskflow's core model. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Hierarchicical Multitenancy Discussion
On Fri, 2014-03-14 at 13:43 -0700, Vishvananda Ishaya wrote: Awesome, this is exactly what I was thinking. I think this is really close to being usable on the nova side. First of all the dot.sperated.form looks better imo, and I think my code should still work that way as well. The other piece that is needed is mapping ids to names for display purposes. I did something like this for a prototype of names in dns caching that should work nicely. The question simply becomes how do we expose those names. I’m thinking we have to add an output field to the display of objects in the system showing the fully qualified name. We can then switch the display in novaclient to show names instead of ids. That way an admin listing all the projects in orga would see the owner as orga.projb instead of the id string. The other option would be to pass names instead of ids from keystone and store those instead. That seems simpler at first glance, it is not backwards compatible with the current model so it will be painful for providers to switch. -1 for instead of. in addition to would have been fine, IMO. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [db][all] (Proposal) Restorable Delayed deletion of OS Resources
Interesting, the usage of stop to do this could work since the semantics are similar enough. People could even remap delete to stop and force-delete to delete and this would be a solution as well (or as u said use a cronjob/deletion service/janitor crew that does the force-delete). Good idea! Sent from my really tiny device... On Mar 15, 2014, at 8:41 AM, Clint Byrum cl...@fewbar.com wrote: Excerpts from Joshua Harlow's message of 2014-03-13 16:16:50 -0700: Seems ok to me, and likely a good start, although I'm still not very comfortable with the effects of soft_deletion (unless its done by admins only), to me it complicates scheduling (can u schedule to something that has been soft_deleted, likely not). It also creates a pool of resources that can't be used but can't be deleted either, that sounds a little bad and wastes companies $$ and it reinforces non-cloudly concepts. It also seems very complex, especially when your start connecting more and more resources together via heat or other system (the whole graph of resources now must be soft_deleted, wasting more $$, and how does one restore the graph of resources if some of them were also hard_deleted). I think you stay clear of scheduling if you treat it as a stopped resource. It is costing you to be there, even if it isn't using the CPU and RAM, it is a form of reservation. The pool of unusable resources must be built into the price for undeletable resources. How long to keep things around is a business decision. I could see an evolution of the feature that includes undelete period in the flavor definition. The fact that one would need to be able to undelete whole applications is just a missing feature. In the case of Heat, it would definitely get complicated if you went out of band and accidentally deleted things but it would be uncomplicated as long as you undeleted it before Heat tried to do an in-place operation like a Metadata change + waitcondition or a rebuild/resize. I think though, that we already have this feature for most things in the form of stop versus delete. The way I would implement undelete is at the policy level. Deny delete to users, and provide a cron-like functionality for deleting. Let them decide how long they'd like to keep things around for, and then let the cron-like thing do the actual deleting. I believe a few of these cron-as-a-service things already exist. ___ 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] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 15/03/14 02:33, Jiří Stránský wrote:
On 12.3.2014 17:03, Jiří Stránský wrote:
Thanks for all the replies everyone :)
I'm leaning towards going the way Robert suggested on the review [1] -
upload pre-created signing cert, signing key and CA cert to controller
nodes using Heat. This seems like a much cleaner approach to
initializing overcloud than having to SSH into it, and it will solve
both problems i outlined in the initial e-mail.
It creates another problem though - for simple (think PoC) deployments
without external CA we'll need to create the keys/certs
somehow/somewhere anyway :) It shouldn't be hard because it's already
implemented in keystone-manage pki_setup but we should figure out a way
to avoid copy-pasting the world. Maybe Tuskar calling pki_setup locally
and passing a parameter to pki_setup to override default location where
new keys/certs will be generated?
Thanks
Jirka
[1] https://review.openstack.org/#/c/78148/
I'm adding [Heat] to the subject. After some discussion on IRC it
seems that what we need to do with Heat is not totally straightforward.
Here's an attempt at a brief summary:
In TripleO we deploy OpenStack using Heat, the cloud is described in a
Heat template [1]. We want to externally generate and then upload 3
small binary files to the controller nodes (Keystone PKI key and
certificates [2]). We don't want to generate them in place or scp them
into the controller nodes, because that would require having ssh
access to the deployed controller nodes, which comes with drawbacks [3].
It would be good if we could have the 3 binary files put into the
controller nodes as part of the Heat stack creation. Can we include
them in the template somehow? Or is there an alternative feasible
approach?
Thank you
Jirka
[1]
https://github.com/openstack/tripleo-heat-templates/blob/0490dd665899d3265a72965aeaf3a342275f4328/overcloud-source.yaml
[2]
http://docs.openstack.org/developer/keystone/configuration.html#install-external-signing-certificate
[3]
http://lists.openstack.org/pipermail/openstack-dev/2014-March/029327.html
It looks like the cert files you want to transfer are all ascii rather
than binary, which is good as we have yet to implement a way to attach
binary data to a heat stack create call.
One way to write out these files would be using cloud-config. The
disadvantages of this is that it is boot-time config only, so those keys
couldn't be updated with a stack update. You would also be consuming a
decent proportion of your 16k user_data limit.
keystone_certs_config:
Type: OS::Heat::CloudConfig
Properties:
cloud_config:
write_files:
- path: /etc/keystone/ssl/certs/signing_cert.pem
content: |
# You have 3 options for how to insert the content here:
# 1. inline the content
# 2. Same as 1, but automatically with your own template
pre-processing logic
# 3. call {get_file: path/to/your/signing_cert.pem} but this
only works for HOT syntax templates
permissions: '0600'
keystone_init:
Type: OS::Heat::MultipartMime
Properties:
parts:
- subtype: cloud-config
config:
get_resource: keystone_certs_config
notCompute0:
Type: OS::Nova::Server
Properties:
user_data: {Ref: keystone_init}
But it looks like you should just be using os-apply-config templates for
all of the files in /etc/keystone/ssl/certs/
notCompute0Config:
Type: AWS::AutoScaling::LaunchConfiguration
...
Metadata:
...
keystone:
signing_cert: |
# You have 3 options for how to insert the content here:
# 1. inline the content
# 2. Same as 1, but automatically with your own template
pre-processing logic
# 3. call {get_file: path/to/your/signing_cert.pem} but this
only works for HOT syntax templates
If the files really are binary then currently you'll have to encode to
base64 before including the content in your templates, then have an
os-refresh-config script to decode and write out the binary files.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 17/03/14 10:14, Robert Collins wrote: On 17 March 2014 09:20, Steve Baker sba...@redhat.com wrote: It looks like the cert files you want to transfer are all ascii rather than binary, which is good as we have yet to implement a way to attach binary data to a heat stack create call. One way to write out these files would be using cloud-config. The disadvantages of this is that it is boot-time config only, so those keys couldn't be updated with a stack update. You would also be consuming a decent proportion of your 16k user_data limit. I'm confused - why can't we include them in the template? We include an SSH key in ascii form already with no issue. You can include them in the template. That template snippet shows how to specify cloud-config in the template. However I would recommend just going with the os-apply-config templates (the second option in that email). I probably shouldn't have mentioned cloud-config as an option at all. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 17 March 2014 09:20, Steve Baker sba...@redhat.com wrote: It looks like the cert files you want to transfer are all ascii rather than binary, which is good as we have yet to implement a way to attach binary data to a heat stack create call. One way to write out these files would be using cloud-config. The disadvantages of this is that it is boot-time config only, so those keys couldn't be updated with a stack update. You would also be consuming a decent proportion of your 16k user_data limit. I'm confused - why can't we include them in the template? We include an SSH key in ascii form already with no issue. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] [Heat] os-cloud-config ssh access to cloud
On 17 March 2014 10:32, Steve Baker sba...@redhat.com wrote: On 17/03/14 10:14, Robert Collins wrote: On 17 March 2014 09:20, Steve Baker sba...@redhat.com wrote: It looks like the cert files you want to transfer are all ascii rather than binary, which is good as we have yet to implement a way to attach binary data to a heat stack create call. One way to write out these files would be using cloud-config. The disadvantages of this is that it is boot-time config only, so those keys couldn't be updated with a stack update. You would also be consuming a decent proportion of your 16k user_data limit. I'm confused - why can't we include them in the template? We include an SSH key in ascii form already with no issue. You can include them in the template. That template snippet shows how to specify cloud-config in the template. However I would recommend just going with the os-apply-config templates (the second option in that email). I probably shouldn't have mentioned cloud-config as an option at all. Righto - thats what I meant. Shove it in heat, pull it out in heat metadata, apply via o-a-c. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [gantt] scheduler sub-group meeting 3/18 - Cancel
I can't make the meeting this week so, unless someone else wants to volunteer to run the meeting, let's cancel this one. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Operators Design Summit ideas for Atlanta
All, Many times we've heard a desire for more feedback and interaction from users. However, their attendance at design summit sessions is met with varied success. However, last summit, by happy accident, a swift session turned into a something a lot more user driven. A competent user was able to describe their use case, and the developers were able to stage a number of question to them. In this way, some of the assumptions about the way certain things were implemented, and the various priorities of future plans became clearer. It worked really well ... perhaps this is something we'd like to have happen for all the projects? *Idea*: Add an ops session for each project in the design summit https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions Most operators running OpenStack tend to treat it more holistically than those coding it. They are aware of, but don't necessarily think or work in terms of project breakdowns. To this end, I'd imagine the such sessions would: * have a primary purpose for developers to ask the operators to answer questions, and request information * allow operators to tell the developers things (give feedback) as a secondary purpose that could potentially be covered better in a cross-project session * need good moderation, for example to push operator-to-operator discussion into forums with more time available (eg https://etherpad.openstack.org/p/ATL-ops-unconference-RFC ) * be reinforced by having volunteer good users in potentially every design summit session (https://etherpad.openstack.org/p/ATL-ops-in-design-sessions ) Anyway, just a strawman - please jump on the etherpad (https://etherpad.openstack.org/p/ATL-ops-dedicated-design-summit-sessions) or leave your replies here! Regards, Tom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Run Tempest with new test case
Hi, Oscar First, openstack-qa ML is deprecated now as I said before. So please do not send an e-mail to openstack-qa ML. On 03/10, Oscar Correia wrote: I have new test case and I would like add inside Tempest directory and after execute, example: test case Swift for object and container. How is the process? Have you read How_To_Contribute wiki page[1]? Before contributing your code, you need to agree with the contributors license agreement. And, you also need to know Gerrit Workflow[2]. This is the process. [1] https://wiki.openstack.org/wiki/How_To_Contribute [2] https://wiki.openstack.org/wiki/GerritWorkflow Best Regards, -- Masayuki Igawa Oscar CorreiaCTwww.lettersvitae.comSkype: oscar.correiaFacebook: Letters VitaeE-Mail: oscar_correiaj@hotmail.comoscarmo...@lettersvitae.com Regis Regum servitium -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] Some thoughts on the nova-specs design process
Hi. So I've written a blueprint for nova for Juno, and uploaded it to nova-specs (https://review.openstack.org/#/c/80865/). That got me thinking about what this process might look like, and this is what I came up with: * create a launchpad blueprint * you write a proposal in the nova-specs repo * add the blueprint to the commit message of the design proposal, and send the design proposal off for review * advertise the existence of the design proposal to relevant stake holders (other people who hack on that bit of the code, operators mailing list if relevant, etc) * when the proposal is approved, it merges into the nova-specs git repo and nova-drivers then mark the launchpad blueprint as approved * off you go with development as normal This has the advantage that there's always a launchpad blueprint, and that the spec review is associated with that blueprint. That way someone who finds the launchpad blueprint but wants to see the actual design proposal can easily do so because it is linked as an addressed by review on the blueprint. Thoughts? Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] Automatic version creation in PBR
Right now PBR's creation of versions for postversioning is problematic - it generates versions that (if recognized by pip) would be treated as releases, even when its a non-tagged commit. https://etherpad.openstack.org/p/pbr-postversion-semver The tl;dr is a proposal to generate dev marked versions of the lowest possible higher tag that we would accept - which would be any of full release or alpha/beta/rc A related but can be done separately change is to pick version strings for alpha releases that are compatible with both PEP 440 and semver. Feedback solicited - if this is something contentious, we can make it an opt-in feature, but it seems unambiguously better to the folk that chatted through it on #openstack-infra, so ideally I'd like to transition any existing incompatible tags we have, and then land code to make this the behaviour for post-versioned (the default - no 'version' key in setup.cfg) untagged commits. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Some thoughts on the nova-specs design process
On Mar 16, 2014, at 7:58 PM, Michael Still mi...@stillhq.com wrote: Hi. So I've written a blueprint for nova for Juno, and uploaded it to nova-specs (https://review.openstack.org/#/c/80865/). That got me thinking about what this process might look like, and this is what I came up with: * create a launchpad blueprint * you write a proposal in the nova-specs repo * add the blueprint to the commit message of the design proposal, and send the design proposal off for review * advertise the existence of the design proposal to relevant stake holders (other people who hack on that bit of the code, operators mailing list if relevant, etc) * when the proposal is approved, it merges into the nova-specs git repo and nova-drivers then mark the launchpad blueprint as approved * off you go with development as normal This has the advantage that there's always a launchpad blueprint, and that the spec review is associated with that blueprint. That way someone who finds the launchpad blueprint but wants to see the actual design proposal can easily do so because it is linked as an addressed by review on the blueprint. Thoughts? Makes sense to me. - Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Some thoughts on the nova-specs design process
On Mon, Mar 17, 2014 at 3:00 PM, Chris Behrens cbehr...@codestud.com wrote: On Mar 16, 2014, at 7:58 PM, Michael Still mi...@stillhq.com wrote: Hi. So I've written a blueprint for nova for Juno, and uploaded it to nova-specs (https://review.openstack.org/#/c/80865/). That got me thinking about what this process might look like, and this is what I came up with: * create a launchpad blueprint * you write a proposal in the nova-specs repo * add the blueprint to the commit message of the design proposal, and send the design proposal off for review * advertise the existence of the design proposal to relevant stake holders (other people who hack on that bit of the code, operators mailing list if relevant, etc) * when the proposal is approved, it merges into the nova-specs git repo and nova-drivers then mark the launchpad blueprint as approved * off you go with development as normal This has the advantage that there's always a launchpad blueprint, and that the spec review is associated with that blueprint. That way someone who finds the launchpad blueprint but wants to see the actual design proposal can easily do so because it is linked as an addressed by review on the blueprint. Thoughts? Makes sense to me. One possible wart is I'm not sure how Launchpad handles git repos. Will a commit to nova-specs get a comment added to a nova blueprint? Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Some thoughts on the nova-specs design process
On Mon, 17 Mar 2014 13:58:20 +1100 Michael Still mi...@stillhq.com wrote: So I've written a blueprint for nova for Juno, and uploaded it to nova-specs (https://review.openstack.org/#/c/80865/). That got me thinking about what this process might look like, and this is what I came up with: * create a launchpad blueprint * you write a proposal in the nova-specs repo * add the blueprint to the commit message of the design proposal, and send the design proposal off for review * advertise the existence of the design proposal to relevant stake holders (other people who hack on that bit of the code, operators mailing list if relevant, etc) * when the proposal is approved, it merges into the nova-specs git repo and nova-drivers then mark the launchpad blueprint as approved * off you go with development as normal This has the advantage that there's always a launchpad blueprint, and that the spec review is associated with that blueprint. That way someone who finds the launchpad blueprint but wants to see the actual design proposal can easily do so because it is linked as an addressed by review on the blueprint. Thoughts? To accommodate those who happen to find the blueprint first, I think we need a link from the blueprint to the nova-specs review or when its approved into the nova-specs repository. I kind of expected the link from the blueprint to review to happen automatically, but it doesn't seem to have happened for your example. Chris. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Some thoughts on the nova-specs design process
On Mon, Mar 17, 2014 at 3:21 PM, Christopher Yeoh cbky...@gmail.com wrote: To accommodate those who happen to find the blueprint first, I think we need a link from the blueprint to the nova-specs review or when its approved into the nova-specs repository. I kind of expected the link from the blueprint to review to happen automatically, but it doesn't seem to have happened for your example. I think this is because of the git repo problem (its a proposed commit for nova-specs not nova). I'm not sure how to fix that apart from expecting the author to create a comment in the launchpad blueprint manually, but perhaps that's good enough. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [db][all] (Proposal) Restorable Delayed deletion of OS Resources
Hope this is not too late to ask this question, but isn't this extra code just fat finger mistakes? IME, most provisioning on cloud happens via automated tools, and it seems counter-productive to design a feature for manual operations. Thx, Subbu On Mar 13, 2014, at 12:42 PM, Boris Pavlovic bpavlo...@mirantis.com wrote: Hi stackers, As a result of discussion: [openstack-dev] [all][db][performance] Proposal: Get rid of soft deletion (step by step) http://osdir.com/ml/openstack-dev/2014-03/msg00947.html I understood that there should be another proposal. About how we should implement Restorable Delayed Deletion of OpenStack Resource in common way without these hacks with soft deletion in DB. It is actually very simple, take a look at this document: https://docs.google.com/document/d/1WGrIgMtWJqPDyT6PkPeZhNpej2Q9Mwimula8S8lYGV4/edit?usp=sharing Best regards, Boris Pavlovic ___ 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
