Open Stack

Man thanks, John. This is really useful.

As you say, this describes what’s happening in Nova. Is there any pressure, process or impetus to adopt these ideas in the other projects? Is Nova “sui generis” because of scale, scope, or history? (I’m looping in Kyle in case he wants to provide a Neutron perspective.) I ask, because it is likely to significantly affect the way the Product WG has to operate if we have to interface with a wide range of project-specific governance models.

Thanks again,

Geoff

> On Jun 4, 2015, at 3:09 AM, John Garbutt <john at johngarbutt.com> wrote:
> 
> Hi,
> 
> It was great to meet with a lot of you in that room at the summit.
> 
> I just wanted to write down what I remember coming out of those
> sessions. This email is very Nova focused, mostly because thats what I
> am thinking about, but also because I think its a reasonable example
> to start with, and I am keen to work with you all.
> 
> 
> A)
> Some interesting things around how to influence the developer community
> 
> The development community is a meritocracy, this applies to non-devs
> helping them, such as product managers.
> 
> The PTLs have almost zero control on what people work on, although
> they do get to block some things if there is a valid reason
> 
> Its accepted that Product Managers are "hidden influencers" of what
> the developers actually work on. Almost all our developers are
> corporate sponsored professional developers, who are being allowed or
> asked by their company to contribute to OpenStack.
> 
> We frequently have developers talking about who their different use
> cases are quite similar and collaborating to produce a single feature
> that supports both sets of use cases. It would be good if some of
> these frictions were discussed by product managers already. Currently
> the developers proxy what their respective production managers want.
> This seems crazy.
> 
> There are lots of operator groups, user groups, and vendor groups. It
> would be great to collect that feedback, and work out what projects
> they need to talk to, and connect the special interest groups with the
> appropriate projects in a productive way. As a carrot, you might find
> some interesting customers as part of that discussion.
> 
> We need the same for the API users, not just the deployers. But that
> user group doesn't quite exist yet. The API-WG are doing some of that,
> although mostly by proxy. If that group of users are not happy,
> private cloud deployments will not get properly adopted, but that just
> doesn't seem to be happening right now.
> 
> Things like technical debt don't get all the attention they need,
> partly as people are pushing specific features to get specific deals.
> Someones people don't realise the ground work that is required to
> support some of these features. Because you don't directly own the
> code, its easy to assume its everyone else job, but thats just not
> true, there is no magic army of people to fix those things.
> 
> I think there were other things too, but I forget, and this email is
> too long already.
> 
> 
> B)
> Some interesting specifics about OpenStack Dev Process
> 
> 1) Specs are great at tracking features in a particular project
> 
> You can see the nova template here, for more details on what we do.
> http://specs.openstack.org/openstack/nova-specs/specs/liberty/template.html
> 
> 2) Backlog specs help agree a problem statement with developers
> 
> We are starting to use backlog specs to get agreement with the
> developer community around a given problem statement. In general, this
> is a partial spec.
> 
> It was hoped we can use this to get feedback from the large operators
> group, or similar to capture a problem, its use case and requirements,
> so we can get developers to take a look at that, if its interesting to
> them.
> 
> We have not merged any nova ones yet, but here is the placeholder:
> http://specs.openstack.org/openstack/nova-specs/specs/backlog/index.html
> 
> 3) Epics are useful, but not formally used right now.
> 
> Epic = tracking specs that span multiple specs and multiple releases
> 
> Nova has started a very informal method around this:
> http://docs.openstack.org/developer/nova/devref/cells.html
> http://docs.openstack.org/developer/nova/devref/upgrade.html
> http://docs.openstack.org/developer/nova/devref/policy_enforcement.html#future-of-policy-enforcement
> 
> We are in the process of sorting out devref, and I am likely to move
> this into the nova-specs repo as something called an "Epics". But
> thats a work in progress.
> 
> I am likely to leave things that talk about the "architectural
> evolution" of Nova in devref. Thats kind of something thats at a
> higher level of abstraction to the Epics. Hopefully once we have some
> examples that distinction will make more sense! (if not we can get rid
> of that distinction).
> 
> We don't tie back the Specs or Epics to your themes, like
> Manageability, and Scalability, but I suspect that would be really
> useful. I would except the developer writing the spec to do that
> classification, not another team. Mostly because it seems its not very
> obvious from reading the specs (I assume thats how the themes were
> perviously mapped to projects and releases?)
> 
> 4) We are OK at tracking/agreeing things that affect all projects
> 
> Here are some things that affect all projects, and seem to work:
> http://specs.openstack.org/openstack/openstack-specs/specs/log-guidelines.html
> http://specs.openstack.org/openstack/api-wg/guidelines/http.html
> 
> The TC owns the first. A horizontal team, the API-WG own the other.
> 
> 5) We don't have anything for Epics that span multiple projects, but we need it
> 
> Things tend to get driven only in one project, causing friction when
> late in the release a request for urgent changes in another project
> gets ignored. Help to track the cross project co-ordination would be
> very welcome.
> 
> Examples:
> Cinder encryption, requires bits in Cinder and Nova
> Keystone working on centralised policy
> 
> This might be something that the Product Working Group could own. I
> was thinking we could do something like this:
> * email to the ML to each affect project to discuss the idea
> * add backlog specs into relevant projects
> * once those are approved, merge the cross project epic description
> * then track the progress in each of the projects
> 
> 
> But anyways, thats quite a big brain dump of things we spoke about.
> Is that how others were remembering the discussion?
> 
> Thanks,
> John
> 
> _______________________________________________
> Product-wg mailing list
> Product-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg