Open Stack

Just to clarify my vote.

+1 for single repository

2016-05-02 14:11 GMT-03:00 Jeff Peeler <jpeeler at redhat.com>:

> Also +1 for working on kolla-kubernetes. (Please read this thread if
> you haven't yet):
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-May/093575.html
>
> On Mon, May 2, 2016 at 10:56 AM, Ryan Hallisey <rhallise at redhat.com>
> wrote:
> > +1 to start kolla-kubernetes work.
> >
> > ----- Original Message -----
> > From: "Swapnil Kulkarni" <me at coolsvap.net>
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> > Sent: Monday, May 2, 2016 12:59:40 AM
> > Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]
> kolla-kubernetes repository management proposal up for vote
> >
> > On Mon, May 2, 2016 at 10:08 AM, Vikram Hosakote (vhosakot)
> > <vhosakot at cisco.com> wrote:
> >> 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.
> >>
> >
> > I agree with you Vikram, but we should consider the bootstrapping
> > requirements for new deployment technologies and learn from our
> > failures with kolla-mesos.
> >
> > At the same time, it will help us evaluate the deployment technologies
> > going ahead without distrupting the kolla repo which we can treat as a
> > repo with stable images & associated deployment tools.
> >
> >> Regards,
> >> Vikram Hosakote
> >> IRC: vhosakot
> >>
> >> From: Vikram Hosakote <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>
> >> 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>
> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> >> <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>
> >> 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>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160502/b23c5f01/attachment.html>