On 9/30/2015 5:47 PM, Matt Fischer wrote:
Is the purge deleted a replacement for nova-manage db archive-deleted? It hasn't worked for several cycles and so I assume it's abandoned. On Sep 30, 2015 4:16 PM, "Matt Riedemann" <[email protected] <mailto:[email protected]>> wrote: On 9/29/2015 6:33 PM, Kris G. Lindgren wrote: Hello All, We have some pretty good contributions of local patches on the etherpad. We are going through right now and trying to group patches that multiple people are carrying and patches that people may not be carrying but solves a problem that they are running into. If you can take some time and either add your own local patches that you have to the ether pad or add +1's next to the patches that are laid out, it would help us immensely. The etherpad can be found at: https://etherpad.openstack.org/p/operator-local-patches Thanks for your help! ___________________________________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy From: "Kris G. Lindgren" Date: Tuesday, September 22, 2015 at 4:21 PM To: openstack-operators Subject: Re: Operator Local Patches Hello all, Friendly reminder: If you have local patches and haven't yet done so, please contribute to the etherpad at: https://etherpad.openstack.org/p/operator-local-patches ___________________________________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy From: "Kris G. Lindgren" Date: Friday, September 18, 2015 at 4:35 PM To: openstack-operators Cc: Tom Fifield Subject: Operator Local Patches Hello Operators! During the ops meetup in Palo Alto were we talking about sessions for Tokyo. A session that I purposed, that got a bunch of +1's, was about local patches that operators were carrying. From my experience this is done to either implement business logic, fix assumptions in projects that do not apply to your implementation, implement business requirements that are not yet implemented in openstack, or fix scale related bugs. What I would like to do is get a working group together to do the following: 1.) Document local patches that operators have (even those that are in gerrit right now waiting to be committed upstream) 2.) Figure out commonality in those patches 3.) Either upstream the common fixes to the appropriate projects or figure out if a hook can be added to allow people to run their code at that specific point 4.) ???? 5.) Profit To start this off, I have documented every patch, along with a description of what it does and why we did it (where needed), that GoDaddy is running [1]. What I am asking is that the operator community please update the etherpad with the patches that you are running, so that we have a good starting point for discussions in Tokyo and beyond. [1] - https://etherpad.openstack.org/p/operator-local-patches ___________________________________________________________________ Kris Lindgren Senior Linux Systems Engineer GoDaddy __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe <http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I saw this originally on the ops list and it's a great idea - cat herding the bazillion ops patches and seeing what common things rise to the top would be helpful. Hopefully some of that can then be pushed into the projects. There are a couple of things I could note that are specifically operator driven which could use eyes again. 1. purge deleted instances from nova database: http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/purge-deleted-instances-cmd.html The spec is approved for mitaka, the code is out for review. If people could test the change out it'd be helpful to vet it's usefulness. 2. I'm trying to revive a spec that was approved in liberty but the code never landed: https://review.openstack.org/#/c/226925/ That's for force resetting quotas for a project/user so that on the next pass it gets recalculated. A question came up about making the user optional in that command so it's going to require a bit more review before we re-approve for mitaka since the design changes slightly. 3. mgagne was good enough to propose a patch upstream to neutron for a script he had out of tree: https://review.openstack.org/#/c/221508/ That's a tool to deleted empty linux bridges. The neutron linuxbridge agent used to remove those automatically but it caused race problems with nova so that was removed, but it'd still be good to have a tool to remove then as needed. -- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe <http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
The spec [1] has the details on that, but really it's a stopgap until something better comes along (see the alternatives section in the spec).
Basically there are alternatives, but they are more complicated and therefore haven't been ironed out even though they've been discussed for a couple of cycles. So late(ish) in liberty we got talking about just adding a command in tree (that a lot of operators seem to hae anyway) until we can close that gap with the archival framework (or just do away with soft deleting things).
[1] http://specs.openstack.org/openstack/nova-specs/specs/mitaka/approved/purge-deleted-instances-cmd.html#problem-description
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
