[openstack-dev] [kolla][kubernetes] One repo vs two
Fox, Kevin M
Kevin.Fox at pnnl.gov
Mon May 2 19:04:29 UTC 2016
+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) [stdake at 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" <rhallise at 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.Fox at pnnl.gov>
>To: "OpenStack Development Mailing List (not for usage questions)"
><openstack-dev at 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) [stdake at 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" <me at coolsvap.net> wrote:
>
>>On Mon, May 2, 2016 at 9:54 AM, Britt Houser (bhouser)
>><bhouser at cisco.com> wrote:
>>> Although it seems I'm in the minority, I am in favor of unified repo.
>>>
>>> From: "Steven Dake (stdake)" <stdake at cisco.com>
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> <openstack-dev at lists.openstack.org>
>>> Date: Sunday, May 1, 2016 at 5:03 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> <openstack-dev at 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-request at 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-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
>
>__________________________________________________________________________
>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