Crusty Blaa

I just wrote down a few pieces advice for someone submitting a large feature patch to Nova, so I thought I'd re-post it here:

• Think about what it is like to be a nova-core reviewer looking at a list of 40 to 60 reviews and having maybe 2 hours today to do reviews. Think about how to make it more likely that such a reviewer will choose your code to review.
• Small patches are easier to consume. The smaller you make the patch, the more likely it is that it will get reviewed quickly.
• Break your changes into a series of small, self-contained changes.
• The earlier in the release cycle you can begin submitting some of your changes the better. Don't wait until all of your changes are finished before submitting.
• Do as much of your design discussion in the open, preferably on the openstack-dev mailing list. If you have discussions on the phone or IRC, try and post a summary of those discussions to the
  mailing list.
• Holding a design summit session to discuss your changes in advance is a great idea, but don't assume that everybody who may have an opinion on your changes is present. Also, bear in mind that someone's quick opinion offered at a design summit session may be very different from their considered opinion after reviewing the code in detail.
• Finally, try and participate in the project beyond just making the changes you need. Review other peoples' changes in gerrit and offer your opinions, participate in design discussions on the mailing lists, fix bugs you come across, triage bug reports, etc. etc. All of this will allow other developers to get to know you, trust your judgement and review your changes more quickly. You will also learn more by interacting with other developers.

The OpenStack Foundation Board election has begun with 39 excellent candidates for only 8 seats!

Each candidate was asked to answer a number of questions to give an insight into why they are running for the Board. My answers are below.

If you'd like to know some more about my involvement in OpenStack, Rackspace recently posted a nice interview with me as part of their "How I Contribute To OpenStack" series.

What is your relationship to OpenStack, and why is its success important to you and/or your company? What would you say is your biggest contribution to OpenStack's success to date?

I've been involved with OpenStack for just over a year now. I started out packaging OpenStack for Fedora, but have concentrated mostly on contributing to the core projects in various ways since then.

I'm a member of the nova-core team and spend quite a bit of time reviewing proposed changes in gerrit. I'm also the openstack-common PTL and have been working to kickstart this effort to create a shared library for all OpenStack projects. My role as PTL recently means that I'm now a PPB/TC member, but I haven't contributed much there yet. Finally, I co-ordinate the efforts of the stable-maint and release teams to maintain a stable branch for OpenStack's core projects and publish regular bugfix releases.

It's thanks to Red Hat that I have time to make these contributions to the project and I am the technical lead of Red Hat's OpenStack team.

Red Hat's mission statement is all about being a catalyst in communities and, while credit must go to others for initially catalysing the OpenStack community, we recognize the massive strength of OpenStack's diverse community. This strength is the foundation that will ensure that OpenStack continues to grow, continues to improve and will be around for a long time to win. Red Hat is doing everything it can to help make that happen.

Describe your experience with other non profits or serving as a board member. How does your experience prepare you for the role of a board member?

I've been heavily involved in various open-source projects for over a decade now. Observing and pondering the role of non-profit organizations in open-source projects has prepared me well to participate in the OpenStack Foundation and its efforts to determine its own particular role.

Indeed, I participated significantly in the early discussions leading up to the formation of the Foundation and even proposed a strawman Foundation structure based on my experiences with other similar organizations.

What do you see as the Board's role in OpenStack's success?

More importantly, I think, is the role the Foundation will play in OpenStack's success. I'm a big fan of the Foundation's simple mission statement - to "protect, empower and promote" OpenStack. It perfectly encapsulates the role of the Foundation.

The "protecting" and "promoting" elements of the mission are hugely important, but what I find myself wondering most about is how the Foundation can "empower" the project. The Foundation can certainly use some of its budget to fill gaps in the resources which are available to the project. But, to me, "empowering" the project is mostly about re-inforcing the understanding that the project's future and direction lies in the hand of its meritocractic community of contributors (in the broadest possible sense) and not the Foundation itself.

