Open Stack

On Sat, Apr 30, 2016 at 8:20 PM, 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
>



I am currently +1 on the creating different kolla-kubernetes/kolla-k8s
repo and reevaluating the merge/split thing once we have a stable
kubernetes deployment with the minimum deployment features added.
Perhaps this list can be maintained somewhere in documentation and
updated as we move along.


I think from the lessons we have learnt during kolla-mesos regarding
the participation and ABI, we need to ensure that we do not get into
the similar situation with kolla-kubernetes and maintain consistency.