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

Steven Dake (stdake) stdake at cisco.com
Mon May 2 00:43:18 UTC 2016



On 5/1/16, 4:22 PM, "Ryan Hallisey" <rhallise at redhat.com> wrote:

>I'm voting for separate repo.  I'm not keen to adding 20 new cores to a
>stable repo.  I'd prefer it to be in a different repo while it gets
>going.  Yes, we will lose some git history *if* we vote to merge it into
>the main repo.  It's not a guarantee.

Just to clarify this point, we are not adding people to kolla-core that
want to paricipate in this effort.  Instead they would go in the
kolla-k8s-core ACL but would have effective permissions over the entire
repo but with the caveat that these invidiuals only approve commits to the
kubernetes repository.

>
>If this were to go into the main repo, I think it becomes harder for both
>ansible and kubernetes to ever come out.  I'd rather start outside since
>it's easier to move in if we choose to do that.

You have failed to convince me having these orchesetration engines in
separate repos are a good idea. :)

Regards
-steve
>
>-Ryan
>
>----- Original Message -----
>From: "Steven Dake (stdake)" <stdake at cisco.com>
>To: "OpenStack Development Mailing List (not for usage questions)"
><openstack-dev at lists.openstack.org>
>Sent: Sunday, May 1, 2016 5:03:57 PM
>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-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




More information about the OpenStack-dev mailing list