On Sep 19, 2014, at 10:37 PM, Monty Taylor <mord...@inaugust.com> wrote:
> On 09/19/2014 03:29 AM, Thierry Carrez 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 >> 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. > > Agree. I'm willing to bet it'll be better not worse to have a large > constituency - but it's also problem that it's a giant disaster. I'm > still on board with going for it. > >> ## 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 think we can do what you're saying and generalize a little bit. What > if we declared programs, as needed, when we think there is a need to > "pick a winner". (I think we can all agree that early winner picking is > an unintended but very real side effect of the current system) > > And when I say "need to" - I mean it in the same sense as "Production > Ready" The themes you listed are excellent ones - it makes no sense to > have two Infras, two QAs or two Docs teams. On the other hand, maybe > someone else wants to take a stab at the general problem space that > congress and manilla and heat are all playing in. Do we need to bless > that yet? No. Are those people all honestly trying to solve problems for > OpenStack? Absolutely! > > It's a judgement call for sure - but I like the idea of keeping the > programs for some things and not for others. > >> ## 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. > > I'm in. > >> 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. > > For what it's worth, Infra even tries to do freezes around release (this > concept is known as "don't land any of Monty's patches for a week around > major freezes) > > I think it's worth having a more expansive discussion around the release > cycle overall, but this is enough massive change for me for now. > >> ## 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. > > ++ > > My main point was that we should optimize summit time for things that we > can only do then - gnarly cross-project issues being one of the biggest > examples. The other was that it would be great to add a bit more topic > malleability to be able to respond to things we hear in the operator > feedback sessions - especially in the heavily-contested cross-project > time. (saying "just use pods" for those emergent issues isn't a workable > thing because we likely need people who are double booked) > > But in general, yeah. > >> ## 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. > > I don't think ring 0 -> bylaws "Integrated" is the right mapping. I just > spent a board meeting yelling about how I'm pretty sure that any logical > system that somehow winds up leaving swift out has a flaw, and I think > that applies here too. > > I don't have a great answer - but you're right - we need a name mapping. > > OTOH, the board was considering a bylaws change for defcore - perhaps we > should take a quick pass at proposing a bylaws change to make the > language a little bit more general and get us to the point of the > _intent_ of that - which is that defcore can pick from at most a list of > projects suggested by the TC. > > OR - we could go massively the other way WRT the bylaws, and we could > consider _every_ crazy big-tent thing under our care "in the integrated > release" - and count on the fact that _probably_ defcore is not even > going to think about including something in their definition until we've > blessed something as production ready … The matrix the defcore committee used to pick capabilities included a couple of inputs related to quality and existing deployments. If we start giving projects a quality designation (whether it’s binary or on some sort of scale), that designation could feed into the existing process. > >> >> That was a long answer, but then so was your original post :P > > We should do this more often ... ;) > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
