Open Stack

On 4 June 2015 at 16:07, Kyle Mestery <mestery at mestery.com> wrote:
> Each project is run in it's own way.

+1
We need to keep that.

> We share some things but we all operate
> in a different way at some level. For example, in Neutron, we've moved away
> from waterfall design specs to an RFE process [1].

I don't like calling specs waterfall.
They are if they get used like we did in Nova during Juno.
But lets not go there.

> My point is that, as John
> says, this is all a meritocracy, and it will be hard to push from the top
> down uniformity in a lot of areas. Geoff, not sure that answers your
> questions or not though, but hope it provides some perspective.

I think this bit makes the idea of tracking a cross project thing even
more important. It makes it harder too.

Also, it makes having a single group all the operator and user groups
can ask for advice on how to engage with different projects, really
useful.

Thanks,
John

>
> [1]
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
>
> On Thu, Jun 4, 2015 at 9:44 AM, Geoff Arnold <geoff at geoffarnold.com> wrote:
>>
>> 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
>>
>