Seems like these are some of the same growing pains (cores can’t be experts on
all technologies) neutron went through. Maybe at the PTG we could pick their
brain and see if the path they have chosen would work well for Kolla.
Thx,
britt
On 12/24/16, 10:31 AM, "Steven Dake (stdake)" <std...@cisco.com> wrote:
My response wasn’t clear and I’ve also thought more about your proposal.
I’d be highly in favor of the approach you mentioned as long as 2 was modified
in your proposal to include some larger number then 2 individuals. One option
that comes to mind is a majority of each core review sub-team for point 2
taking into account some of our core reviewers have issues that temporarily
prevent them from fulfilling their core reviewer duties (although they plan to
re-engage).
I agree we don’t want to duplicate the TC – that would be super heavy – not
that the TC is heavy – but rather that Kolla doesn’t need its own governance
structure as the technical governance of OpenStack is directed by the technical
committee. I for one, don’t want to have a full-blown governance structure for
Kolla, although I can’t speak for other core reviewers.
Regards
-steve
-----Original Message-----
From: "Steven Dake (stdake)" <std...@cisco.com>
Date: Friday, December 23, 2016 at 3:53 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt deliverable
WFM – I’d be partly in favor of such an approach although I can’t speak
for others. I think we should require some larger set then 2 individuals from
the kolla-policy-core; perhaps a majority of active reviewers for some
definition of active reviewers.
Regards
-steve
-----Original Message-----
From: Michał Jastrzębski <inc...@gmail.com>
Reply-To: "OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org>
Date: Friday, December 23, 2016 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc] Re: [kolla] A new kolla-salt
deliverable
So I agree with you that we need policy established here. What I'm
getting at - which core teams will vote on inclusion of new
deliverable? All of them? Just Kolla? This is grey area I'm
referring
to. What's kolla-k8s core team's business if somebody would like to
add saltstack support? What I wouldn't want to have is to establish
new semi-tc in form of our core team that will decide what is and
isn't good orchiestration engine for Kolla. That would seriously
hinder our ability to innovate, experiment. What if we find out this
new orchiestration engine and just want to play with it? But keep it
community from start?
So let me throw an idea there, one which we should vote on:
Prep:
1. We create kolla-policy-core-team which is sum of all core teams
of
kolla supported projects
2. We create list of kolla supported projects - today it's kolla,
kolla-ansible and kolla-k8s
Add new project:
1. Everyone is free to create kolla-* deliverable as long as they
follow certain documented standards (action: document these)
2. We create lightweight process to include new deliverable to
Kolla,
like just 2* +2 from kolla-policy-core-team to include project like
that
3. If project gets traction, interest and is successful, we vote on
including it's core team to kolla-policy-core-team
This way it would be easy to try and fail fast to run kolla with
whatever. We need this kind of flexibility for people to innovate.
Thoughts?
Michal
On 23 December 2016 at 13:11, Steven Dake (stdake)
<std...@cisco.com> wrote:
> Michal,
>
> Really what I was getting at was placing in the governance
repository as a kolla deliverable. In days past we *always* voted on additions
and removals of deliverables. It doesn’t seem like a gray area to me – we have
always followed a voting pattern for adding and removal of deliverables. This
repo could be added to the git openstack namespace but then not have it as a
kolla deliverable without a vote I think; this is sort of what Fuel did with
Fuel-ccp – that proposal is a gray area. I found when Fuel did that to be
extremely odd personally ☺ I’m not sure if there is a trademark policy or
something similar that affects the use of Kolla and OpenStack together. I’ve
included the [tc] in the topic so they can provide guidance on the route you
suggested (incubation for new kolla deliverables that are not actually
deliverables).
>
> I think we really don’t need the tc to intervene here though, we
can just make new policies on our own via the typical policy voting process we
have followed in the past. Before we make any decisions about that though, I
think we need a vote on the topic. ☺
>
> Regards
> -steve
>
> -----Original Message-----
> From: Michał Jastrzębski <inc...@gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org>
> Date: Friday, December 23, 2016 at 10:08 AM
> To: "OpenStack Development Mailing List (not for usage
questions)" <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [kolla] A new kolla-salt deliverable
>
> Hello,
>
> Ok this is grey area we haven't had proper discussion yet, I
agree.
> Since we decided to have separate core teams, I personally
don't
> really see *why* we should have any form of vote for projects
to use
> kolla containers.
> Things change when we talk about it being kolla deliverable,
but what
> exactly does that mean? They can use kolla name? Everybody
can. They
> follow Kolla policies, use Kolla irc channel and have Kolla
PTL to
> represent them? That's also a choice everybody can make.
>
> In the spirit of inclusiveness, I'd say keep it free and
open. I would
> rather have people use kolla name, be open about using kolla
> containers and be part of our community. Maybe some sort of
"free to
> add, but incubate" would be in order, but I personally think
that
> would be overkill at this stage.
>
> Thoughts?
>
> Cheers Michal
>
> On 23 December 2016 at 05:34, Steven Dake (stdake)
<std...@cisco.com> wrote:
> > Michal,
> >
> >
> >
> > I was thinking about kolla-salt and our Wednesday team
meeting and the
> > declaration you made about how it should be done. I
personally feel it is
> > mandatory we hold a vote of the core review teams to add a
new deliverable.
> > We have voted on the addition of every deliverable we have
ever added to
> > kolla including application initially to the big tent. I’m
in favor of the
> > idea of kolla-salt and it would have my +1 vote. I am not
attempting to
> > block the addition. It’s more a matter of policies we have
established over
> > the last several years. We have also voted to retire
deliverables from the
> > Kolla project as well (kolla-mesos and the cli).
> >
> >
> >
> > This was easier when there was one core review team.
Perhaps a solution to
> > that problem is to make a global core team in gerrit which
includes everyone
> > just for policy decisions (such as adding a deliverable).
Another option to
> > count whether consensus was reached is to count the core
reviewers in each
> > deliverable, divide by two, and determine if consensus is
reached.
> >
> >
> >
> > If we don’t hold a vote, it looks like a BDFL model that
PTLs don’t operate
> > under. Rather PTLs operate under a service model.
> >
> >
> >
> > 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
