Open Stack

On May 3, 2016 1:53 AM, "Davanum Srinivas" <davanum at 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) <stdake at 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.Fox at 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) [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
> >>
>
>>__________________________________________________________________________
> >>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
>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160503/aa344c5e/attachment.html>