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