Open Stack

On Sun, May 1, 2016 at 12:54 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[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 <http://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
>

I did this for you ages ago:
https://etherpad.openstack.org/p/kolla-set_configs

My opinion on this is that kolla images should provide mechanisms
to make configuration easy and the deployment tools should use
these in which ever way makes sense to them.


> 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:
>
>    1. Prechecks
>    2. mariadb_recvoery
>    3. Deploy
>    4. Post-deploy
>    5. Pull
>    6. Upgrade
>    7. Reconfgiure
>    8. 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.
>

A common cli has been tossed around for a while, I'd suggest using
the cliff library so that the deployment tool of choice installs it's
commands under "kolla", but can also do specific actions that are
particular to it (be as common as possible, but allow divergence as
needed). - this does seem to be adding multiple decisions into one
which is probably not a good thing...


>
> 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 to giving kubernetes a go.

-Angus


>
> [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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160502/0ccbd289/attachment.html>