Open Stack

On Sep 19, 2014, at 6:29 AM, Thierry Carrez <thierry at openstack.org> wrote:

> Monty Taylor wrote:
>> I've recently been thinking a lot about Sean's Layers stuff. So I wrote
>> a blog post which Jim Blair and Devananda were kind enough to help me edit.
>> 
>> http://inaugust.com/post/108
> 
> Hey Monty,
> 
> As you can imagine, I read that post with great attention. I generally
> like the concept of a tightly integrated, limited-by-design layer #1
> (I'd personally call it "Ring 0") and a large collection of "OpenStack"
> things gravitating around it. That would at least solve the attraction
> of the integrated release, suppress the need for incubation, foster

I’m not sure I see this change reducing the number of incubated projects unless we no longer incubate and graduate projects at all. Would everything just live on stackforge and have a quality designation instead of an “officialness” designation? Or would we have both? ATC status seems to imply we need some sort of officialness designation, as you mention below.

> competition/innovation within our community, and generally address the
> problem of community scaling. There are a few details on the
> consequences though, and in those as always the devil lurks.
> 
> ## The Technical Committee
> 
> The Technical Committee is defined in the OpenStack bylaws, and is the
> representation of the contributors to "the project". Teams work on code
> repositories, and at some point ask their work to be recognized as part
> of "OpenStack". In doing so, they place their work under the oversight
> of the Technical Committee. In return, team members get to participate
> in electing the technical committee members (they become "ATC"). It's a
> balanced system, where both parties need to agree: the TC can't force
> itself as overseer of a random project, and a random project can't just
> decide by itself it is "OpenStack".
> 
> I don't see your proposal breaking that balanced system, but it changes
> its dynamics a bit. The big tent would contain a lot more members. And
> while the TC would arguably bring a significant share of its attention
> to Ring 0, its voters constituency would mostly consist of developers
> who do not participate in Ring 0 development. I don't really see it as
> changing dramatically the membership of the TC, but it's a consequence
> worth mentioning.
> 
> ## Programs
> 
> Programs were created relatively recently as a way to describe which
> teams are "in OpenStack" vs. which ones aren't. They directly tie into
> the ATC system: if you contribute to code repositories under a blessed
> program, then you're an ATC, you vote in TC elections and the TC has
> some oversight over your code repositories. Previously, this was granted
> at a code repository level, but that failed to give flexibility for
> teams to organize their code in the most convenient manner for them. So
> we started to bless teams rather than specific code repositories.
> 
> Now, that didn't work out so well. Some programs were a 'theme', like
> Infrastructure, or Docs. For those, competing efforts do not really make
> sense: there can only be one, and competition should happen inside those
> efforts rather than outside. Some programs were a 'team', like
> Orchestration/Heat or Deployment/TripleO. And that's where the model
> started to break: some new orchestration things need space, but the
> current Heat team is not really interested in maintaining them. What's
> the point of being under the same program then ? And TripleO is not the
> only way to deploy OpenStack, but its mere existence (and name)
> prevented other flowers to bloom in our community.
> 
> You don't talk much about programs in your proposal. In particular, you
> only mention layer 1, "Cloud Native" applications, "User Interface"
> applications, and "Operator" applications. So I'm unsure of where, if
> anywhere, would "Infrastructure" or "Docs" repositories live.
> 
> Here is how I see it could work. We could keep 'theme' programs (think
> Infra, Release cycle management, Docs, QA) with their current structure
> (collection of code repositories under a single team/PTL). We would get
> rid of 'team' programs completely, and just have a registry of
> "OpenStack" code repositories (openstack*/*, big tent). Each of those
> could have a specific PTL, or explicitely inherit its PTL from another
> code repository. Under that PTL, they could have separate or same core
> review team, whatever maps reality and how they want to work (so we
> could say that openstack/python-novaclient inherits its PTL from
> openstack/nova and doesn't need a specific one). That would allow us to
> map anything that may come in. Oslo falls a bit in between, could be
> considered a 'theme' program or several repos sharing PTL.

I like the idea of chartered programs as a way to tackling our cross-project issues. We need fewer of programs, but for the ones we do need we still need to integrate them with the rest of our governance.

> 
> ## The release and the development cycle
> 
> You touch briefly on the consequences of your model for the "common
> release" and our development cycle. Obviously we would release the ring
> 0 projects in an integrated manner on a time-based schedule.
> 
> For the other projects, we have a choice:
> 
> - the "ring 0" model (development milestones, coordinated final release)
> - the "Swift" model (release as-needed, coordinated final release)
> - the "Oslo" model (release as-needed, try to have one final one before
> end of cycle)
> - the "Client libraries" model (release as-needed)
> 
> If possible, I would like to avoid the "Swift" model, which is the most
> costly from a release management standpoint. All projects following the
> ring 0 model are easy to keep track of, using common freezes etc. So
> it's easy to make sure they will be ready in time for the coordinated
> release. Each project following the Swift model would be a special case,
> and that adds up to a lot of load on the release management team.
> Keeping track of one project doing that is OK. 5 or 20, not so much. So
> I'd advise we only keep ring0, Oslo and client lib models as options.
> Release management would just care about ring 0, and provide tools and
> advice for all the others, but not being responsible for them.
> 
> What about the development cycle ? I think it's part of our "identity":
> being "OpenStack" is also about having the same notion of passing time,
> the same reference points. So I think it would probably be a good idea,
> even for projects that purely release "as-needed", to organize their
> development at least vaguely around the notion of a common cycle.

+1 — This is why we do it for Oslo.

> 
> ## The design summit
> 
> I'm not a big fan of your #11 suggestion. I guess I just don't want to
> defer all in-project alignment and work to mid-cycle meetups, and force
> all contributors to travel all the time. I think the right time to reach
> alignment on the goals is at the start of a development cycle, not in
> the middle of it. The middle of a cycle is a good time to get things
> done. So I would still like teams to be able to discuss their goals at
> the Design Summit, at the start of a cycle.
> 
> Now I realize this creates a pretty significant issue, since Design
> Summit space is one resource which can't really support the "infinite
> tent" model. My proposal to solve it would be to give ample space to
> cross-project issues, ring 0 projects, and 'theme' programs. Everyone
> else gets limited space, which may boil down to a pod. Then we work on
> options, so that whoever who wants to organize a large meetup in
> parallel with the summit may find space to do so in neighboring hotels.
> 
> The main value in that proposal is that it makes the "Design Summit"
> space needs more predictable. I've been visiting spaces for the 2016 and
> 2018 summits recently -- it's really difficult to make plans when you
> don't know how many projects you'll have to host. And it's really
> difficult to get good locations and times (and prices) if you don't book
> at least 2 years in advance.
> 
> ## The Foundation bylaws
> 
> There are a number of terms used in the bylaws, and we may need to map
> our new structure to it, make sure it doesn't require a bylaws change.
> I didn't spot any showstopper yet. The "integrated release" could be the
> ring 0 (that would mean that defcore would only get to pick between
> Nova/Neutron/Cinder/Keystone/Designate for the trademark programs). The
> "OpenStack project" could be the big tent. We keep the TC, the ATCs
> concepts the same.
> 
> 
> That was a long answer, but then so was your original post :P
> 
> -- 
> Thierry Carrez (ttx)
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev