[openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

Michał Jastrzębski inc007 at gmail.com
Sat Apr 30 15:00:02 UTC 2016


Also +1 :)

On 30 April 2016 at 09:58, Michał Jastrzębski <inc007 at gmail.com> wrote:
> Add me too please Steven.
>
> On 30 April 2016 at 09:50, 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[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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>



More information about the OpenStack-dev mailing list