+1 Cheers, Alicja
-----Original Message----- From: Hui Kang [mailto:hkang.sun...@gmail.com] Sent: Sunday, May 1, 2016 12:40 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote +1 - Hui On Sat, Apr 30, 2016 at 10:50 AM, Steven Dake (stdake) <std...@cisco.com> wrote: > 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 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: > > Prechecks > mariadb_recvoery > Deploy > Post-deploy > Pull > Upgrade > Reconfgiure > 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 > __________________________________________________________________________ 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 __________________________________________________________________________ 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