Open Stack

A separate repo will land us in the same spot as we had with kolla-mesos
originally.  We had all kinds of variance in the implementation.

I’m in favor of a single repo.

+1 for the single repo.

Regards,
Vikram Hosakote
IRC: vhosakot

From: Vikram Hosakote <vhosakot at cisco.com<mailto:vhosakot at cisco.com>>
Date: Sunday, May 1, 2016 at 11:36 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

Please add me too to the list!

Regards,
Vikram Hosakote
IRC: vhosakot

From: Michał Jastrzębski <inc007 at gmail.com<mailto:inc007 at gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Saturday, April 30, 2016 at 9:58 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote

Add me too please Steven.

On 30 April 2016 at 09:50, Steven Dake (stdake) <stdake at cisco.com<mailto: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<mailto:OpenStack-dev-request at 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-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160502/be1ffc51/attachment.html>