I think that if the Board delivers on the promise of a Foundation which "protects, empowers and promotes", we will find ourselves in the enviable situation of a project with a large and diverse community of contributors supported by a well-financed organization acting at all times in the interests of that community.

What do you think the top priority of the Board should be during the OpenStack Foundation's first year?

I think it's the transitioning of responsibilities from Rackspace to the Foundation will take much of the focus of the Foundation and the Board in the coming year. The Board will need to appoint an Executive Director and, in turn, oversee the Executive Director's work to transition the likes of community management, release management and event co-ordination to employees of the Foundation.

A huge part of OpenStack's success to date is that functions such as these have been executed extremely well under Rackspace's management. The transition to a Foundation is a significant challenge in its own right and we cannot afford any missteps here. As part of this transition, I look forward to more open discussion leading up to decisions made by the Foundation.

I also expect the Board to quickly establish the User Committee and Legal Affairs Committee. The User Committee will have a hugely important role to help advocate specific needs of operators and users. The Legal Affairs Committee will be needed to help us make progress on reforming our trademark and contributor agreements.

Finally, the Board will have its work cut out finding its feet as the official voice of OpenStack. The Board will be expected to speak on behalf of us all and, as such, will need to work hard to build and reflect consensus within the project.

So, you want to play with some sqlalchemy queries against the Nova DB in an interactive python console?

$> sudo nova-manage shell python
...
>>> from nova.db.sqlalchemy import api
>>> from nova.db.sqlalchemy import models
>>> from nova import context
>>> ctxt = context.get_admin_context()
>>> vars(api.model_query(ctxt, models.Service).all()[0])
{'binary': u'nova-compute', ..., 'topic': u'compute', 'host': u'f16', 'disabled': False, 'deleted_at': None, 'id': 1L}

In OpenStack, we have a particular problem where much of the early development on the project was done using bzr and launchpad. All this history is in git, but it can be difficult to find the bzr merge proposal in launchpad which caused a given commit to be merged.

Here's an example of how I did it yesterday.

We're interested in commit 8aea573:

commit 8aea573bd2e44e152fb4ef1627640bab1818dede
Author: Trey Morris ...
Date:   Tue Dec 28 23:55:58 2010 -0600

    initial lock functionality commit

To trace back to the merge commit which merged this into master, I did:

$> git log --graph --topo-order --ancestry-path --merges 8aea573bd2e44e152fb4ef1627640bab1818dede..HEAD
* commit ae5dbe2b5d4871d3e26e859c03feab705c9c59ea
  Merge: 9eca4d5 76e3923
  Author: Trey Morris ...
  Date:   Fri Jan 7 00:49:30 2011 +0000

      This branch implements lock functionality. The lock is stored in the compute worker database. Decorators have been added to the opens

* commit f9c33f4ba09e02f8668bdd655b7acba15984838c
  Merge: ba245da 9eca4d5
  Author: Trey Morris ...
  Date:   Thu Jan 6 16:35:48 2011 -0600

      merged trunk

* commit f09d1ce4d38f3a8ef72566e95cde38f1dc1b8bed
  Merge: 9b9b5fe 9a84a2b
  Author: Trey Morris ...
  Date:   Wed Dec 29 15:13:24 2010 -0600

      fixed merge conflict with trunk

Double check that by looking at exactly what was merged in:

$> git diff 9eca4d5..ae5dbe2
diff --git a/nova/api/openstack/servers.py b/nova/api/openstack/servers.py
index ce64ac7..f8d5e76 100644
--- a/nova/api/openstack/servers.py
+++ b/nova/api/openstack/servers.py
@@ -170,6 +170,50 @@ class Controller(wsgi.Controller):
             return faults.Fault(exc.HTTPUnprocessableEntity())
         return exc.HTTPAccepted()

+    def lock(self, req, id):
...

That's the one!

Now how to find the merge proposal? Simply googling for "This branch implements lock functionality" quickly lead me to the correct merge prop, but better ideas welcome :)

We're holding a test day for Fedora 16 OpenStack today on #fedora-test-day.