Fellow core reviewers, We had a fantastic turnout at our fishbowl kubernetes as an underlay for Kolla session. The etherpad documents the folks interested and discussion at summit[1].
This proposal is mostly based upon a combination of several discussions at open design meetings coupled with the kubernetes underlay discussion. The proposal (and what we are voting on) is as follows: Folks in the following list will be added to a kolla-k8s-core group. This kolla-k8s-core group will be responsible for code reviews and code submissions to the kolla repository for the /kubernetes top level directory. Individuals in kolla-k8s-core that consistently approve (+2) or disapprove with a (-2) votes to TLD directories other then kubernetes will be handled on a case by case basis with several "training warnings" followed by removal of the kolla-k8s-core group. The kolla-k8s-core group will be added as a subgroup of the kolla-core reviewer team, which means they in effect have all of the ACL access as the existing kolla repository. I think it is better in this case to trust these individuals to the right thing and only approve changes for the kubernetes directory until proposed for the kolla-core reviewer group where they can gate changes to any part of the repository. * Britt Houser * mark casey * Steven Dake (delta-alpha-kilo-echo) * Michael Schmidt * Marian Schwarz * Andrew Battye * Kevin Fox (kfox1111) * Sidharth Surana (ssurana) * Michal Rostecki (mrostecki) * Swapnil Kulkarni (coolsvap) * MD NADEEM (mail2nadeem92) * Vikram Hosakote (vhosakot) * Jeff Peeler (jpeeler) * Martin Andre (mandre) * Ian Main (Slower) * Hui Kang (huikang) * Serguei Bezverkhi (sbezverk) * Alex Polvi (polvi) * Rob Mason * Alicja Kwasniewska * sean mooney (sean-k-mooney) * Keith Byrne (kbyrne) * Zdenek Janda (xdeu) * Brandon Jozsa (v1k0d3n) * Rajath Agasthya (rajathagasthya) If you already are in the kolla-core review team, you won't be added to the kolla-k8s-core team as you will already have the necessary ACLs to do the job. If you feel you would like to join this initial bootstrapping process, please add your name to the etherpad in [1]. After 8 weeks (July 15h), folks that have not been actively reviewing or committing code will be removed from the kolla-k8s-core group. We will use the governance repository metrics for team size [2] which is either 30 reviews over 6 months (in this case, 10 reviews), or 6 commits over 6 months (in this case 2 commits) to the repository. Folks that don't meet the qualifications are still welcome to commit to the repository and contribute code or documentation but will lose approval rights on patches. The kubernetes codebase will be maintained in the https://github.com/openstack/kolla<http://github.com/openstack/kolla> repository under the kubernees top level directory. Contributors that become active in the kolla repository itself will be proposed over time to the kolla-core group. Only core-kolla members will be permitted to participate in policy decisions and voting thereof, so there is some minimal extra responsibility involved in joining the kolla-core ACL team for those folks wanting to move into the kolla core team over time. The goal will be to over time entirely remove the kolla-k8s-core team and make one core reviewer team in the kolla-core ACL. Members in the kolla-k8s-core group will have the ability to +2 or –2 any change to the main kolla repository via ACLs, however, I propose we trust these folks to only +2/-2 changes related to the kubernetes directory in the kolla repository and remove folks that consistently break this agreement. Initial errors as folks learn the system will be tolerated and commits reverted as makes sense. I feel we made a couple errors with the creation of Kolla-mesos that I feel needs correction. Our first error the kolla-mesos-core team made a lack of a diversely affiliated team membership developing the code base. The above list has significant diversity. The second error is that the repository was split in the first place. This resulted in a separate ABI to the containers being implemented which was a sore spot for me personally. We did our best to build both sides of the bridge here, but this time I'd like the bridge between these two interests and set of individuals to be fully built before beginning. As such, I'd ask the existing kolla-core team to trust my judgement on this point and roll with it. We can always change the structure later if this model doesn't work out as I expect it will, but if we started with split repos and a changed structure to begin with, we can't go back to a non-split repo as the action is irreversible according to dims. I know this proposal may seem uncomfortable for our existing kolla-core team. I can assure you based upon twenty years of open source participation this will result in a better outcome. We had talked about splitting the repositories, and our plan around that is to punt until such action is absolutely necessary. Keeping things in one repository can always be split later, but a premature split can never be undone without losing git commit history. We will mark the kubernetes orchestration in Kolla as experimental until existing feature parity is achieved in the kolla CLI tool. After the initial implementation is ready, we will mark it as ready for evaluation. At the conclusion of Newton, assuming the implementation works well, we will mark the implementation as "production ready", just as our current Ansible orchestrated implementation is recorded. ** All CLI features of the kolla-ansible shell script to be implemented for "ready-for-evaluation" stage. ** This includes the following CLI operations where they make sense: 1. Prechecks 2. mariadb_recvoery 3. Deploy 4. Post-deploy 5. Pull 6. Upgrade 7. Reconfgiure 8. Certificates As part of this change, I will be submitting a change to rename kolla-ansible to kolla with appropriate documentation changes. This one shell script will in the future will read from globals.yml a yaml variable which is "orchestratoin_engine" which may be either ansible or kubernetes. In this way, the terminology I strongly dislike "first class citizen" will be removed from our lexicon in the Kolla repository. Instead of first class/second class citizen, we will have all orchestration systems as "first class citizens" with varying levels of maturity. Please vote +1 if in favor, -1 if not in favor. 7 votes will trigger early closing of the vote and the creation of the kubernetes directory with a README.rst. The voting will remain open for 1 week until May 6th unless a majority is reached prior to the voting window closing. I would appreciate a quick turnaround on the voting so the work can begin rapidly. If you have arguments with this approach I'd like to hear them. If they involve the concept of trust, I'd ask you to keep in mind we are a community working towards a common goal with common objectives, and to trust until given reason otherwise. [1] https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kubernetes-underlay [2] https://github.com/openstack/governance/blob/master/tools/teamstats.py#L32
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
