Open Stack

+1 for kolla-kubernetes.

On Mon, May 2, 2016 at 1:07 PM, Mauricio Lima <mauriciolimab at gmail.com> wrote:
> 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
>
>
>
> __________________________________________________________________________
> 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
>