+1 for kolla-kubernetes. On Mon, May 2, 2016 at 1:07 PM, Mauricio Lima <mauricioli...@gmail.com> wrote: > Just to clarify my vote. > > +1 for single repository > > 2016-05-02 14:11 GMT-03:00 Jeff Peeler <jpee...@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 <rhall...@redhat.com> >> wrote: >> > +1 to start kolla-kubernetes work. >> > >> > ----- Original Message ----- >> > From: "Swapnil Kulkarni" <m...@coolsvap.net> >> > To: "OpenStack Development Mailing List (not for usage questions)" >> > <openstack-dev@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) >> > <vhosa...@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 <vhosa...@cisco.com> >> >> Date: Sunday, May 1, 2016 at 11:36 PM >> >> >> >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> <openstack-dev@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 <inc...@gmail.com> >> >> Reply-To: "OpenStack Development Mailing List (not for usage >> >> questions)" >> >> <openstack-dev@lists.openstack.org> >> >> Date: Saturday, April 30, 2016 at 9:58 AM >> >> To: "OpenStack Development Mailing List (not for usage questions)" >> >> <openstack-dev@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) <std...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
