Topic Leader(s)
Topic Overview
Brainstorming session on release process goals and objectives. The intent is to get consensus in the community on the high level objectives for a release process, including approval by the TSC, then use those objectives to guide development of the Anuket release process.
Slides & Recording
Minutes
Slides are just a framework to spark discussions. The follow up to this session will be taken into the Anuket TSC. Anuket has a challenge because the artifacts are not only code. They are documents, implementations, etc. Have to explain the concept of a feature from its lifecycle that folds in requirements to conformance platforms end to end. Something that is integrated is important to make it useful to the community. Anuket happened because the components need to be integrated, however it requires changes on how the community thinks about the artifacts and how they can be consumed by the operators and vendors alike. There are artifacts in RM and RA that do not always translate into components that go into RI and RC artifacts. Sometimes the components are forward thinking, can drive use cases and gaps in the technology, that spawns work with peer, downstream and upstream communities – e.g. CNCF Working Group, Barometer project, are influenced by the Anuket use cases and models.
Pierre Lynchhow does the release cycle handle the fact that the downstream artifacts are dependent on the upstream work – RI and RC is dependent on the RA and RM documents. The release cycles need to be staggered to accommodate this. Pierre: RC must be verified vs other CNTT compliant (regarding their testing scope) deployment, else it's chicken & egg (we know that very well in OPNFV) See Functest Gates vsperf gates (under construction?) That’s how we work it at ETSI NFV TST. We have (an equivalent to) RA, then once that is ready (OpenAPIs), then we (TST) can develop the tests (RC equivalent). ETSI doesn’t really have RI :)
Once RA v 3.3.1 (for example) is ready, then we develop TST (RC) v 3.3.1, released with the same number, but a few months later.
Cedric Ollivier RI is verified by RC, Tom Kivlin as Cedric says, it is the other way round - RI relies on RC. RI would be your develop gates (possibly only mocking in case of ETSI NFV TST). For my understanding the big tent is not that successful tempest is rolling. K8s is very challenging because they use a rolling release schedule, while OpenStack follows a 6 month cycle.
Pankaj Goyalquestion: Does RI "rely" on RC other than for "conformance" (verify that it conforms to the RA)?
David McBrideis proposing a loosely coupled process to support the staggered output.
Pankaj Goyalnotes that the RM and RA artifacts are still valuable to the industry, even if they are not translated into software right away. FYI: While RA's typically follow RM, there can be exceptions. RM is just starting to define Observability, LCM, etc. but RA1 has some needed elements already.
Could potentially skip some releases for the workstreams that are moving at different paces. Heather Kirkseynotes that the stations along the way are the touch points between the workstreams, even if they are moving at different speeds. Scot Steelesays that we should still keep a cadence (6 month), even if the outputs are different and the amount of work done during a given release. Rihab Banday We have run into situations in the past where RI2 has been based on older version of k8s, i.e conforming to older versions of RA2 & RC2. It could be difficult for RI software to keep up with new releases of RA/RC artifacts.
Ildiko Vancsa Release management guide in OpenStack: https://docs.openstack.org/project-team-guide/release-management.html. Big tent doesn’t have much to do with the release models. The challenges with big tent was that we’ve been having a lot of projects and not everything was clearly fitting into the scope of OpenStack. Agree. It's more review and core developer issues. Well, that’s the project’s business on how they do onboarding and maintaining leadership. So I let the team members to judge the situation. :) With that said, there’s always room for improvement everywhere! Cedric Ollivier: Neutron could have simply promoted core developers rather than allow decreasing the review quality ;) However, OpenStack has had 10 years to work through all the issues. Gergely Csatari Just a bit of clarification to what we just discussed with Beth. OpenStack has a binary project status, the project is either an official OpenStack project or not (and it is decided by the OpenStack TC), however in OIF they have different states, like Confirmed and Pilot, but here it is not clear for me who decides on the state of the projects (my guess is the OIF board). And as @Gergely said for OpenStack it is the TC (Technical Committee) who can accept a new project team to become part of OpenStack.
Jim Baker : One perspective I’d like to introduce is the role of the Anuket members in the two-phase release process. I think it essential that the spec writers are ACTIVELY involved in the acceptance/approval of the test release. The model of “write a spec, throw it over the wall” does not leverage the talent on the Anuket team. Can we figure out a process that keeps BOTH spec and test writers engaged in each others work product?
Pankaj Goyal : Bullet two needs changes RI doesn't follow RC. We can create an RI based on RA but wouldn't know how well it conforms to the specs -- that is what RC achieves.
Cedric OllivierRC is a test case list + a playbook and somehow a traceability (which is also the test entries). It lists containers and test case names. All the software is included in the containers. RC selects a common test execution framework which helps storing the results.
Al Morton I was writing: , RC is a test case list, the SW implementation of the test cases, and a framework to run the tests, collect results, store the results for later access (public). Pankaj Goyal 1 RC but multiple RI's are possible
Scott Steinbrueckis proposing a release cycle that maps to twice a year, by creating a release package. Each project (workstream) aligns with the package as appropriate for their pace. Discussion on how to fold all the project into the overall cycle properly.