[openstack-dev] [kolla][kubernetes] One repo vs two

Jeffrey Zhang zhang.lei.fly at gmail.com
Tue May 3 16:03:55 UTC 2016


I +1 for split the kolla-k8s repo, too.

Here is the reason:

1. Kolla will be split into several repo in the future: kolla-docker,
kolla-ansible. So
   if we use one repo for k8s, we will split it again. It will be more
painful to do this.

2. Normally, the kolla-docker, kolla-ansible and kolla-k8s has less
relations between
   each other. We need decouple them. So split the repo will be helpful for
that. then
   different reviewer/committer cloud focus on her own domain.

On Tue, May 3, 2016 at 11:48 PM, Steven Dake (stdake) <stdake at cisco.com>
wrote:

> Paul,
>
> Just to be clear, we are not putting master on pause for 4-6 weeks to
> split apart the repos to enable kubernetes development.  The option on the
> table at this point are
> A) kolla repo as it exists today and empty repo for k8s
> B) kolla repo as it exists today with kubernetes integrated
>
> A pause would essentially kill any kubernetes effort.  Plus there is a
> whole bunch of reasons why not to split the main kolla repo.  The fact
> that our tools don't work well for this means that developers are less
> likely to go through backporting bug fixes, which means our stable
> branches may fall into disrepair.
>
> Keep in mind, our stable branches fell into disrepair last time because of
> tools.  We were not using launchpad correctly as a team, which we are now
> doing.  As a result back-porting is consistently done and done well.  A
> bunch of manual backports will result in a lower quality code base and I
> have concerns folks wouldn't end up backporting - or worse make errors
> since the process would no longer be automated.
>
> Regards
> -steve
>
> On 5/3/16, 2:23 AM, "Paul Bourke" <paul.bourke at oracle.com> wrote:
>
> >Having read through the full thread I'm still in support of separate
> >repos. I think the explanations Jeff Peeler and Adam Young have put
> >forward summarise my thoughts very well.
> >
> >One of the main arguments I seem to be hearing for a single repo is Git
> >tooling which I don't think is a good one; we should do what's best for
> >users and devs, not for tools.
> >
> >Also as the guys pointed out, multiple repos are the most common pattern
> >across OpenStack. I think it will help keep a better separation of
> >concerns. Otherwise in my experience you start to get cross
> >contamination of the projects, to the point where it becomes extremely
> >difficult to pull them apart.
> >
> >The images, ansible, and k8n need to be separate. The alternative is not
> >scalable.
> >
> >Thanks,
> >-Paul
> >
> >On 03/05/16 00:39, Angus Salkeld wrote:
> >> On Mon, May 2, 2016 at 7:07 AM Steven Dake (stdake) <stdake at cisco.com
> >> <mailto:stdake at cisco.com>> wrote:
> >>
> >>     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.
> >>
> >>
> >> +1 to the separate repo
> >>
> >> I think the separate repo worked very well for us and would encourage
> >> you to replicate that again. Having one repo doing one thing makes the
> >> goal of the repo obvious and makes the api between the images and
> >> deployment clearer (also the stablity of that
> >> api and things like permissions *cough* drop-root).
> >>
> >> -Angus
> >>
> >>
> >>     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-request at lists.openstack.org?subject:unsubscribe
> >>
> >><http://OpenStack-dev-request@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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards,
Jeffrey Zhang
Blog: http://xcodest.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160504/fcf638fc/attachment.html>


More information about the OpenStack-dev mailing list