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 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. ## 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. ## 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
