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]> 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://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://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
