<p dir="ltr"><br>
On May 3, 2016 1:53 AM, "Davanum Srinivas" <<a href="mailto:davanum@gmail.com">davanum@gmail.com</a>> wrote:<br>
><br>
> Sorry for top-post...<br>
><br>
> There's a third option : Using Feature branch for Kubernetes with a<br>
> custom gerrit group<br>
><br>
> * Feature branch can be sync'ed from Master periodically<br>
> * Feature branch can have it's own separate gerrit group.<br>
> * We can opt to merge from feature branch to master if necessary.<br>
> * We can have minimum changes in the feature branch (only that is<br>
> needed for k8s work). Everything else should hit master first and then<br>
> sync'ed to the branch.<br>
> * We should have a deadline for the feature branch when we think<br>
> appropriate (Say Newton-2 Milestone?)<br>
> * We can define jobs that run only on feature branch<br>
> * I'll assume that folks get promoted as they earn karma from just the<br>
> feature group to the main group.<br>
> * At some point (Newton-2) we take a go/no-go on k8s feature for the<br>
> Newton release, if we say no-go, then the feature branch remains for<br>
> on-going work while the master branch can be made release-ready.<br>
><br>
> Worst case scenario, we nuke the feature branch as an experiment<br>
> Best case scenario, we can choose either to make the feature branch<br>
> into master OR figure out how to split the contents into another repo.<br>
> We don't have to decide right now.<br>
><br>
> Thanks,<br>
> Dims<br>
></p>
<p dir="ltr">like this option which keeps you kinda detached to the kolla repo and achieve the required bootstrapping, gating, reviewing code separately and analyze overlap.<br></p>
<p dir="ltr">> On Mon, May 2, 2016 at 3:38 PM, Steven Dake (stdake) <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>> wrote:<br>
> > Yup but that didn't happen with kolla-mesos and I didn't catch it until 2<br>
> > weeks after it was locked in stone.  At that point I asked for the ABI to<br>
> > be unified to which I got a "shrug" and no action.<br>
> ><br>
> > If it has been in one repo, everyone would have seen the multiple ABIs and<br>
> > rejected the patch in the first place.<br>
> ><br>
> > FWIW I am totally open to extending the ABI however is necessary to make<br>
> > Kolla containers be the reference that other projects use for their<br>
> > container deployment technology tooling.  In this case the ABI was<br>
> > extended without consultation and without repair after the problem was<br>
> > noticed.<br>
> ><br>
> > Regards<br>
> > -steve<br>
> ><br>
> > On 5/2/16, 12:04 PM, "Fox, Kevin M" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>> wrote:<br>
> ><br>
> >>+1 to one set of containers for all. If kolla-k8s needs tweaks to the<br>
> >>abi, the request should go to the kolla core team (involving everyone)<br>
> >>and discuss why they are needed/reasonable. This should be done<br>
> >>regardless of if there are 1or 2 repo's in the end.<br>
> >><br>
> >>Thanks,<br>
> >>Kevin<br>
> >>________________________________________<br>
> >>From: Steven Dake (stdake) [<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>]<br>
> >>Sent: Monday, May 02, 2016 11:14 AM<br>
> >>To: OpenStack Development Mailing List (not for usage questions)<br>
> >>Subject: Re: [openstack-dev] [kolla][kubernetes] One repo vs two<br>
> >><br>
> >>I personally would like to see one set of defaults files for the default<br>
> >>config and merging thereof. (the stuff in roles/*/defaults).<br>
> >><br>
> >>There would be overlap there.<br>
> >><br>
> >>A lot of the overlap involves things like reno, sphinx, documentation,<br>
> >>gating, etc.<br>
> >><br>
> >>During kolla-emsos, separate containers (IIRC) were made, separate start<br>
> >>extension scripts were made, and to my dismay a completely different ABI<br>
> >>was implemented.<br>
> >><br>
> >>We need one ABI to the containers and that should be laid out in the spec<br>
> >>if it isn't already.<br>
> >><br>
> >>Regards<br>
> >>-steve<br>
> >><br>
> >><br>
> >>On 5/2/16, 10:31 AM, "Ryan Hallisey" <<a href="mailto:rhallise@redhat.com">rhallise@redhat.com</a>> wrote:<br>
> >><br>
> >>>Most of the code is not an overlap. We will preserve the ABI while<br>
> >>>customizing the ansible config generation (if we do end up using it). We<br>
> >>>can use some of what's in kolla as a starting point.<br>
> >>><br>
> >>>I'd say the code overlap is a bootstrapping point for the project.<br>
> >>><br>
> >>>-Ryan<br>
> >>><br>
> >>>----- Original Message -----<br>
> >>>From: "Kevin M Fox" <<a href="mailto:Kevin.Fox@pnnl.gov">Kevin.Fox@pnnl.gov</a>><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>
> >>>Sent: Monday, May 2, 2016 12:56:22 PM<br>
> >>>Subject: Re: [openstack-dev] [kolla][kubernetes] One repo vs two<br>
> >>><br>
> >>>One thing we didn't talk about too much at the summit is the part of the<br>
> >>>spec that says we will reuse a bunch of ansible stuff to generate configs<br>
> >>>for the k8s case...<br>
> >>><br>
> >>>Do we believe that code would be minimal and not impact separate repo's<br>
> >>>much or is the majority of the work in the end going to be focused there?<br>
> >>>If most of the code ends up landing there, then its probably not worth<br>
> >>>splitting?<br>
> >>><br>
> >>>Thanks,<br>
> >>>Kevin<br>
> >>>________________________________________<br>
> >>>From: Steven Dake (stdake) [<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>]<br>
> >>>Sent: Monday, May 02, 2016 6:05 AM<br>
> >>>To: OpenStack Development Mailing List (not for usage questions)<br>
> >>>Subject: Re: [openstack-dev] [kolla][kubernetes] One repo vs two<br>
> >>><br>
> >>>On 5/1/16, 10:32 PM, "Swapnil Kulkarni" <<a href="mailto:me@coolsvap.net">me@coolsvap.net</a>> wrote:<br>
> >>><br>
> >>>>On Mon, May 2, 2016 at 9:54 AM, Britt Houser (bhouser)<br>
> >>>><<a href="mailto:bhouser@cisco.com">bhouser@cisco.com</a>> wrote:<br>
> >>>>> Although it seems I'm in the minority, I am in favor of unified repo.<br>
> >>>>><br>
> >>>>> From: "Steven Dake (stdake)" <<a href="mailto:stdake@cisco.com">stdake@cisco.com</a>><br>
> >>>>> Reply-To: "OpenStack Development Mailing List (not for usage<br>
> >>>>>questions)"<br>
> >>>>> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> >>>>> Date: Sunday, May 1, 2016 at 5:03 PM<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: [openstack-dev] [kolla][kubernetes] One repo vs two<br>
> >>>>><br>
> >>>>> Ryan had rightly pointed out that when we made the original proposal<br>
> >>>>>9am<br>
> >>>>> morning we had asked folks if they wanted to participate in a separate<br>
> >>>>> repository.<br>
> >>>>><br>
> >>>>> I don't think a separate repository is the correct approach based upon<br>
> >>>>>one<br>
> >>>>> off private conversations with folks at summit.  Many people from that<br>
> >>>>>list<br>
> >>>>> approached me and indicated they would like to see the work integrated<br>
> >>>>>in<br>
> >>>>> one repository as outlined in my vote proposal email.  The reasons I<br>
> >>>>>heard<br>
> >>>>> were:<br>
> >>>>><br>
> >>>>> Better integration of the community<br>
> >>>>> Better integration of the code base<br>
> >>>>> Doesn't present an us vs them mentality that one could argue happened<br>
> >>>>>during<br>
> >>>>> kolla-mesos<br>
> >>>>> A second repository makes k8s a second class citizen deployment<br>
> >>>>>architecture<br>
> >>>>> without a voice in the full deployment methodology<br>
> >>>>> Two gating methods versus one<br>
> >>>>> No going back to a unified repository while preserving git history<br>
> >>>>><br>
> >>>>> I favor of the separate repositories I heard<br>
> >>>>><br>
> >>>>> It presents a unified workspace for kubernetes alone<br>
> >>>>> Packaging without ansible is simpler as the ansible directory need not<br>
> >>>>>be<br>
> >>>>> deleted<br>
> >>>>><br>
> >>>>> There were other complaints but not many pros.  Unfortunately I failed<br>
> >>>>>to<br>
> >>>>> communicate these complaints to the core team prior to the vote, so<br>
> >>>>>now<br>
> >>>>>is<br>
> >>>>> the time for fixing that.<br>
> >>>>><br>
> >>>>> I'll leave it open to the new folks that want to do the work if they<br>
> >>>>>want to<br>
> >>>>> work on an offshoot repository and open us up to the possible problems<br>
> >>>>> above.<br>
> >>>>><br>
> >>>>> If you are on this list:<br>
> >>>>><br>
> >>>>> Ryan Hallisey<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>
> >>>>> Jinay Vora<br>
> >>>>> Hui Kang<br>
> >>>>> Davanum Srinivas<br>
> >>>>><br>
> >>>>><br>
> >>>>><br>
> >>>>> Please speak up if you are in favor of a separate repository or a<br>
> >>>>>unified<br>
> >>>>> repository.<br>
> >>>>><br>
> >>>>> The core reviewers will still take responsibility for determining if<br>
> >>>>>we<br>
> >>>>> proceed on the action of implementing kubernetes in general.<br>
> >>>>><br>
> >>>>> Thank you<br>
> >>>>> -steve<br>
> >>>>><br>
> >>>>><br>
> >>>>>_______________________________________________________________________<br>
> >>>>>_<br>
> >>>>>_<br>
> >>>>>_<br>
> >>>>> OpenStack Development Mailing List (not for usage questions)<br>
> >>>>> Unsubscribe:<br>
> >>>>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>>>><br>
> >>>><br>
> >>>><br>
> >>>>I am in the favor of having two separate repos and evaluating the<br>
> >>>>merge/split option later.<br>
> >>>>Though in the longer run, I would recommend having a single repo with<br>
> >>>>multiple stable deployment tools(maybe too early to comment views but<br>
> >>>>yeah)<br>
> >>>><br>
> >>>>Swapnil<br>
> >>><br>
> >>>Swapnil,<br>
> >>><br>
> >>>I gather this is what people want but this cannot be done with git and<br>
> >>>maintain history.  To do this, we would have to "cp oldrepo/files to<br>
> >>>newrepo/files" and the git history would be lost.  That is why choosing<br>
> >>>two repositories up front is irreversible.<br>
> >>><br>
> >>>Regards<br>
> >>>-steve<br>
> >>><br>
> >>>><br>
> >>>>________________________________________________________________________<br>
> >>>>_<br>
> >>>>_<br>
> >>>>OpenStack Development Mailing List (not for usage questions)<br>
> >>>>Unsubscribe:<br>
> >>>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >>><br>
> >>>_________________________________________________________________________<br>
> >>>_<br>
> >>>OpenStack Development Mailing List (not for usage questions)<br>
> >>>Unsubscribe:<br>
> >>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >>>_________________________________________________________________________<br>
> >>>_<br>
> >>>OpenStack Development Mailing List (not for usage questions)<br>
> >>>Unsubscribe:<br>
> >>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >>><br>
> >>>_________________________________________________________________________<br>
> >>>_<br>
> >>>OpenStack Development Mailing List (not for usage questions)<br>
> >>>Unsubscribe:<br>
> >>><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >>><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> >><br>
> >><br>
> >>__________________________________________________________________________<br>
> >>OpenStack Development Mailing List (not for usage questions)<br>
> >>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</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">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> >><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
> ><br>
> > __________________________________________________________________________<br>
> > OpenStack Development Mailing List (not for usage questions)<br>
> > Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> --<br>
> Davanum Srinivas :: <a href="https://twitter.com/dims">https://twitter.com/dims</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">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>