Open Stack

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