Open Stack

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: OpenStack-dev-request at lists.openstack.org?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