[openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote
alicja.kwasniewska at intel.com
Sun May 1 15:34:32 UTC 2016
From: Hui Kang [mailto:hkang.sunysb at gmail.com]
Sent: Sunday, May 1, 2016 12:40 AM
To: OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote
On Sat, Apr 30, 2016 at 10:50 AM, Steven Dake (stdake) <stdake at 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.
> 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 .
> 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  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:
> 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.
> ____ OpenStack Development Mailing List (not for usage questions)
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev