<div dir="ltr">J<span dir="ltr" id=":4rx" style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:12.8px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255)">ust to clarify my vote.<br><br></span>+1 for single repository<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-02 14:11 GMT-03:00 Jeff Peeler <span dir="ltr"><<a href="mailto:jpeeler@redhat.com" target="_blank">jpeeler@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also +1 for working on kolla-kubernetes. (Please read this thread if<br>
you haven't yet):<br>
<br>
<a href="http://lists.openstack.org/pipermail/openstack-dev/2016-May/093575.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2016-May/093575.html</a><br>
<br>
On Mon, May 2, 2016 at 10:56 AM, Ryan Hallisey <<a href="mailto:rhallise@redhat.com">rhallise@redhat.com</a>> wrote:<br>
> +1 to start kolla-kubernetes work.<br>
><br>
> ----- Original Message -----<br>
> From: "Swapnil Kulkarni" <<a href="mailto:me@coolsvap.net">me@coolsvap.net</a>><br>
> To: "OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Sent: Monday, May 2, 2016 12:59:40 AM<br>
> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra] kolla-kubernetes repository management proposal up for vote<br>
><br>
> On Mon, May 2, 2016 at 10:08 AM, Vikram Hosakote (vhosakot)<br>
> <<a href="mailto:vhosakot@cisco.com">vhosakot@cisco.com</a>> wrote:<br>
>> A separate repo will land us in the same spot as we had with kolla-mesos<br>
>> originally. We had all kinds of variance in the implementation.<br>
>><br>
>> I’m in favor of a single repo.<br>
>><br>
>> +1 for the single repo.<br>
>><br>
><br>
> I agree with you Vikram, but we should consider the bootstrapping<br>
> requirements for new deployment technologies and learn from our<br>
> failures with kolla-mesos.<br>
><br>
> At the same time, it will help us evaluate the deployment technologies<br>
> going ahead without distrupting the kolla repo which we can treat as a<br>
> repo with stable images & associated deployment tools.<br>
><br>
>> Regards,<br>
>> Vikram Hosakote<br>
>> IRC: vhosakot<br>
>><br>
>> From: Vikram Hosakote <<a href="mailto:vhosakot@cisco.com">vhosakot@cisco.com</a>><br>
>> Date: Sunday, May 1, 2016 at 11:36 PM<br>
>><br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]<br>
>> kolla-kubernetes repository management proposal up for vote<br>
>><br>
>> Please add me too to the list!<br>
>><br>
>> Regards,<br>
>> Vikram Hosakote<br>
>> IRC: vhosakot<br>
>><br>
>> From: Michał Jastrzębski <<a href="mailto:inc007@gmail.com">inc007@gmail.com</a>><br>
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Date: Saturday, April 30, 2016 at 9:58 AM<br>
>> To: "OpenStack Development Mailing List (not for usage questions)"<br>
>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
>> Subject: Re: [openstack-dev] [kolla][vote][kubernetes][infra]<br>
>> kolla-kubernetes repository management proposal up for vote<br>
>><br>
>> Add me too please Steven.<br>
>><br>
>> On 30 April 2016 at 09:50, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>> wrote:<br>
>><br>
>> Fellow core reviewers,<br>
>><br>
>> We had a fantastic turnout at our fishbowl kubernetes as an underlay for<br>
>> Kolla session. The etherpad documents the folks interested and discussion<br>
>> at summit[1].<br>
>><br>
>> This proposal is mostly based upon a combination of several discussions at<br>
>> open design meetings coupled with the kubernetes underlay discussion.<br>
>><br>
>> The proposal (and what we are voting on) is as follows:<br>
>><br>
>> Folks in the following list will be added to a kolla-k8s-core group.<br>
>><br>
>> This kolla-k8s-core group will be responsible for code reviews and code<br>
>> submissions to the kolla repository for the /kubernetes top level directory.<br>
>> Individuals in kolla-k8s-core that consistently approve (+2) or disapprove<br>
>> with a (-2) votes to TLD directories other then kubernetes will be handled<br>
>> on a case by case basis with several "training warnings" followed by removal<br>
>> of the kolla-k8s-core group. The kolla-k8s-core group will be added as a<br>
>> subgroup of the kolla-core reviewer team, which means they in effect have<br>
>> all of the ACL access as the existing kolla repository. I think it is<br>
>> better in this case to trust these individuals to the right thing and only<br>
>> approve changes for the kubernetes directory until proposed for the<br>
>> kolla-core reviewer group where they can gate changes to any part of the<br>
>> repository.<br>
>><br>
>> Britt Houser<br>
>><br>
>> mark casey<br>
>><br>
>> Steven Dake (delta-alpha-kilo-echo)<br>
>><br>
>> Michael Schmidt<br>
>><br>
>> Marian Schwarz<br>
>><br>
>> Andrew Battye<br>
>><br>
>> Kevin Fox (kfox1111)<br>
>><br>
>> Sidharth Surana (ssurana)<br>
>><br>
>> Michal Rostecki (mrostecki)<br>
>><br>
>> Swapnil Kulkarni (coolsvap)<br>
>><br>
>> MD NADEEM (mail2nadeem92)<br>
>><br>
>> Vikram Hosakote (vhosakot)<br>
>><br>
>> Jeff Peeler (jpeeler)<br>
>><br>
>> Martin Andre (mandre)<br>
>><br>
>> Ian Main (Slower)<br>
>><br>
>> Hui Kang (huikang)<br>
>><br>
>> Serguei Bezverkhi (sbezverk)<br>
>><br>
>> Alex Polvi (polvi)<br>
>><br>
>> Rob Mason<br>
>><br>
>> Alicja Kwasniewska<br>
>><br>
>> sean mooney (sean-k-mooney)<br>
>><br>
>> Keith Byrne (kbyrne)<br>
>><br>
>> Zdenek Janda (xdeu)<br>
>><br>
>> Brandon Jozsa (v1k0d3n)<br>
>><br>
>> Rajath Agasthya (rajathagasthya)<br>
>><br>
>><br>
>> If you already are in the kolla-core review team, you won't be added to the<br>
>> kolla-k8s-core team as you will already have the necessary ACLs to do the<br>
>> job. If you feel you would like to join this initial bootstrapping process,<br>
>> please add your name to the etherpad in [1].<br>
>><br>
>> After 8 weeks (July 15h), folks that have not been actively reviewing or<br>
>> committing code will be removed from the kolla-k8s-core group. We will use<br>
>> the governance repository metrics for team size [2] which is either 30<br>
>> reviews over 6 months (in this case, 10 reviews), or 6 commits over 6 months<br>
>> (in this case 2 commits) to the repository. Folks that don't meet the<br>
>> qualifications are still welcome to commit to the repository and contribute<br>
>> code or documentation but will lose approval rights on patches.<br>
>><br>
>> The kubernetes codebase will be maintained in the<br>
>> <a href="https://github.com/openstack/kolla" rel="noreferrer" target="_blank">https://github.com/openstack/kolla</a> repository under the kubernees top level<br>
>> directory. Contributors that become active in the kolla repository itself<br>
>> will be proposed over time to the kolla-core group. Only core-kolla members<br>
>> will be permitted to participate in policy decisions and voting thereof, so<br>
>> there is some minimal extra responsibility involved in joining the<br>
>> kolla-core ACL team for those folks wanting to move into the kolla core team<br>
>> over time. The goal will be to over time entirely remove the kolla-k8s-core<br>
>> team and make one core reviewer team in the kolla-core ACL.<br>
>><br>
>> Members in the kolla-k8s-core group will have the ability to +2 or –2 any<br>
>> change to the main kolla repository via ACLs, however, I propose we trust<br>
>> these folks to only +2/-2 changes related to the kubernetes directory in the<br>
>> kolla repository and remove folks that consistently break this agreement.<br>
>> Initial errors as folks learn the system will be tolerated and commits<br>
>> reverted as makes sense.<br>
>><br>
>> I feel we made a couple errors with the creation of Kolla-mesos that I feel<br>
>> needs correction. Our first error the kolla-mesos-core team made a lack of<br>
>> a diversely affiliated team membership developing the code base. The above<br>
>> list has significant diversity. The second error is that the repository was<br>
>> split in the first place. This resulted in a separate ABI to the containers<br>
>> being implemented which was a sore spot for me personally. We did our best<br>
>> to build both sides of the bridge here, but this time I'd like the bridge<br>
>> between these two interests and set of individuals to be fully built before<br>
>> beginning. As such, I'd ask the existing kolla-core team to trust my<br>
>> judgement on this point and roll with it. We can always change the<br>
>> structure later if this model doesn't work out as I expect it will, but if<br>
>> we started with split repos and a changed structure to begin with, we can't<br>
>> go back to a non-split repo as the action is irreversible according to dims.<br>
>><br>
>> I know this proposal may seem uncomfortable for our existing kolla-core<br>
>> team. I can assure you based upon twenty years of open source participation<br>
>> this will result in a better outcome. We had talked about splitting the<br>
>> repositories, and our plan around that is to punt until such action is<br>
>> absolutely necessary. Keeping things in one repository can always be split<br>
>> later, but a premature split can never be undone without losing git commit<br>
>> history.<br>
>><br>
>> We will mark the kubernetes orchestration in Kolla as experimental until<br>
>> existing feature parity is achieved in the kolla CLI tool. After the<br>
>> initial implementation is ready, we will mark it as ready for evaluation.<br>
>> At the conclusion of Newton, assuming the implementation works well, we will<br>
>> mark the implementation as "production ready", just as our current Ansible<br>
>> orchestrated implementation is recorded.<br>
>><br>
>> ** All CLI features of the kolla-ansible shell script to be implemented for<br>
>> "ready-for-evaluation" stage. **<br>
>><br>
>> This includes the following CLI operations where they make sense:<br>
>><br>
>> Prechecks<br>
>> mariadb_recvoery<br>
>> Deploy<br>
>> Post-deploy<br>
>> Pull<br>
>> Upgrade<br>
>> Reconfgiure<br>
>> Certificates<br>
>><br>
>> As part of this change, I will be submitting a change to rename<br>
>> kolla-ansible to kolla with appropriate documentation changes. This one<br>
>> shell script will in the future will read from globals.yml a yaml variable<br>
>> which is "orchestratoin_engine" which may be either ansible or kubernetes.<br>
>> In this way, the terminology I strongly dislike "first class citizen" will<br>
>> be removed from our lexicon in the Kolla repository. Instead of first<br>
>> class/second class citizen, we will have all orchestration systems as "first<br>
>> class citizens" with varying levels of maturity.<br>
>><br>
>> Please vote +1 if in favor, -1 if not in favor. 7 votes will trigger early<br>
>> closing of the vote and the creation of the kubernetes directory with a<br>
>> README.rst. The voting will remain open for 1 week until May 6th unless a<br>
>> majority is reached prior to the voting window closing. I would appreciate<br>
>> a quick turnaround on the voting so the work can begin rapidly. If you have<br>
>> arguments with this approach I'd like to hear them. If they involve the<br>
>> concept of trust, I'd ask you to keep in mind we are a community working<br>
>> towards a common goal with common objectives, and to trust until given<br>
>> reason otherwise.<br>
>><br>
>> [1]<br>
>> <a href="https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kubernetes-underlay" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/kolla-newton-summit-kolla-kubernetes-underlay</a><br>
>> [2]<br>
>> <a href="https://github.com/openstack/governance/blob/master/tools/teamstats.py#L32" rel="noreferrer" target="_blank">https://github.com/openstack/governance/blob/master/tools/teamstats.py#L32</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div>