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