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
