Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Thierry,

Cool thanks for the leeway here ☺

I agree wholeheartedly with your last sentiment.  If an existing Kolla sub-team 
or an existing project (e.g. the Puppet team) in OpenStack or a new project 
wants to use Kolla images and feels they would operate more effectively without 
the structure Kolla has in place, I personally as a core reviewer don’t want to 
limit that type of activity as long as it fits within the TC’s governance 
rules.  As a core reviewer, I do want to keep what deliverables we currently 
have in place as splitting out deliverables is super disruptive to the Kolla 
project.  Over 60% of the Ocata cycle has been spent just splitting 
kolla-ansible into its own deliverable – meaning we are way behind on 
maintenance and development of our existing deliverables.  Like all things in 
life, my opinion is subject to change in the future.

Regards
-steve


-Original Message-
From: Thierry Carrez <thie...@openstack.org>
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, January 12, 2017 at 6:25 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Michał Jastrzębski wrote:
> So from my point of view, while I understand why project separation
> makes sense in the long run, I will argue that at this moment it will
> be hurtful for the project. Our community is still fairly integrated,
> and I'd love to keep it this way a while longer. We haven't yet fully
> cleaned up mess that split of kolla-ansible caused (documentation and
> whatnot). Having small revolution like that again is something that
> would greatly hinder our ability to deliver valuable project, and I
> think for now that should be our priority.

FWIW my email was not meant as an immediate request to split Kolla
because its internal structure goes against the OpenStack project
structure. In particular as long as the Kolla subteams are fine
operating under a single umbrella and being seen as a single "team",
there is no need to change that, that would be a distraction.

I just wanted to explain that a lot of the organizational problems the
Kolla team is going through are caused by this "umbrella" model and that
we designed the current OpenStack project structure precisely to avoid
them. I also don't want to discourage any Kolla subteam (or future
project leveraging Kolla images) which feels like it would operate
better as a separate project team to file for official inclusion.

Cheers!

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Thierry Carrez]

Michał Jastrzębski wrote:
> So from my point of view, while I understand why project separation
> makes sense in the long run, I will argue that at this moment it will
> be hurtful for the project. Our community is still fairly integrated,
> and I'd love to keep it this way a while longer. We haven't yet fully
> cleaned up mess that split of kolla-ansible caused (documentation and
> whatnot). Having small revolution like that again is something that
> would greatly hinder our ability to deliver valuable project, and I
> think for now that should be our priority.

FWIW my email was not meant as an immediate request to split Kolla
because its internal structure goes against the OpenStack project
structure. In particular as long as the Kolla subteams are fine
operating under a single umbrella and being seen as a single "team",
there is no need to change that, that would be a distraction.

I just wanted to explain that a lot of the organizational problems the
Kolla team is going through are caused by this "umbrella" model and that
we designed the current OpenStack project structure precisely to avoid
them. I also don't want to discourage any Kolla subteam (or future
project leveraging Kolla images) which feels like it would operate
better as a separate project team to file for official inclusion.

Cheers!

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Michał Jastrzębski]

Hey Brandon,

So couple comments to your mail.
Kolla at it's core is community which took on preparing deployment of
openstack using docker containers. This same community now is working with
both ansible and k8s as means to deploy these containers. So far we're
preserving that single community to allow full cooperation and let's be
honest, we still learn and experiment, especially in k8s space.

As for k8s being abstraction layer to container runtime, it indeed is, but
that's only part of the story. Container runtime is less important than
it's ABI for k8s deployment mechanism. With OCI container, what we today
have as docker containers can (don't know really, never tested) be
compatible with RKT, maybe with a bit of work. What's more important is how
to interact with these containers. Kolla honed our containers ABI over
multiple releases and we are still working on it. While k8s can run
multiple container formats, how do you interact with them depends on how
containers are built. While I can clearly see benefit of having
multi-runtime mechanism like that, all containers should follow same ABI
for deployment code to consume, and as far as I know (please, correct me if
I'm wrong), there is no alternative to Kolla's images that would be
compatible with Kolla ABI. So question about multiple runtimes becomes
hypothetical until one these appear. If there is community that is working
on alternative image format, I'd love to talk to them so we can try to keep
our ABIs compatible so deployment projects like one you describe can have
this choice too. I'd go further still, if such project would appear
(alternative container format), I'd be happy to discuss kolla-ansible and
kolla-k8s being able to consume it too! Just...nobody did that, doing that
or plant that as far as I know.

Cheers,
Michal

On 11 January 2017 at 12:09, Steven Dake (stdake) <std...@cisco.com> wrote:

> Sure – you asked me and I thought you wanted an answer from me (which fits
> under the do not use OpenStack properties (i.e. this mailing list) for
> promotion of candidates email that Mark sent out).
>
>
>
> Others are able to answer in the broader Kolla community.
>
>
>
> Regards
>
> -steve
>
>
>
> *From: *"Brandon B. Jozsa" <bjo...@jinkit.com>
> *Date: *Wednesday, January 11, 2017 at 1:01 PM
> *To: *"Britt Houser (bhouser)" <bhou...@cisco.com>, "Steven Dake
> (stdake)" <std...@cisco.com>, "OpenStack Development Mailing List (not
> for usage questions)" <openstack-dev@lists.openstack.org>
>
> *Subject: *Re: [openstack-dev] [tc][kolla] Adding new deliverables
>
>
>
>
>
> I’m not entirely sure how the two relate, but anyone from Kolla can
> respond.
>
>
>
> Brandon B. Jozsa
>
>
>
> On January 11, 2017 at 2:49:07 PM, Steven Dake (stdake) (std...@cisco.com)
> wrote:
>
> Brandon,
>
>
>
> Your question is a mix of political and technical aspects that I am not
> permitted to answer until Monday because of my parsing of this email from
> Mark Collier:
>
>
>
> http://lists.openstack.org/pipermail/foundation/2017-January/002446.html
>
>
>
> I will answer you Monday after the individual board of directors elections
> conclude.
>
>
>
> Regards
>
> -steve
>
>
>
>
>
> *From: *"Brandon B. Jozsa" <bjo...@jinkit.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Wednesday, January 11, 2017 at 12:36 PM
> *To: *"Britt Houser (bhouser)" <bhou...@cisco.com>, "OpenStack
> Development Mailing List (not for usage questions)" <openstack-dev@lists.
> openstack.org>
> *Subject: *Re: [openstack-dev] [tc][kolla] Adding new deliverables
>
>
>
> To your point Steve, then I’d image that Kolla would have no objection to
> the introduction of other Openstack-namespace projects that provide
> alternative image formats, integration choices, or orchestration variances
> for those in the larger community who do not want to use Kolla images. All
> of the Kolla-x projects point to this one source of truth in the end. This
> results in large to the many projects falling under the Kolla umbrella:
> Kolla, Kolla-Mesos, Kolla-Ansible, Kolla-Kubernetes, Kolla-Salt, and I’d
> assume whatever else wants to consume Kolla, if things continue as they are.
>
>
>
> My immediate ask is "what are the potential negative impacts to Kolla
> having so many projects under one mission”: fragmentation of goals,
> misunderstanding of mission, increased developer debt across each
> inter-twined project (cross-repo commits and reviews), complex gating
> requirements? #kolla has been a place of spirited debate wi

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Sure – you asked me and I thought you wanted an answer from me (which fits 
under the do not use OpenStack properties (i.e. this mailing list) for 
promotion of candidates email that Mark sent out).

Others are able to answer in the broader Kolla community.

Regards
-steve

From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Date: Wednesday, January 11, 2017 at 1:01 PM
To: "Britt Houser (bhouser)" <bhou...@cisco.com>, "Steven Dake (stdake)" 
<std...@cisco.com>, "OpenStack Development Mailing List (not for usage 
questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables


I’m not entirely sure how the two relate, but anyone from Kolla can respond.

Brandon B. Jozsa


On January 11, 2017 at 2:49:07 PM, Steven Dake (stdake) 
(std...@cisco.com<mailto:std...@cisco.com>) wrote:
Brandon,

Your question is a mix of political and technical aspects that I am not 
permitted to answer until Monday because of my parsing of this email from Mark 
Collier:

http://lists.openstack.org/pipermail/foundation/2017-January/002446.html

I will answer you Monday after the individual board of directors elections 
conclude.

Regards
-steve


From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 12:36 PM
To: "Britt Houser (bhouser)" <bhou...@cisco.com>, "OpenStack Development 
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

To your point Steve, then I’d image that Kolla would have no objection to the 
introduction of other Openstack-namespace projects that provide alternative 
image formats, integration choices, or orchestration variances for those in the 
larger community who do not want to use Kolla images. All of the Kolla-x 
projects point to this one source of truth in the end. This results in large to 
the many projects falling under the Kolla umbrella: Kolla, Kolla-Mesos, 
Kolla-Ansible, Kolla-Kubernetes, Kolla-Salt, and I’d assume whatever else wants 
to consume Kolla, if things continue as they are.

My immediate ask is "what are the potential negative impacts to Kolla having so 
many projects under one mission”: fragmentation of goals, misunderstanding of 
mission, increased developer debt across each inter-twined project (cross-repo 
commits and reviews), complex gating requirements? #kolla has been a place of 
spirited debate with the recent addition of Kolla-Kubernetes, and I think some 
of this is the result of the problems I’m alluding to. It’s very difficult to 
preserve what Kolla is at it’s core, and in turn preserve the benefits of 
something like Kubernetes which has a Runtime Interface abstraction model. It’s 
a tough sell for the larger Openstack community, and this is a critical time 
for Openstack and CNCF interoperability; would you not agree?

I’m failing to see the benefits you mention outweighing what others might see 
as potential pitfalls. My viewpoint is not news to those in Kolla. I’ve 
expressed this in Kolla already, and this is why I’m disappointed when 
Kolla-Kuberntes drops Secs in favor of quicker ad-hoc IRC 
architecturally-focused discussions.

So my question now becomes; "How is Kolla addressing these issues, and what has 
Kolla been doing with the assistance of the Openstack Foundation to gain the 
confidence of those who are watching Kolla and looking for that next cool 
container project”?

Brandon B. Jozsa


On January 11, 2017 at 1:46:13 PM, Britt Houser (bhouser) 
(bhou...@cisco.com<mailto:bhou...@cisco.com>) wrote:
My sentiments exactly Michal. We’ll get there, but let’s not jump the gun quite 
yet.

On 1/11/17, 1:38 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote:

So from my point of view, while I understand why project separation
makes sense in the long run, I will argue that at this moment it will
be hurtful for the project. Our community is still fairly integrated,
and I'd love to keep it this way a while longer. We haven't yet fully
cleaned up mess that split of kolla-ansible caused (documentation and
whatnot). Having small revolution like that again is something that
would greatly hinder our ability to deliver valuable project, and I
think for now that should be our priority.

To me, at least before we will have more than one prod-ready
deployment tool, separation of projects would be bad. I think project
separation should be a process instead of revolution, and we already
started this process by separating kolla-ansible repo and core team.
I'd be happy to discuss how to pave road for full project separation
without causing pain for operators, users and developers, as to me
their best interest should take priority.

Cheers,
Michal

On 1

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Brandon B. Jozsa]

I’m not entirely sure how the two relate, but anyone from Kolla can respond.

Brandon B. Jozsa


On January 11, 2017 at 2:49:07 PM, Steven Dake (stdake) 
(std...@cisco.com<mailto:std...@cisco.com>) wrote:
Brandon,

Your question is a mix of political and technical aspects that I am not 
permitted to answer until Monday because of my parsing of this email from Mark 
Collier:

http://lists.openstack.org/pipermail/foundation/2017-January/002446.html

I will answer you Monday after the individual board of directors elections 
conclude.

Regards
-steve


From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 12:36 PM
To: "Britt Houser (bhouser)" <bhou...@cisco.com>, "OpenStack Development 
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

To your point Steve, then I’d image that Kolla would have no objection to the 
introduction of other Openstack-namespace projects that provide alternative 
image formats, integration choices, or orchestration variances for those in the 
larger community who do not want to use Kolla images. All of the Kolla-x 
projects point to this one source of truth in the end. This results in large to 
the many projects falling under the Kolla umbrella: Kolla, Kolla-Mesos, 
Kolla-Ansible, Kolla-Kubernetes, Kolla-Salt, and I’d assume whatever else wants 
to consume Kolla, if things continue as they are.

My immediate ask is "what are the potential negative impacts to Kolla having so 
many projects under one mission”: fragmentation of goals, misunderstanding of 
mission, increased developer debt across each inter-twined project (cross-repo 
commits and reviews), complex gating requirements? #kolla has been a place of 
spirited debate with the recent addition of Kolla-Kubernetes, and I think some 
of this is the result of the problems I’m alluding to. It’s very difficult to 
preserve what Kolla is at it’s core, and in turn preserve the benefits of 
something like Kubernetes which has a Runtime Interface abstraction model. It’s 
a tough sell for the larger Openstack community, and this is a critical time 
for Openstack and CNCF interoperability; would you not agree?

I’m failing to see the benefits you mention outweighing what others might see 
as potential pitfalls. My viewpoint is not news to those in Kolla. I’ve 
expressed this in Kolla already, and this is why I’m disappointed when 
Kolla-Kuberntes drops Secs in favor of quicker ad-hoc IRC 
architecturally-focused discussions.

So my question now becomes; "How is Kolla addressing these issues, and what has 
Kolla been doing with the assistance of the Openstack Foundation to gain the 
confidence of those who are watching Kolla and looking for that next cool 
container project”?

Brandon B. Jozsa


On January 11, 2017 at 1:46:13 PM, Britt Houser (bhouser) 
(bhou...@cisco.com<mailto:bhou...@cisco.com>) wrote:
My sentiments exactly Michal. We’ll get there, but let’s not jump the gun quite 
yet.

On 1/11/17, 1:38 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote:

So from my point of view, while I understand why project separation
makes sense in the long run, I will argue that at this moment it will
be hurtful for the project. Our community is still fairly integrated,
and I'd love to keep it this way a while longer. We haven't yet fully
cleaned up mess that split of kolla-ansible caused (documentation and
whatnot). Having small revolution like that again is something that
would greatly hinder our ability to deliver valuable project, and I
think for now that should be our priority.

To me, at least before we will have more than one prod-ready
deployment tool, separation of projects would be bad. I think project
separation should be a process instead of revolution, and we already
started this process by separating kolla-ansible repo and core team.
I'd be happy to discuss how to pave road for full project separation
without causing pain for operators, users and developers, as to me
their best interest should take priority.

Cheers,
Michal

On 11 January 2017 at 09:59, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
>> Thierry,
>>
>> I am not a big fan of the separate gerrit teams we have instituted inside 
>> the Kolla project. I always believed we should have one core reviewer team 
>> responsible for all deliverables to avoid not just the appearance but the 
>> reality that each team would fragment the overall community of people 
>> working on Kolla containers and deployment tools. This is yet another reason 
>> I didn’t want to split the repositories into separate deliverables in the 
>

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Brandon,

Your question is a mix of political and technical aspects that I am not 
permitted to answer until Monday because of my parsing of this email from Mark 
Collier:

http://lists.openstack.org/pipermail/foundation/2017-January/002446.html

I will answer you Monday after the individual board of directors elections 
conclude.

Regards
-steve


From: "Brandon B. Jozsa" <bjo...@jinkit.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 12:36 PM
To: "Britt Houser (bhouser)" <bhou...@cisco.com>, "OpenStack Development 
Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

To your point Steve, then I’d image that Kolla would have no objection to the 
introduction of other Openstack-namespace projects that provide alternative 
image formats, integration choices, or orchestration variances for those in the 
larger community who do not want to use Kolla images. All of the Kolla-x 
projects point to this one source of truth in the end. This results in large to 
the many projects falling under the Kolla umbrella: Kolla, Kolla-Mesos, 
Kolla-Ansible, Kolla-Kubernetes, Kolla-Salt, and I’d assume whatever else wants 
to consume Kolla, if things continue as they are.

My immediate ask is "what are the potential negative impacts to Kolla having so 
many projects under one mission”: fragmentation of goals, misunderstanding of 
mission, increased developer debt across each inter-twined project (cross-repo 
commits and reviews), complex gating requirements? #kolla has been a place of 
spirited debate with the recent addition of Kolla-Kubernetes, and I think some 
of this is the result of the problems I’m alluding to. It’s very difficult to 
preserve what Kolla is at it’s core, and in turn preserve the benefits of 
something like Kubernetes which has a Runtime Interface abstraction model. It’s 
a tough sell for the larger Openstack community, and this is a critical time 
for Openstack and CNCF interoperability; would you not agree?

I’m failing to see the benefits you mention outweighing what others might see 
as potential pitfalls. My viewpoint is not news to those in Kolla. I’ve 
expressed this in Kolla already, and this is why I’m disappointed when 
Kolla-Kuberntes drops Secs in favor of quicker ad-hoc IRC 
architecturally-focused discussions.

So my question now becomes; "How is Kolla addressing these issues, and what has 
Kolla been doing with the assistance of the Openstack Foundation to gain the 
confidence of those who are watching Kolla and looking for that next cool 
container project”?

Brandon B. Jozsa


On January 11, 2017 at 1:46:13 PM, Britt Houser (bhouser) 
(bhou...@cisco.com<mailto:bhou...@cisco.com>) wrote:
My sentiments exactly Michal. We’ll get there, but let’s not jump the gun quite 
yet.

On 1/11/17, 1:38 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote:

So from my point of view, while I understand why project separation
makes sense in the long run, I will argue that at this moment it will
be hurtful for the project. Our community is still fairly integrated,
and I'd love to keep it this way a while longer. We haven't yet fully
cleaned up mess that split of kolla-ansible caused (documentation and
whatnot). Having small revolution like that again is something that
would greatly hinder our ability to deliver valuable project, and I
think for now that should be our priority.

To me, at least before we will have more than one prod-ready
deployment tool, separation of projects would be bad. I think project
separation should be a process instead of revolution, and we already
started this process by separating kolla-ansible repo and core team.
I'd be happy to discuss how to pave road for full project separation
without causing pain for operators, users and developers, as to me
their best interest should take priority.

Cheers,
Michal

On 11 January 2017 at 09:59, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
>> Thierry,
>>
>> I am not a big fan of the separate gerrit teams we have instituted inside 
>> the Kolla project. I always believed we should have one core reviewer team 
>> responsible for all deliverables to avoid not just the appearance but the 
>> reality that each team would fragment the overall community of people 
>> working on Kolla containers and deployment tools. This is yet another reason 
>> I didn’t want to split the repositories into separate deliverables in the 
>> first place – since it further fragments the community working on Kolla 
>> deliverables.
>>
>> When we made our original mission statement, I originally wanted it scoped 
>> around j

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Brandon B. Jozsa]

t; get everyone working together rather than apart. That is, unless those folks 
>> want to “work apart” which of course is their prerogative. I wouldn’t 
>> suggest merging teams today that are separate that don’t have a desire to 
>> merge. That said, Kolla is very warm and open to new contributors so 
>> hopefully no more new duplicate effort solutions are started.
>
> It sure sounds to me like you want Kolla to "own" container deployment
> tools. As Thierry said, we aren't intended to be organized that way any
> more.
>
>> Siloing the deliverables into separate teams I believe would result in the 
>> competition I just mentioned, and further discord between the deployment 
>> tool projects in the big tent. We need consolidation around people working 
>> together, not division. Division around Kolla weakens Kolla specifically and 
>> doesn’t help out OpenStack all that much either.
>
> I would hope that the spirit of collaboration could extend across team
> boundaries. #WeAreOpenStack
>
> Doug
>
>>
>> The idea of branding or themes is not really relevant to me. Instead this is 
>> all about the people producing and consuming Kolla. I’d like these folks to 
>> work together as much as feasible. Breaking a sub-community apart (in this 
>> case Kolla) into up to 4 different communities with 4 different PTLs sounds 
>> wrong to me.
>>
>> I hope my position is clear ☺ If not, feel free to ask any follow-up 
>> questions.
>>
>> Regards
>> -steve
>>
>> -Original Message-----
>> From: Thierry Carrez <thie...@openstack.org>
>> Organization: OpenStack
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>> <openstack-dev@lists.openstack.org>
>> Date: Wednesday, January 11, 2017 at 4:21 AM
>> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables
>>
>> Michał Jastrzębski wrote:
>> > I created CIVS poll with options we discussed. Every core member should
>> > get link to poll voting, if that's not the case, please let me know.
>>
>> Just a quick sidenote to explain how the "big-tent" model of governance
>> plays in here...
>>
>> In the previous project structure model, we had "programs". If you
>> wanted to do networking stuff, you had to join the Networking program
>> (neutron). If you worked on object storage, you had to join the Object
>> Storage program (swift). The main issue with this model is that it
>> prevented alternate approaches from emerging (as a program PTL could
>> just refuse its emergence to continue to "own" that space). It also
>> created weird situations where there would be multiple distinct groups
>> of people in a program, but a single PTL to elect to represent them all.
>> That created unnecessary political issues within programs and tension
>> around PTL election.
>>
>> Part of the big-tent project structure reform was to abolish programs
>> and organize our work around "teams", rather than "themes". Project
>> teams should be strongly aligned with a single team of people that work
>> together. That allowed some amount of competition to emerge (we still
>> try to avoid "gratuitous duplication of effort"), but most importantly
>> made sure groups of people could "own" their work without having to
>> defer to an outside core team or PTL. So if you have a distinct team, it
>> should be its own separate project team with its own PTL. There is no
>> program or namespace anymore. As a bonus side-effect, it made sure teams
>> would not indefinitely grow, and we all know that it's difficult to grow
>> core teams (and trust) beyond a certain point.
>>
>> This is why we have multiple packaging project teams, each specialized
>> in a given package orchestration mechanism, rather than have a single
>> "Packaging" program with a single PTL and Ansible / Puppet / Chef
>> fighting in elections to get their man at the helm. This is why the
>> Storlets team, while deeply related to Swift and in very good
>> collaboration terms with them, was set up as a separate project team.
>> Different people, different team.
>>
>> The fact that you're having hard discussions in Kolla about "adding new
>> deliverables" produced by distinct groups of people indicates that you
>> may be using Kolla as an old-style "program" rather than as a single
>> team. Why not set them up as separate project teams ? What am 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Britt Houser (bhouser)]

My sentiments exactly Michal.  We’ll get there, but let’s not jump the gun 
quite yet.

On 1/11/17, 1:38 PM, "Michał Jastrzębski" <inc...@gmail.com> wrote:

So from my point of view, while I understand why project separation
makes sense in the long run, I will argue that at this moment it will
be hurtful for the project. Our community is still fairly integrated,
and I'd love to keep it this way a while longer. We haven't yet fully
cleaned up mess that split of kolla-ansible caused (documentation and
whatnot). Having small revolution like that again is something that
would greatly hinder our ability to deliver valuable project, and I
think for now that should be our priority.

To me, at least before we will have more than one prod-ready
deployment tool, separation of projects would be bad. I think project
separation should be a process instead of revolution, and we already
started this process by separating kolla-ansible repo and core team.
I'd be happy to discuss how to pave road for full project separation
without causing pain for operators, users and developers, as to me
their best interest should take priority.

Cheers,
Michal

On 11 January 2017 at 09:59, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
>> Thierry,
>>
>> I am not a big fan of the separate gerrit teams we have instituted 
inside the Kolla project.  I always believed we should have one core reviewer 
team responsible for all deliverables to avoid not just the appearance but the 
reality that each team would fragment the overall community of people working 
on Kolla containers and deployment tools.  This is yet another reason I didn’t 
want to split the repositories into separate deliverables in the first place – 
since it further fragments the community working on Kolla deliverables.
>>
>> When we made our original mission statement, I originally wanted it 
scoped around just Ansible and Docker.  Fortunately, the core review team at 
the time made it much more general and broad before we joined the big tent.  
Our mission statement permits multiple different orchestration tools.
>>
>> Kolla is not “themed”, at least to me.  Instead it is one community with 
slightly different interests (some people work on Ansible, some on Kubernetes, 
some on containers, some on all 3, etc).  If we break that into separate 
projects with separate PTLs, those projects may end up competing with each 
other (which isn’t happening now inside Kolla).  I think competition is a good 
thing.  In this case, I am of the opinion it is high time we end the 
competition on deployment tools related to containers and get everyone working 
together rather than apart.  That is, unless those folks want to “work apart” 
which of course is their prerogative.  I wouldn’t suggest merging teams today 
that are separate that don’t have a desire to merge.  That said, Kolla is very 
warm and open to new contributors so hopefully no more new duplicate effort 
solutions are started.
>
> It sure sounds to me like you want Kolla to "own" container deployment
> tools. As Thierry said, we aren't intended to be organized that way any
> more.
>
>> Siloing the deliverables into separate teams I believe would result in 
the competition I just mentioned, and further discord between the deployment 
tool projects in the big tent.  We need consolidation around people working 
together, not division.  Division around Kolla weakens Kolla specifically and 
doesn’t help out OpenStack all that much either.
>
> I would hope that the spirit of collaboration could extend across team
> boundaries. #WeAreOpenStack
>
> Doug
>
>>
>> The idea of branding or themes is not really relevant to me.  Instead 
this is all about the people producing and consuming Kolla.  I’d like these 
folks to work together as much as feasible.  Breaking a sub-community apart (in 
this case Kolla) into up to 4 different communities with 4 different PTLs 
sounds wrong to me.
>>
>> I hope my position is clear ☺  If not, feel free to ask any follow-up 
questions.
>>
>> Regards
>> -steve
>>
>> -Original Message-
>> From: Thierry Carrez <thie...@openstack.org>
>> Organization: OpenStack
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
>> Date: Wednesday, January 11, 2017 at 4:21 AM
>> To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Doug,

I apologize for not being able to reply inline.  Bug in outlook.  I am probably 
going to start posting/responding on the ml with my gmail account so I can 
properly communicate with ml.

To your two points.

I don’t want kolla to “own” all deployment with containers.  I want kolla and 
it’s deliverables to operate as one community.  TripleO is consuming kolla 
containers currently – and our core team is suppoprtive of that.  Just this 
morning I  approved a tripleo blueprint to enable TripleO to use kolla 
containers.  My actions maybe here speak louder than my words ☺

I agree we could work across project boundaries because we are one community 
(OpenStack).  I also believe it would be more difficult to do so because of 
channel siloing, meeting siloing, developer siloing, etc.

Kolla really works hard to operate within the boundaries of the 4 Opens without 
ANY exception.

Regards
-steve


-Original Message-
From: Doug Hellmann <d...@doughellmann.com>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 10:59 AM
To: openstack-dev <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
> Thierry,
> 
> I am not a big fan of the separate gerrit teams we have instituted inside 
the Kolla project.  I always believed we should have one core reviewer team 
responsible for all deliverables to avoid not just the appearance but the 
reality that each team would fragment the overall community of people working 
on Kolla containers and deployment tools.  This is yet another reason I didn’t 
want to split the repositories into separate deliverables in the first place – 
since it further fragments the community working on Kolla deliverables.
> 
> When we made our original mission statement, I originally wanted it 
scoped around just Ansible and Docker.  Fortunately, the core review team at 
the time made it much more general and broad before we joined the big tent.  
Our mission statement permits multiple different orchestration tools.
> 
> Kolla is not “themed”, at least to me.  Instead it is one community with 
slightly different interests (some people work on Ansible, some on Kubernetes, 
some on containers, some on all 3, etc).  If we break that into separate 
projects with separate PTLs, those projects may end up competing with each 
other (which isn’t happening now inside Kolla).  I think competition is a good 
thing.  In this case, I am of the opinion it is high time we end the 
competition on deployment tools related to containers and get everyone working 
together rather than apart.  That is, unless those folks want to “work apart” 
which of course is their prerogative.  I wouldn’t suggest merging teams today 
that are separate that don’t have a desire to merge.  That said, Kolla is very 
warm and open to new contributors so hopefully no more new duplicate effort 
solutions are started.

It sure sounds to me like you want Kolla to "own" container deployment
tools. As Thierry said, we aren't intended to be organized that way any
more.

> Siloing the deliverables into separate teams I believe would result in 
the competition I just mentioned, and further discord between the deployment 
tool projects in the big tent.  We need consolidation around people working 
together, not division.  Division around Kolla weakens Kolla specifically and 
doesn’t help out OpenStack all that much either.

I would hope that the spirit of collaboration could extend across team
boundaries. #WeAreOpenStack

Doug

> 
> The idea of branding or themes is not really relevant to me.  Instead 
this is all about the people producing and consuming Kolla.  I’d like these 
folks to work together as much as feasible.  Breaking a sub-community apart (in 
this case Kolla) into up to 4 different communities with 4 different PTLs 
sounds wrong to me.
> 
> I hope my position is clear ☺  If not, feel free to ask any follow-up 
questions.
> 
> Regards
> -steve
> 
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org>
> Organization: OpenStack
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
> Date: Wednesday, January 11, 2017 at 4:21 AM
> To: "openstack-dev@lists.openstack.org" 
<openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables
> 
> Michał Jastrzębski wrote:
> > I created CIVS poll with options we discussed. Every core member 
should
> > get link to poll voting

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Michał Jastrzębski]

So from my point of view, while I understand why project separation
makes sense in the long run, I will argue that at this moment it will
be hurtful for the project. Our community is still fairly integrated,
and I'd love to keep it this way a while longer. We haven't yet fully
cleaned up mess that split of kolla-ansible caused (documentation and
whatnot). Having small revolution like that again is something that
would greatly hinder our ability to deliver valuable project, and I
think for now that should be our priority.

To me, at least before we will have more than one prod-ready
deployment tool, separation of projects would be bad. I think project
separation should be a process instead of revolution, and we already
started this process by separating kolla-ansible repo and core team.
I'd be happy to discuss how to pave road for full project separation
without causing pain for operators, users and developers, as to me
their best interest should take priority.

Cheers,
Michal

On 11 January 2017 at 09:59, Doug Hellmann <d...@doughellmann.com> wrote:
> Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
>> Thierry,
>>
>> I am not a big fan of the separate gerrit teams we have instituted inside 
>> the Kolla project.  I always believed we should have one core reviewer team 
>> responsible for all deliverables to avoid not just the appearance but the 
>> reality that each team would fragment the overall community of people 
>> working on Kolla containers and deployment tools.  This is yet another 
>> reason I didn’t want to split the repositories into separate deliverables in 
>> the first place – since it further fragments the community working on Kolla 
>> deliverables.
>>
>> When we made our original mission statement, I originally wanted it scoped 
>> around just Ansible and Docker.  Fortunately, the core review team at the 
>> time made it much more general and broad before we joined the big tent.  Our 
>> mission statement permits multiple different orchestration tools.
>>
>> Kolla is not “themed”, at least to me.  Instead it is one community with 
>> slightly different interests (some people work on Ansible, some on 
>> Kubernetes, some on containers, some on all 3, etc).  If we break that into 
>> separate projects with separate PTLs, those projects may end up competing 
>> with each other (which isn’t happening now inside Kolla).  I think 
>> competition is a good thing.  In this case, I am of the opinion it is high 
>> time we end the competition on deployment tools related to containers and 
>> get everyone working together rather than apart.  That is, unless those 
>> folks want to “work apart” which of course is their prerogative.  I wouldn’t 
>> suggest merging teams today that are separate that don’t have a desire to 
>> merge.  That said, Kolla is very warm and open to new contributors so 
>> hopefully no more new duplicate effort solutions are started.
>
> It sure sounds to me like you want Kolla to "own" container deployment
> tools. As Thierry said, we aren't intended to be organized that way any
> more.
>
>> Siloing the deliverables into separate teams I believe would result in the 
>> competition I just mentioned, and further discord between the deployment 
>> tool projects in the big tent.  We need consolidation around people working 
>> together, not division.  Division around Kolla weakens Kolla specifically 
>> and doesn’t help out OpenStack all that much either.
>
> I would hope that the spirit of collaboration could extend across team
> boundaries. #WeAreOpenStack
>
> Doug
>
>>
>> The idea of branding or themes is not really relevant to me.  Instead this 
>> is all about the people producing and consuming Kolla.  I’d like these folks 
>> to work together as much as feasible.  Breaking a sub-community apart (in 
>> this case Kolla) into up to 4 different communities with 4 different PTLs 
>> sounds wrong to me.
>>
>> I hope my position is clear ☺  If not, feel free to ask any follow-up 
>> questions.
>>
>> Regards
>> -steve
>>
>> -Original Message-----
>> From: Thierry Carrez <thie...@openstack.org>
>> Organization: OpenStack
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
>> <openstack-dev@lists.openstack.org>
>> Date: Wednesday, January 11, 2017 at 4:21 AM
>> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables
>>
>> Michał Jastrzębski wrote:
>> > I created CIVS poll with options we discussed. Every

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Doug Hellmann]

Excerpts from Steven Dake (stdake)'s message of 2017-01-11 14:50:31 +:
> Thierry,
> 
> I am not a big fan of the separate gerrit teams we have instituted inside the 
> Kolla project.  I always believed we should have one core reviewer team 
> responsible for all deliverables to avoid not just the appearance but the 
> reality that each team would fragment the overall community of people working 
> on Kolla containers and deployment tools.  This is yet another reason I 
> didn’t want to split the repositories into separate deliverables in the first 
> place – since it further fragments the community working on Kolla 
> deliverables.
> 
> When we made our original mission statement, I originally wanted it scoped 
> around just Ansible and Docker.  Fortunately, the core review team at the 
> time made it much more general and broad before we joined the big tent.  Our 
> mission statement permits multiple different orchestration tools.
> 
> Kolla is not “themed”, at least to me.  Instead it is one community with 
> slightly different interests (some people work on Ansible, some on 
> Kubernetes, some on containers, some on all 3, etc).  If we break that into 
> separate projects with separate PTLs, those projects may end up competing 
> with each other (which isn’t happening now inside Kolla).  I think 
> competition is a good thing.  In this case, I am of the opinion it is high 
> time we end the competition on deployment tools related to containers and get 
> everyone working together rather than apart.  That is, unless those folks 
> want to “work apart” which of course is their prerogative.  I wouldn’t 
> suggest merging teams today that are separate that don’t have a desire to 
> merge.  That said, Kolla is very warm and open to new contributors so 
> hopefully no more new duplicate effort solutions are started.

It sure sounds to me like you want Kolla to "own" container deployment
tools. As Thierry said, we aren't intended to be organized that way any
more.

> Siloing the deliverables into separate teams I believe would result in the 
> competition I just mentioned, and further discord between the deployment tool 
> projects in the big tent.  We need consolidation around people working 
> together, not division.  Division around Kolla weakens Kolla specifically and 
> doesn’t help out OpenStack all that much either.

I would hope that the spirit of collaboration could extend across team
boundaries. #WeAreOpenStack

Doug

> 
> The idea of branding or themes is not really relevant to me.  Instead this is 
> all about the people producing and consuming Kolla.  I’d like these folks to 
> work together as much as feasible.  Breaking a sub-community apart (in this 
> case Kolla) into up to 4 different communities with 4 different PTLs sounds 
> wrong to me.
> 
> I hope my position is clear ☺  If not, feel free to ask any follow-up 
> questions.
> 
> Regards
> -steve
> 
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org>
> Organization: OpenStack
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev@lists.openstack.org>
> Date: Wednesday, January 11, 2017 at 4:21 AM
> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables
> 
> Michał Jastrzębski wrote:
> > I created CIVS poll with options we discussed. Every core member should
> > get link to poll voting, if that's not the case, please let me know.
> 
> Just a quick sidenote to explain how the "big-tent" model of governance
> plays in here...
> 
> In the previous project structure model, we had "programs". If you
> wanted to do networking stuff, you had to join the Networking program
> (neutron). If you worked on object storage, you had to join the Object
> Storage program (swift). The main issue with this model is that it
> prevented alternate approaches from emerging (as a program PTL could
> just refuse its emergence to continue to "own" that space). It also
> created weird situations where there would be multiple distinct groups
> of people in a program, but a single PTL to elect to represent them all.
> That created unnecessary political issues within programs and tension
> around PTL election.
> 
> Part of the big-tent project structure reform was to abolish programs
> and organize our work around "teams", rather than "themes". Project
> teams should be strongly aligned with a single team of people that work
> together. That allowed some amount of competition to emerge (we still
> 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steve Wilkerson]

.

I'd also like to see people with the same targeted means for achieving the
same end working together.  I think splitting the Kolla-* out into their
own projects and letting the contributors interested in those projects work
on them separately best enables that goal, not having them operate under
one, large umbrella.












On Wed, Jan 11, 2017 at 8:50 AM, Steven Dake (stdake) <std...@cisco.com>
wrote:

> Thierry,
>
> I am not a big fan of the separate gerrit teams we have instituted inside
> the Kolla project.  I always believed we should have one core reviewer team
> responsible for all deliverables to avoid not just the appearance but the
> reality that each team would fragment the overall community of people
> working on Kolla containers and deployment tools.  This is yet another
> reason I didn’t want to split the repositories into separate deliverables
> in the first place – since it further fragments the community working on
> Kolla deliverables.
>
> When we made our original mission statement, I originally wanted it scoped
> around just Ansible and Docker.  Fortunately, the core review team at the
> time made it much more general and broad before we joined the big tent.
> Our mission statement permits multiple different orchestration tools.
>
> Kolla is not “themed”, at least to me.  Instead it is one community with
> slightly different interests (some people work on Ansible, some on
> Kubernetes, some on containers, some on all 3, etc).  If we break that into
> separate projects with separate PTLs, those projects may end up competing
> with each other (which isn’t happening now inside Kolla).  I think
> competition is a good thing.  In this case, I am of the opinion it is high
> time we end the competition on deployment tools related to containers and
> get everyone working together rather than apart.  That is, unless those
> folks want to “work apart” which of course is their prerogative.  I
> wouldn’t suggest merging teams today that are separate that don’t have a
> desire to merge.  That said, Kolla is very warm and open to new
> contributors so hopefully no more new duplicate effort solutions are
> started.
>
> Siloing the deliverables into separate teams I believe would result in the
> competition I just mentioned, and further discord between the deployment
> tool projects in the big tent.  We need consolidation around people working
> together, not division.  Division around Kolla weakens Kolla specifically
> and doesn’t help out OpenStack all that much either.
>
> The idea of branding or themes is not really relevant to me.  Instead this
> is all about the people producing and consuming Kolla.  I’d like these
> folks to work together as much as feasible.  Breaking a sub-community apart
> (in this case Kolla) into up to 4 different communities with 4 different
> PTLs sounds wrong to me.
>
> I hope my position is clear ☺  If not, feel free to ask any follow-up
> questions.
>
> Regards
> -steve
>
>
> -Original Message-
> From: Thierry Carrez <thie...@openstack.org>
> Organization: OpenStack
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, January 11, 2017 at 4:21 AM
> To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org
> >
> Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables
>
> Michał Jastrzębski wrote:
> > I created CIVS poll with options we discussed. Every core member
> should
> > get link to poll voting, if that's not the case, please let me know.
>
> Just a quick sidenote to explain how the "big-tent" model of governance
> plays in here...
>
> In the previous project structure model, we had "programs". If you
> wanted to do networking stuff, you had to join the Networking program
> (neutron). If you worked on object storage, you had to join the Object
> Storage program (swift). The main issue with this model is that it
> prevented alternate approaches from emerging (as a program PTL could
> just refuse its emergence to continue to "own" that space). It also
> created weird situations where there would be multiple distinct groups
> of people in a program, but a single PTL to elect to represent them
> all.
> That created unnecessary political issues within programs and tension
> around PTL election.
>
> Part of the big-tent project structure reform was to abolish programs
> and organize our work around "teams", rather than "themes". Project
> teams should be strongly aligned with a single team of people that work
> together. That allowed so

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Thierry,

I am not a big fan of the separate gerrit teams we have instituted inside the 
Kolla project.  I always believed we should have one core reviewer team 
responsible for all deliverables to avoid not just the appearance but the 
reality that each team would fragment the overall community of people working 
on Kolla containers and deployment tools.  This is yet another reason I didn’t 
want to split the repositories into separate deliverables in the first place – 
since it further fragments the community working on Kolla deliverables.

When we made our original mission statement, I originally wanted it scoped 
around just Ansible and Docker.  Fortunately, the core review team at the time 
made it much more general and broad before we joined the big tent.  Our mission 
statement permits multiple different orchestration tools.

Kolla is not “themed”, at least to me.  Instead it is one community with 
slightly different interests (some people work on Ansible, some on Kubernetes, 
some on containers, some on all 3, etc).  If we break that into separate 
projects with separate PTLs, those projects may end up competing with each 
other (which isn’t happening now inside Kolla).  I think competition is a good 
thing.  In this case, I am of the opinion it is high time we end the 
competition on deployment tools related to containers and get everyone working 
together rather than apart.  That is, unless those folks want to “work apart” 
which of course is their prerogative.  I wouldn’t suggest merging teams today 
that are separate that don’t have a desire to merge.  That said, Kolla is very 
warm and open to new contributors so hopefully no more new duplicate effort 
solutions are started.

Siloing the deliverables into separate teams I believe would result in the 
competition I just mentioned, and further discord between the deployment tool 
projects in the big tent.  We need consolidation around people working 
together, not division.  Division around Kolla weakens Kolla specifically and 
doesn’t help out OpenStack all that much either.

The idea of branding or themes is not really relevant to me.  Instead this is 
all about the people producing and consuming Kolla.  I’d like these folks to 
work together as much as feasible.  Breaking a sub-community apart (in this 
case Kolla) into up to 4 different communities with 4 different PTLs sounds 
wrong to me.

I hope my position is clear ☺  If not, feel free to ask any follow-up questions.

Regards
-steve


-Original Message-
From: Thierry Carrez <thie...@openstack.org>
Organization: OpenStack
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Wednesday, January 11, 2017 at 4:21 AM
To: "openstack-dev@lists.openstack.org" <openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Michał Jastrzębski wrote:
> I created CIVS poll with options we discussed. Every core member should
> get link to poll voting, if that's not the case, please let me know.

Just a quick sidenote to explain how the "big-tent" model of governance
plays in here...

In the previous project structure model, we had "programs". If you
wanted to do networking stuff, you had to join the Networking program
(neutron). If you worked on object storage, you had to join the Object
Storage program (swift). The main issue with this model is that it
prevented alternate approaches from emerging (as a program PTL could
just refuse its emergence to continue to "own" that space). It also
created weird situations where there would be multiple distinct groups
of people in a program, but a single PTL to elect to represent them all.
That created unnecessary political issues within programs and tension
around PTL election.

Part of the big-tent project structure reform was to abolish programs
and organize our work around "teams", rather than "themes". Project
teams should be strongly aligned with a single team of people that work
together. That allowed some amount of competition to emerge (we still
try to avoid "gratuitous duplication of effort"), but most importantly
made sure groups of people could "own" their work without having to
defer to an outside core team or PTL. So if you have a distinct team, it
should be its own separate project team with its own PTL. There is no
program or namespace anymore. As a bonus side-effect, it made sure teams
would not indefinitely grow, and we all know that it's difficult to grow
core teams (and trust) beyond a certain point.

This is why we have multiple packaging project teams, each specialized
in a given package orchestration mechanism, rather than have a single
"Packaging" program with a single PTL 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Thierry Carrez]

Thierry Carrez wrote:
> [...]
> The fact that you're having hard discussions in Kolla about "adding new
> deliverables" produced by distinct groups of people indicates that you
> may be using Kolla as an old-style "program" rather than as a single
> team. Why not set them up as separate project teams ? What am I missing
> here ?

Answering my own question using Michał's previous answer in the thread:

Michał Jastrzębski wrote:
> Having single Kolla umbrella has practical benefits which I would hate
> to lose quite frankly. One of which would be that Kolla is being
> evaluated by lot of different companies, and having full separation
> between projects would make navigation of a landscape harder.

That sounds like you're building a "Kolla" brand and afraid that a more
distributed project structure would hurt that... So this is going a bit
against the grain of the OpenStack project structure (which is designed
to facilitate people to openly collaborate, not really to create
sub-brands).

Also when you say companies evaluate "Kolla", in the end don't they
choose one of the kolla-* flavors to deploy, rather than "Kolla" ? It
feels like multiple projects could depend on Kolla images (which
everyone seems to be very happy with) without breaking that ?

> Another reason is single community which we value - there is no full
> separation even between kolla-ansible and kolla-k8s (ansible still
> generates config files for k8s for example), and further separation of
> projects would hurt cooperation, and I don't think we've hit situation
> when it's necessary. I'm not ready to have this discussion yet, and
> I'm personally quite opposed to this.

Wondering if this lack of separation is an artifact of the
single-project-team model you picked, rather than a reason to keep it...
Stronger contracts and proper decomposition of roles sounds like a
worthwhile goal ?

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Thierry Carrez]

Michał Jastrzębski wrote:
> I created CIVS poll with options we discussed. Every core member should
> get link to poll voting, if that's not the case, please let me know.

Just a quick sidenote to explain how the "big-tent" model of governance
plays in here...

In the previous project structure model, we had "programs". If you
wanted to do networking stuff, you had to join the Networking program
(neutron). If you worked on object storage, you had to join the Object
Storage program (swift). The main issue with this model is that it
prevented alternate approaches from emerging (as a program PTL could
just refuse its emergence to continue to "own" that space). It also
created weird situations where there would be multiple distinct groups
of people in a program, but a single PTL to elect to represent them all.
That created unnecessary political issues within programs and tension
around PTL election.

Part of the big-tent project structure reform was to abolish programs
and organize our work around "teams", rather than "themes". Project
teams should be strongly aligned with a single team of people that work
together. That allowed some amount of competition to emerge (we still
try to avoid "gratuitous duplication of effort"), but most importantly
made sure groups of people could "own" their work without having to
defer to an outside core team or PTL. So if you have a distinct team, it
should be its own separate project team with its own PTL. There is no
program or namespace anymore. As a bonus side-effect, it made sure teams
would not indefinitely grow, and we all know that it's difficult to grow
core teams (and trust) beyond a certain point.

This is why we have multiple packaging project teams, each specialized
in a given package orchestration mechanism, rather than have a single
"Packaging" program with a single PTL and Ansible / Puppet / Chef
fighting in elections to get their man at the helm. This is why the
Storlets team, while deeply related to Swift and in very good
collaboration terms with them, was set up as a separate project team.
Different people, different team.

The fact that you're having hard discussions in Kolla about "adding new
deliverables" produced by distinct groups of people indicates that you
may be using Kolla as an old-style "program" rather than as a single
team. Why not set them up as separate project teams ? What am I missing
here ?

-- 
Thierry Carrez (ttx)

__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Michał Jastrzębski]

I created CIVS poll with options we discussed. Every core member should get
link to poll voting, if that's not the case, please let me know.

On 5 January 2017 at 19:07, Britt Houser (bhouser) <bhou...@cisco.com>
wrote:

> I think you’re giving a great example of my point that we’re not yet at
> the stage where we can say, “Any tool should be able to deploy kolla
> containers”.  Right?
>
>
>
> *From: *Pete Birley <pete@port.direct>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, January 5, 2017 at 9:06 PM
>
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [tc][kolla] Adding new deliverables
>
>
>
> I'll reply to Britts comments, and then duck out, unless explicitly asked
> back, as I don't want to (totally) railroad this conversation:
>
>
>
> The Kolla containers entry-point is a great example of how the field have
> moved on. While it was initially required, in the Kkubernetes world the
> Kolla ABI is actually more of a hindrance than help, as it makes the
> containers much more of a 'black-box' to use. In the other Openstack on
> Kubernetes projects I contribute to, and my own independent work, in we
> actually just define the entry point to the container directly in the k8s
> manifest and make no use of Kolla's entry point and config mechanisms,
> either running another 'init' container to build and bind mount the
> configuration (Harbor), or use Kubernetes configmap object to achieve the
> same result (Openstack Helm). It would be perfectly possible for Kolla
> Ansible (and indeed Salt) to take a similar approach - meaning that rather
> maintaining an ABI that works for all platforms, Kolla would be free to
> just ensure that the required binaries were present in images.
>
>
>
> I agree that this cannot happen overnight, but think that when appropriate
> we should take stock of where we are and how to plot a course that lets all
> of our projects flourish without competing for resources, or being so
> entwined that we become technically paralyzed and overloaded.
>
> Sorry, Sam and Michal! You can have your thread back now :)
>
>
>
> On Fri, Jan 6, 2017 at 1:17 AM, Britt Houser (bhouser) <bhou...@cisco.com>
> wrote:
>
> I think both Pete and Steve make great points and it should be our long
> term vision.  However, I lean more with Michael that we should make that a
> separate discussion, and it’s probably better done further down the road.
> Yes, Kolla containers have come a long way, and the ABI has been stable for
> awhile, but the vast majority of that “for awhile” was with a single
> deployment tool: ansible.  Now we have kolla-k8s and kolla-salt.  Neither
> one is fully featured yet as ansible, which to me means I don’t think we
> can say for sure that ABI won’t need to change as we try to support many
> deployment tools.  (Someone remind me, didn’t kolla-mesos change the ABI?)
> Anyway, the point is I don’t think we’re at a point of maturity to be
> certain the ABI won’t need changing.  When we have 2-3 deployment tools
> with enough feature parity to say, “Any tool should be able to deploy kolla
> containers” then I think it make sense to have that discussion.  I just
> don’t think we’re there yet.  And until the point, changes to the ABI will
> be quite painful if each project is in outside of the kolla umbrella, IMHO.
>
>
>
> Thx,
>
> britt
>
>
>
> *From: *Pete Birley <pete@port.direct>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, January 5, 2017 at 6:47 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [tc][kolla] Adding new deliverables
>
>
>
> Also coming from the perspective of a Kolla-Kubernetes contributor, I am
> worried about the scope that Kolla is extending itself to.
>
>
>
> Moving from a single repo to multiple repo's has made the situation much
> better, but by operating under a single umbrella I feel that we may
> potentially be significantly limiting the potential for each deliverable.
> Alex Schultz, Steve and Sam raise some good points here.
>
>
>
> The interdependency between the projects is causing issues, the current
> reliance that Kolla-Kubernetes has on Kolla-ansible is both undesirable and
> unsustainable in my opinion. This is both because it limits the flexibility
> that we have as Kolla-Kubernetes developers, but also becaus

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Britt Houser (bhouser)]

I think you’re giving a great example of my point that we’re not yet at the 
stage where we can say, “Any tool should be able to deploy kolla containers”.  
Right?

From: Pete Birley <pete@port.direct>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, January 5, 2017 at 9:06 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

I'll reply to Britts comments, and then duck out, unless explicitly asked back, 
as I don't want to (totally) railroad this conversation:

The Kolla containers entry-point is a great example of how the field have moved 
on. While it was initially required, in the Kkubernetes world the Kolla ABI is 
actually more of a hindrance than help, as it makes the containers much more of 
a 'black-box' to use. In the other Openstack on Kubernetes projects I 
contribute to, and my own independent work, in we actually just define the 
entry point to the container directly in the k8s manifest and make no use of 
Kolla's entry point and config mechanisms, either running another 'init' 
container to build and bind mount the configuration (Harbor), or use Kubernetes 
configmap object to achieve the same result (Openstack Helm). It would be 
perfectly possible for Kolla Ansible (and indeed Salt) to take a similar 
approach - meaning that rather maintaining an ABI that works for all platforms, 
Kolla would be free to just ensure that the required binaries were present in 
images.

I agree that this cannot happen overnight, but think that when appropriate we 
should take stock of where we are and how to plot a course that lets all of our 
projects flourish without competing for resources, or being so entwined that we 
become technically paralyzed and overloaded.

Sorry, Sam and Michal! You can have your thread back now :)

On Fri, Jan 6, 2017 at 1:17 AM, Britt Houser (bhouser) 
<bhou...@cisco.com<mailto:bhou...@cisco.com>> wrote:
I think both Pete and Steve make great points and it should be our long term 
vision.  However, I lean more with Michael that we should make that a separate 
discussion, and it’s probably better done further down the road.  Yes, Kolla 
containers have come a long way, and the ABI has been stable for awhile, but 
the vast majority of that “for awhile” was with a single deployment tool: 
ansible.  Now we have kolla-k8s and kolla-salt.  Neither one is fully featured 
yet as ansible, which to me means I don’t think we can say for sure that ABI 
won’t need to change as we try to support many deployment tools.  (Someone 
remind me, didn’t kolla-mesos change the ABI?)  Anyway, the point is I don’t 
think we’re at a point of maturity to be certain the ABI won’t need changing.  
When we have 2-3 deployment tools with enough feature parity to say, “Any tool 
should be able to deploy kolla containers” then I think it make sense to have 
that discussion.  I just don’t think we’re there yet.  And until the point, 
changes to the ABI will be quite painful if each project is in outside of the 
kolla umbrella, IMHO.

Thx,
britt

From: Pete Birley <pete@port.direct>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, January 5, 2017 at 6:47 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Also coming from the perspective of a Kolla-Kubernetes contributor, I am 
worried about the scope that Kolla is extending itself to.

Moving from a single repo to multiple repo's has made the situation much 
better, but by operating under a single umbrella I feel that we may potentially 
be significantly limiting the potential for each deliverable. Alex Schultz, 
Steve and Sam raise some good points here.

The interdependency between the projects is causing issues, the current 
reliance that Kolla-Kubernetes has on Kolla-ansible is both undesirable and 
unsustainable in my opinion. This is both because it limits the flexibility 
that we have as Kolla-Kubernetes developers, but also because it places burden 
and rigidity on Kolla-Ansible. This will ultimately prevent both projects from 
being able to take advantage of the capabilities offered to them by the 
deployment mechanism they use.

Like Steve, I don't think the addition of Kolla-aSlt should affect me, and as a 
result don't feel I should have any say in the project. That said, I'd really 
like to see it happen in one form or another - as having a wide variety of 
complementary projects and tooling for OpenStack deployment can only be a good 
thing for the community if correctly managed

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Pete Birley]

I'll reply to Britts comments, and then duck out, unless explicitly asked
back, as I don't want to (totally) railroad this conversation:

The Kolla containers entry-point is a great example of how the field have
moved on. While it was initially required, in the Kkubernetes world the
Kolla ABI is actually more of a hindrance than help, as it makes the
containers much more of a 'black-box' to use. In the other Openstack on
Kubernetes projects I contribute to, and my own independent work, in we
actually just define the entry point to the container directly in the k8s
manifest and make no use of Kolla's entry point and config mechanisms,
either running another 'init' container to build and bind mount the
configuration (Harbor), or use Kubernetes configmap object to achieve the
same result (Openstack Helm). It would be perfectly possible for Kolla
Ansible (and indeed Salt) to take a similar approach - meaning that rather
maintaining an ABI that works for all platforms, Kolla would be free to
just ensure that the required binaries were present in images.

I agree that this cannot happen overnight, but think that when appropriate
we should take stock of where we are and how to plot a course that lets all
of our projects flourish without competing for resources, or being so
entwined that we become technically paralyzed and overloaded.

Sorry, Sam and Michal! You can have your thread back now :)

On Fri, Jan 6, 2017 at 1:17 AM, Britt Houser (bhouser) <bhou...@cisco.com>
wrote:

> I think both Pete and Steve make great points and it should be our long
> term vision.  However, I lean more with Michael that we should make that a
> separate discussion, and it’s probably better done further down the road.
> Yes, Kolla containers have come a long way, and the ABI has been stable for
> awhile, but the vast majority of that “for awhile” was with a single
> deployment tool: ansible.  Now we have kolla-k8s and kolla-salt.  Neither
> one is fully featured yet as ansible, which to me means I don’t think we
> can say for sure that ABI won’t need to change as we try to support many
> deployment tools.  (Someone remind me, didn’t kolla-mesos change the ABI?)
> Anyway, the point is I don’t think we’re at a point of maturity to be
> certain the ABI won’t need changing.  When we have 2-3 deployment tools
> with enough feature parity to say, “Any tool should be able to deploy kolla
> containers” then I think it make sense to have that discussion.  I just
> don’t think we’re there yet.  And until the point, changes to the ABI will
> be quite painful if each project is in outside of the kolla umbrella, IMHO.
>
>
>
> Thx,
>
> britt
>
>
>
> *From: *Pete Birley <pete@port.direct>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Thursday, January 5, 2017 at 6:47 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [tc][kolla] Adding new deliverables
>
>
>
> Also coming from the perspective of a Kolla-Kubernetes contributor, I am
> worried about the scope that Kolla is extending itself to.
>
>
>
> Moving from a single repo to multiple repo's has made the situation much
> better, but by operating under a single umbrella I feel that we may
> potentially be significantly limiting the potential for each deliverable.
> Alex Schultz, Steve and Sam raise some good points here.
>
>
>
> The interdependency between the projects is causing issues, the current
> reliance that Kolla-Kubernetes has on Kolla-ansible is both undesirable and
> unsustainable in my opinion. This is both because it limits the flexibility
> that we have as Kolla-Kubernetes developers, but also because it places
> burden and rigidity on Kolla-Ansible. This will ultimately prevent both
> projects from being able to take advantage of the capabilities offered to
> them by the deployment mechanism they use.
>
>
>
> Like Steve, I don't think the addition of Kolla-aSlt should affect me, and
> as a result don't feel I should have any say in the project. That said, I'd
> really like to see it happen in one form or another - as having a wide
> variety of complementary projects and tooling for OpenStack deployment can
> only be a good thing for the community if correctly managed.
>
>
>
> When Kolla started it was very experimental, containers (In their modern
> form) were a relatively new construct, and it took on the audacious task of
> trying to package and deploy OpenStack using the tooling that was available
> at the time. I really feel that this effort has succeeded admirably, and
> conversations like this are a result of that. Kolla is one of the most
> active projec

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Britt Houser (bhouser)]

I think both Pete and Steve make great points and it should be our long term 
vision.  However, I lean more with Michael that we should make that a separate 
discussion, and it’s probably better done further down the road.  Yes, Kolla 
containers have come a long way, and the ABI has been stable for awhile, but 
the vast majority of that “for awhile” was with a single deployment tool: 
ansible.  Now we have kolla-k8s and kolla-salt.  Neither one is fully featured 
yet as ansible, which to me means I don’t think we can say for sure that ABI 
won’t need to change as we try to support many deployment tools.  (Someone 
remind me, didn’t kolla-mesos change the ABI?)  Anyway, the point is I don’t 
think we’re at a point of maturity to be certain the ABI won’t need changing.  
When we have 2-3 deployment tools with enough feature parity to say, “Any tool 
should be able to deploy kolla containers” then I think it make sense to have 
that discussion.  I just don’t think we’re there yet.  And until the point, 
changes to the ABI will be quite painful if each project is in outside of the 
kolla umbrella, IMHO.

Thx,
britt

From: Pete Birley <pete@port.direct>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Date: Thursday, January 5, 2017 at 6:47 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [tc][kolla] Adding new deliverables

Also coming from the perspective of a Kolla-Kubernetes contributor, I am 
worried about the scope that Kolla is extending itself to.

Moving from a single repo to multiple repo's has made the situation much 
better, but by operating under a single umbrella I feel that we may potentially 
be significantly limiting the potential for each deliverable. Alex Schultz, 
Steve and Sam raise some good points here.

The interdependency between the projects is causing issues, the current 
reliance that Kolla-Kubernetes has on Kolla-ansible is both undesirable and 
unsustainable in my opinion. This is both because it limits the flexibility 
that we have as Kolla-Kubernetes developers, but also because it places burden 
and rigidity on Kolla-Ansible. This will ultimately prevent both projects from 
being able to take advantage of the capabilities offered to them by the 
deployment mechanism they use.

Like Steve, I don't think the addition of Kolla-aSlt should affect me, and as a 
result don't feel I should have any say in the project. That said, I'd really 
like to see it happen in one form or another - as having a wide variety of 
complementary projects and tooling for OpenStack deployment can only be a good 
thing for the community if correctly managed.

When Kolla started it was very experimental, containers (In their modern form) 
were a relatively new construct, and it took on the audacious task of trying to 
package and deploy OpenStack using the tooling that was available at the time. 
I really feel that this effort has succeeded admirably, and conversations like 
this are a result of that. Kolla is one of the most active projects in 
OpenStack, with two deployment mechanisms being developed currently, and 
hopefully to increase soon with a salt based deployment and potentially even 
more on the horizon.

With this in mind, I return to my original point and wonder if we may be better 
moving from our current structure of Kolla-deploy(x) to deploy(x)-Kolla and 
redefine the governance of these deliverables, turning them into freestanding 
projects. I think this would offer several potential advantages, as it would 
allow teams to form tighter bonds with the tools and communities they use (ie 
Kubernetes/Helm, Ansible or Salt). This would also make it easier for these 
projects to use upstream components where available (eg Ceph, RabbitMQ, and 
MariaDB) which are (and should be) in many cases better than the artifacts we 
can produce. To this end, I have been working with the Ceph community to get 
their Kubernetes Helm implementation to the point where we can use it for our 
own work, and would love to see more of this. It benefits not only us by 
offloading support to the upstream project, but gives them a vested interest in 
supporting us and also helps provide better quality tooling for the entire open 
source ecosystem.

This should also allow Kolla itself to become much more streamlined, and 
focused simply on producing docker containers for consumption by the community, 
and make the artifacts produced potentially much less opinionated and more 
attractive to other projects. And being honest, I have a real desire for this 
activity to eventually be taken on by the relevant OpenStack projects 
themselves - and would love to see Kolla help develop a framework that would 
allow projects to take ownership of the containerisation of their output.

Sorry for such a long email - but this seems like a good oppo

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Pete Birley]

Also coming from the perspective of a Kolla-Kubernetes contributor, I am
worried about the scope that Kolla is extending itself to.

Moving from a single repo to multiple repo's has made the situation much
better, but by operating under a single umbrella I feel that we may
potentially be significantly limiting the potential for each deliverable.
Alex Schultz, Steve and Sam raise some good points here.

The interdependency between the projects is causing issues, the current
reliance that Kolla-Kubernetes has on Kolla-ansible is both undesirable and
unsustainable in my opinion. This is both because it limits the flexibility
that we have as Kolla-Kubernetes developers, but also because it places
burden and rigidity on Kolla-Ansible. This will ultimately prevent both
projects from being able to take advantage of the capabilities offered to
them by the deployment mechanism they use.

Like Steve, I don't think the addition of Kolla-aSlt should affect me, and
as a result don't feel I should have any say in the project. That said, I'd
really like to see it happen in one form or another - as having a wide
variety of complementary projects and tooling for OpenStack deployment can
only be a good thing for the community if correctly managed.

When Kolla started it was very experimental, containers (In their modern
form) were a relatively new construct, and it took on the audacious task of
trying to package and deploy OpenStack using the tooling that was available
at the time. I really feel that this effort has succeeded admirably, and
conversations like this are a result of that. Kolla is one of the most
active projects in OpenStack, with two deployment mechanisms being
developed currently, and hopefully to increase soon with a salt based
deployment and potentially even more on the horizon.

With this in mind, I return to my original point and wonder if we may be
better moving from our current structure of Kolla-deploy(x) to
deploy(x)-Kolla and redefine the governance of these deliverables, turning
them into freestanding projects. I think this would offer several potential
advantages, as it would allow teams to form tighter bonds with the tools
and communities they use (ie Kubernetes/Helm, Ansible or Salt). This would
also make it easier for these projects to use upstream components where
available (eg Ceph, RabbitMQ, and MariaDB) which are (and should be) in
many cases better than the artifacts we can produce. To this end, I have
been working with the Ceph community to get their Kubernetes Helm
implementation to the point where we can use it for our own work, and would
love to see more of this. It benefits not only us by offloading support to
the upstream project, but gives them a vested interest in supporting us and
also helps provide better quality tooling for the entire open source
ecosystem.

This should also allow Kolla itself to become much more streamlined, and
focused simply on producing docker containers for consumption by the
community, and make the artifacts produced potentially much less
opinionated and more attractive to other projects. And being honest, I have
a real desire for this activity to eventually be taken on by the relevant
OpenStack projects themselves - and would love to see Kolla help develop a
framework that would allow projects to take ownership of the
containerisation of their output.

Sorry for such a long email - but this seems like a good opportunity to
raise some of these issues that have been on my mind. In summary, if it
doesn't affect me then I wish a Salt based Kolla deployment the best of
success and hope to see the project prosper so that we as OpenStack
developers can all share from the increased experience and opportunities
growing the community offers.


On Thu, Jan 5, 2017 at 9:43 PM, Steve Wilkerson 
wrote:

> There are some interesting points in this topic.  I agree entirely with
> Sam Yaple.  It does not make sense to me to have kolla-ansible and
> kolla-kubernetes cores involved with the introduction of a new deliverable
> under the kolla umbrella.  A new deliverable (read: project, really) should
> not rely on a separate project to ratify its existence.  I feel this is
> dangerous.  I also feel looking at the different deployment methodologies
> scoped under the kolla project as competition or rivalry is folly.  I'm
> honestly a bit concerned about how broad the scope of the project kolla has
> become.  I think the conversation of separating the deployment projects
> from the kolla umbrella is a conversation worth having at some point.
>
> The repo split was a step in the right direction, but currently the
> deliverables (4, if kolla-salt becomes a thing) are sharing a single PTL, a
> single IRC channel, and a single IRC weekly meeting.  This has the
> potential of introducing a significant amount of overhead for the
> overarching project as a whole.  What happens if kolla-puppet becomes a
> thing?  What if kolla-mesos was still about?  I think 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steve Wilkerson]

There are some interesting points in this topic.  I agree entirely with Sam
Yaple.  It does not make sense to me to have kolla-ansible and
kolla-kubernetes cores involved with the introduction of a new deliverable
under the kolla umbrella.  A new deliverable (read: project, really) should
not rely on a separate project to ratify its existence.  I feel this is
dangerous.  I also feel looking at the different deployment methodologies
scoped under the kolla project as competition or rivalry is folly.  I'm
honestly a bit concerned about how broad the scope of the project kolla has
become.  I think the conversation of separating the deployment projects
from the kolla umbrella is a conversation worth having at some point.

The repo split was a step in the right direction, but currently the
deliverables (4, if kolla-salt becomes a thing) are sharing a single PTL, a
single IRC channel, and a single IRC weekly meeting.  This has the
potential of introducing a significant amount of overhead for the
overarching project as a whole.  What happens if kolla-puppet becomes a
thing?  What if kolla-mesos was still about?  I think we can all agree this
gets out of hand quickly.

Yes, people are religious about the tools they use, and deployment tools
are no different.  I think scoping them all under the same umbrella project
is a mistake in the long term.  The folks that want to focus on Ansible
should be able to focus wholly on Ansible with like-minded folks, same for
Salt, same for whatever.  Having them remain together for the sake of
sharing a name isn't sustainable in the long term -- let each do what they
do well.  As far as being able to talk and share experiences in deployments
or whatever, let's not act as if IRC channels have walls we can't reach
across.  As part of the kolla-kubernetes community, it's imperative that I
can reach across the gap to work with people in the Helm and Kubernetes
community.  If the deployment tools existed separately, there's nothing
stopping them from asking either.

But in regards to the question, if kolla-salt is to be a thing, I think the
PTL and the kolla team proper can decide that.  As a contributor for
kolla-kubernetes, it does not and should not affect me.

On Thu, Jan 5, 2017 at 3:14 PM, Doug Hellmann  wrote:

> Excerpts from Michał Jastrzębski's message of 2017-01-05 11:45:49 -0800:
> > I think total separation of projects would require much larger
> > discussion in community. Currently we agreed on having kolla-ansible
> > and kolla-k8s to be deliverables under kolla umbrella from historical
> > reasons. Also I don't agree that there is "little or no overlap" in
> > teams, in fact there is ton of overlap, just not 100%. Many
> > contributors (myself included) jump between deliverables today.
>
> OK, that's good to know. It wasn't clear from some of the initial
> messages in this thread, which seemed to imply otherwise.
>
> Doug
>
> __
> 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Doug Hellmann]

Excerpts from Michał Jastrzębski's message of 2017-01-05 11:45:49 -0800:
> I think total separation of projects would require much larger
> discussion in community. Currently we agreed on having kolla-ansible
> and kolla-k8s to be deliverables under kolla umbrella from historical
> reasons. Also I don't agree that there is "little or no overlap" in
> teams, in fact there is ton of overlap, just not 100%. Many
> contributors (myself included) jump between deliverables today.

OK, that's good to know. It wasn't clear from some of the initial
messages in this thread, which seemed to imply otherwise.

Doug

__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

On Thu, Jan 5, 2017 at 7:42 PM, Doug Hellmann  wrote:

> Excerpts from Sam Yaple's message of 2017-01-05 18:22:54 +:
> > On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann 
> wrote:
> >
> > > Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> > > > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley 
> > > wrote:
> > > >
> > > > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > > > > [...]
> > > > > > I do feel this is slightly different than whats described. Since
> it
> > > is
> > > > > not
> > > > > > unrelated services, but rather, for lack of a better word,
> competing
> > > > > > services. To my knowledge infra doesn't have several service
> doing
> > > the
> > > > > same
> > > > > > job with different core teams (though I could be wrong).
> > > > >
> > > > > True, though I do find it an interesting point of view that helping
> > > > > Kolla support multiple and diverse configuration management and
> > > > > automation ecosystems is a "competition" rather than merely
> > > > > extending the breadth of the project as a whole.
> > > > >
> > > >
> > > > Yea I computer good, but I am no wordsmith. Perhaps 'friendly
> rivalry'? I
> > > > expect these different deploy tools to bring new techniques that can
> then
> > > > be reapplied to kolla-ansible and kolla-kubernetes to help out
> everyone.
> > >
> > > I'm still curious to understand why, if the teams building those
> > > different things have little or no overlap in membership, they need to
> > > be part of "kolla" and not just part of the larger OpenStack? Why build
> > > a separate project hierarchy instead of keeping things flat?
> > >
> > > Do I misunderstand the situation?
> > >
> > > You absolutely do not misunderstand the situation. It is a very valid
> > question, one to which I do not have a satisfying answer. I can say that
> it
> > has been the intention since I started work on the ansible bits of kolla
> to
> > have separate repos for the deployment parts. That grew to having several
> > different deployment tools in the future and I don't think anyone really
> > stopped to think that building this hierarchy isn't necessarily the right
> > thing to do. It certainly isn't a required thing to do.
> >
> > With the separation of ansible from the main kolla repo, the kolla repo
> now
> > becomes a consumable much like the relationship keystone and glance.
> >
> > The only advantage I can really think of at the moment is to reuse the
> > Kolla name and community when starting a new project, but that may not be
> > as advantageous as I initially thought. By my own admission, why do these
> > other projects care about a different orchestration tool.
> >
> > So in your estimation Doug, do you feel kolla-salt would be better served
> > as a new project in it's own right? As well as future orchestration tools
> > using Kolla container images?
>
> I don't know enough about the situation to say for sure, and I'll
> leave it up to the people involved, but I thought I should raise
> the option as a way to ease up some of the friction.
>
> Our team structure is really supposed to be organized around groups
> of people rather than groups of things.  The fact that there's some
> negotiation going on to decide who needs to (or gets to) have a say
> in when new deliverables are added, with some people saying they
> don't want to have to vote or that others shouldn't have a vote,
> just makes it seem to me that we're trying to force a fit where it
> would be simpler to establish separate teams.
>
> There may be some common space for shared tools, and it sounds like
> that's how things started out. But not maybe it's time to rethink
> that?
>
> This is definitely the case. Shared tooling. In the case of kolla-k8s and
kolla-ansible sharing the configs, this has broken kolla-k8s many times.
Perhaps the right decision long term is identifying all the needed pieces
that Kolla would be sharing and centralizing them rather than building this
Kolla hierarchy of projects forcing Kolla more into what resembles a
benevolent dictator model for all underlying deployment projects.

Thanks,
SamYaple

> Doug
>
> >
> > Thanks,
> > SamYaple
> >
> > > Doug
> > >
> > > >
> > > > Thanks,
> > > > SamYaple
> > > >
> > > > > --
> > > > > Jeremy Stanley
> > > > >
> > > > > 
> > > __
> > > > > 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
> > > 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

On Thu, Jan 5, 2017 at 7:45 PM, Michał Jastrzębski  wrote:

> I think total separation of projects would require much larger
> discussion in community. Currently we agreed on having kolla-ansible
> and kolla-k8s to be deliverables under kolla umbrella from historical
> reasons. Also I don't agree that there is "little or no overlap" in
> teams, in fact there is ton of overlap, just not 100%. Many
> contributors (myself included) jump between deliverables today.
>
> Having single Kolla umbrella has practical benefits which I would hate
> to lose quite frankly. One of which would be that Kolla is being
> evaluated by lot of different companies, and having full separation
> between projects would make navigation of a landscape harder. Another
> reason is single community which we value - there is no full
> separation even between kolla-ansible and kolla-k8s (ansible still
> generates config files for k8s for example), and further separation of
> projects would hurt cooperation, and I don't think we've hit situation
> when it's necessary. I'm not ready to have this discussion yet, and
> I'm personally quite opposed to this.
>
> If kolla-salt would like to be first completely separate project,
> there is nothing we can (or want) to do to stop it, but I wouldn't
> like to see this being pushed. Having special beast isn't great, and
> moving kolla-ansible and kolla-k8s out of kolla umbrella is revolution
> I don't want to rush. I'd rather figure out process to accept
> kolla-salt (and following projects) to kolla umbrella and have this
> discussion later, when we actually hit community scale issues.
>

I don't think moving kolla-ansible or kolla-k8s out of the kolla namespace
was being suggested. If I implied that, it was not intended. That said,
with Doug's comments, I am not sure it makes sense to continue building a
Kolla deployment hierarchy. I would ask what the benefit of having
kolla-salt or kolla-puppet would be?

It is just a point that hasn't been discussed or considered up until now.
We had all just assumed kolla-salt and kolla-puppet and kolla-chef would be
a thing, but would there be a benefit to sitting under the kolla namespace?
I am not sure what those benefits are.

Thanks,
SamYaple


> Cheers,
> Michal
>
>
> On 5 January 2017 at 10:22, Sam Yaple  wrote:
> > On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann 
> wrote:
> >>
> >> Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> >> > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley 
> >> > wrote:
> >> >
> >> > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> >> > > [...]
> >> > > > I do feel this is slightly different than whats described. Since
> it
> >> > > > is
> >> > > not
> >> > > > unrelated services, but rather, for lack of a better word,
> competing
> >> > > > services. To my knowledge infra doesn't have several service doing
> >> > > > the
> >> > > same
> >> > > > job with different core teams (though I could be wrong).
> >> > >
> >> > > True, though I do find it an interesting point of view that helping
> >> > > Kolla support multiple and diverse configuration management and
> >> > > automation ecosystems is a "competition" rather than merely
> >> > > extending the breadth of the project as a whole.
> >> > >
> >> >
> >> > Yea I computer good, but I am no wordsmith. Perhaps 'friendly
> rivalry'?
> >> > I
> >> > expect these different deploy tools to bring new techniques that can
> >> > then
> >> > be reapplied to kolla-ansible and kolla-kubernetes to help out
> everyone.
> >>
> >> I'm still curious to understand why, if the teams building those
> >> different things have little or no overlap in membership, they need to
> >> be part of "kolla" and not just part of the larger OpenStack? Why build
> >> a separate project hierarchy instead of keeping things flat?
> >>
> >> Do I misunderstand the situation?
> >>
> > You absolutely do not misunderstand the situation. It is a very valid
> > question, one to which I do not have a satisfying answer. I can say that
> it
> > has been the intention since I started work on the ansible bits of kolla
> to
> > have separate repos for the deployment parts. That grew to having several
> > different deployment tools in the future and I don't think anyone really
> > stopped to think that building this hierarchy isn't necessarily the right
> > thing to do. It certainly isn't a required thing to do.
> >
> > With the separation of ansible from the main kolla repo, the kolla repo
> now
> > becomes a consumable much like the relationship keystone and glance.
> >
> > The only advantage I can really think of at the moment is to reuse the
> Kolla
> > name and community when starting a new project, but that may not be as
> > advantageous as I initially thought. By my own admission, why do these
> other
> > projects care about a different orchestration tool.
> >
> > So in your estimation Doug, do you feel kolla-salt would 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Michał Jastrzębski]

I think total separation of projects would require much larger
discussion in community. Currently we agreed on having kolla-ansible
and kolla-k8s to be deliverables under kolla umbrella from historical
reasons. Also I don't agree that there is "little or no overlap" in
teams, in fact there is ton of overlap, just not 100%. Many
contributors (myself included) jump between deliverables today.

Having single Kolla umbrella has practical benefits which I would hate
to lose quite frankly. One of which would be that Kolla is being
evaluated by lot of different companies, and having full separation
between projects would make navigation of a landscape harder. Another
reason is single community which we value - there is no full
separation even between kolla-ansible and kolla-k8s (ansible still
generates config files for k8s for example), and further separation of
projects would hurt cooperation, and I don't think we've hit situation
when it's necessary. I'm not ready to have this discussion yet, and
I'm personally quite opposed to this.

If kolla-salt would like to be first completely separate project,
there is nothing we can (or want) to do to stop it, but I wouldn't
like to see this being pushed. Having special beast isn't great, and
moving kolla-ansible and kolla-k8s out of kolla umbrella is revolution
I don't want to rush. I'd rather figure out process to accept
kolla-salt (and following projects) to kolla umbrella and have this
discussion later, when we actually hit community scale issues.

Cheers,
Michal


On 5 January 2017 at 10:22, Sam Yaple  wrote:
> On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann  wrote:
>>
>> Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
>> > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley 
>> > wrote:
>> >
>> > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
>> > > [...]
>> > > > I do feel this is slightly different than whats described. Since it
>> > > > is
>> > > not
>> > > > unrelated services, but rather, for lack of a better word, competing
>> > > > services. To my knowledge infra doesn't have several service doing
>> > > > the
>> > > same
>> > > > job with different core teams (though I could be wrong).
>> > >
>> > > True, though I do find it an interesting point of view that helping
>> > > Kolla support multiple and diverse configuration management and
>> > > automation ecosystems is a "competition" rather than merely
>> > > extending the breadth of the project as a whole.
>> > >
>> >
>> > Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'?
>> > I
>> > expect these different deploy tools to bring new techniques that can
>> > then
>> > be reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
>>
>> I'm still curious to understand why, if the teams building those
>> different things have little or no overlap in membership, they need to
>> be part of "kolla" and not just part of the larger OpenStack? Why build
>> a separate project hierarchy instead of keeping things flat?
>>
>> Do I misunderstand the situation?
>>
> You absolutely do not misunderstand the situation. It is a very valid
> question, one to which I do not have a satisfying answer. I can say that it
> has been the intention since I started work on the ansible bits of kolla to
> have separate repos for the deployment parts. That grew to having several
> different deployment tools in the future and I don't think anyone really
> stopped to think that building this hierarchy isn't necessarily the right
> thing to do. It certainly isn't a required thing to do.
>
> With the separation of ansible from the main kolla repo, the kolla repo now
> becomes a consumable much like the relationship keystone and glance.
>
> The only advantage I can really think of at the moment is to reuse the Kolla
> name and community when starting a new project, but that may not be as
> advantageous as I initially thought. By my own admission, why do these other
> projects care about a different orchestration tool.
>
> So in your estimation Doug, do you feel kolla-salt would be better served as
> a new project in it's own right? As well as future orchestration tools using
> Kolla container images?
>
> Thanks,
> SamYaple
>>
>> Doug
>>
>> >
>> > Thanks,
>> > SamYaple
>> >
>> > > --
>> > > Jeremy Stanley
>> > >
>> > >
>> > > __
>> > > 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
>
>
>
> 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Doug Hellmann]

Excerpts from Sam Yaple's message of 2017-01-05 18:22:54 +:
> On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann  wrote:
> 
> > Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> > > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley 
> > wrote:
> > >
> > > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > > > [...]
> > > > > I do feel this is slightly different than whats described. Since it
> > is
> > > > not
> > > > > unrelated services, but rather, for lack of a better word, competing
> > > > > services. To my knowledge infra doesn't have several service doing
> > the
> > > > same
> > > > > job with different core teams (though I could be wrong).
> > > >
> > > > True, though I do find it an interesting point of view that helping
> > > > Kolla support multiple and diverse configuration management and
> > > > automation ecosystems is a "competition" rather than merely
> > > > extending the breadth of the project as a whole.
> > > >
> > >
> > > Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
> > > expect these different deploy tools to bring new techniques that can then
> > > be reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
> >
> > I'm still curious to understand why, if the teams building those
> > different things have little or no overlap in membership, they need to
> > be part of "kolla" and not just part of the larger OpenStack? Why build
> > a separate project hierarchy instead of keeping things flat?
> >
> > Do I misunderstand the situation?
> >
> > You absolutely do not misunderstand the situation. It is a very valid
> question, one to which I do not have a satisfying answer. I can say that it
> has been the intention since I started work on the ansible bits of kolla to
> have separate repos for the deployment parts. That grew to having several
> different deployment tools in the future and I don't think anyone really
> stopped to think that building this hierarchy isn't necessarily the right
> thing to do. It certainly isn't a required thing to do.
> 
> With the separation of ansible from the main kolla repo, the kolla repo now
> becomes a consumable much like the relationship keystone and glance.
> 
> The only advantage I can really think of at the moment is to reuse the
> Kolla name and community when starting a new project, but that may not be
> as advantageous as I initially thought. By my own admission, why do these
> other projects care about a different orchestration tool.
> 
> So in your estimation Doug, do you feel kolla-salt would be better served
> as a new project in it's own right? As well as future orchestration tools
> using Kolla container images?

I don't know enough about the situation to say for sure, and I'll
leave it up to the people involved, but I thought I should raise
the option as a way to ease up some of the friction.

Our team structure is really supposed to be organized around groups
of people rather than groups of things.  The fact that there's some
negotiation going on to decide who needs to (or gets to) have a say
in when new deliverables are added, with some people saying they
don't want to have to vote or that others shouldn't have a vote,
just makes it seem to me that we're trying to force a fit where it
would be simpler to establish separate teams.

There may be some common space for shared tools, and it sounds like
that's how things started out. But not maybe it's time to rethink
that?

Doug

> 
> Thanks,
> SamYaple
> 
> > Doug
> >
> > >
> > > Thanks,
> > > SamYaple
> > >
> > > > --
> > > > Jeremy Stanley
> > > >
> > > > 
> > __
> > > > 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

On Thu, Jan 5, 2017 at 6:12 PM, Doug Hellmann  wrote:

> Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> > On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley 
> wrote:
> >
> > > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > > [...]
> > > > I do feel this is slightly different than whats described. Since it
> is
> > > not
> > > > unrelated services, but rather, for lack of a better word, competing
> > > > services. To my knowledge infra doesn't have several service doing
> the
> > > same
> > > > job with different core teams (though I could be wrong).
> > >
> > > True, though I do find it an interesting point of view that helping
> > > Kolla support multiple and diverse configuration management and
> > > automation ecosystems is a "competition" rather than merely
> > > extending the breadth of the project as a whole.
> > >
> >
> > Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
> > expect these different deploy tools to bring new techniques that can then
> > be reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
>
> I'm still curious to understand why, if the teams building those
> different things have little or no overlap in membership, they need to
> be part of "kolla" and not just part of the larger OpenStack? Why build
> a separate project hierarchy instead of keeping things flat?
>
> Do I misunderstand the situation?
>
> You absolutely do not misunderstand the situation. It is a very valid
question, one to which I do not have a satisfying answer. I can say that it
has been the intention since I started work on the ansible bits of kolla to
have separate repos for the deployment parts. That grew to having several
different deployment tools in the future and I don't think anyone really
stopped to think that building this hierarchy isn't necessarily the right
thing to do. It certainly isn't a required thing to do.

With the separation of ansible from the main kolla repo, the kolla repo now
becomes a consumable much like the relationship keystone and glance.

The only advantage I can really think of at the moment is to reuse the
Kolla name and community when starting a new project, but that may not be
as advantageous as I initially thought. By my own admission, why do these
other projects care about a different orchestration tool.

So in your estimation Doug, do you feel kolla-salt would be better served
as a new project in it's own right? As well as future orchestration tools
using Kolla container images?

Thanks,
SamYaple

> Doug
>
> >
> > Thanks,
> > SamYaple
> >
> > > --
> > > Jeremy Stanley
> > >
> > > 
> __
> > > 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Doug Hellmann]

Excerpts from Sam Yaple's message of 2017-01-05 17:02:35 +:
> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley  wrote:
> 
> > On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> > [...]
> > > I do feel this is slightly different than whats described. Since it is
> > not
> > > unrelated services, but rather, for lack of a better word, competing
> > > services. To my knowledge infra doesn't have several service doing the
> > same
> > > job with different core teams (though I could be wrong).
> >
> > True, though I do find it an interesting point of view that helping
> > Kolla support multiple and diverse configuration management and
> > automation ecosystems is a "competition" rather than merely
> > extending the breadth of the project as a whole.
> >
> 
> Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
> expect these different deploy tools to bring new techniques that can then
> be reapplied to kolla-ansible and kolla-kubernetes to help out everyone.

I'm still curious to understand why, if the teams building those
different things have little or no overlap in membership, they need to
be part of "kolla" and not just part of the larger OpenStack? Why build
a separate project hierarchy instead of keeping things flat?

Do I misunderstand the situation?

Doug

> 
> Thanks,
> SamYaple
> 
> > --
> > Jeremy Stanley
> >
> > __
> > 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

On Thu, Jan 5, 2017 at 5:56 PM, Alex Schultz  wrote:

> On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski 
> wrote:
> > Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
> > there is no reason in my mind for kolla-ansible/k8s core team to vote
> > on accepting new deliverable. I think this should be lightweight and
> > easy, we should allow experimentation (after all, kolla itself went
> > through few fail iterations before ansible).
> >
> > Ad disconnect, I think we all are interested in other orch tools more
> > or less, but it's more about "who should allow new one to be added",
> > and that requires more than interest as might potentially block adding
> > new deliverable. Avoiding this disconnect is exactly why I'd like to
> > keep all deliverable team under one Kolla umbrealla, keep everyone in
> > same community so they can make use of each others experience (that
> > would also mean, that kolla-puppet is what I'd like to see rather than
> > puppet-kolla:)).
> >
>
> I mean it depends on what a proposed 'kolla-puppet' does.  If it's
> like puppet-tripleo, which falls under the TripleO umbrella and not
> Puppet OpenStack because it configures more than just a single
> 'openstack' related service then that would make sense.  Since
> puppet-tripleo a way of deploying all things OpenStack it lives in the
> TripleO world.  But I don't necessarily agree that kolla-puppet should
> exist over puppet-kolla if it just configures 'kolla'.  I would like
> to see more cross group collaboration with the deployment tool groups
> and not keeping things to themselves.  As for the intricacies of the
> specific deployment tooling, because we already have patterns and
> plenty of tooling for deploying OpenStack related services in our
> other 40 or so modules I think the Puppet OpenStack community might be
> better suited to provide review feedback than say the Kolla group when
> it comes to puppet specific questions and best practices.  And
> speaking as the Puppet PTL there would not be anything stopping us
> from having Kolla cores also be cores on puppet-kolla.
>

These are good points. I don't know which way I lean on this subject at the
moment. But I would mention that kolla-ansible doesn't exist under
openstack-ansible-kolla. And kolla-salt (should that become a thing) isn't
openstack-salt-kolla.

Just because there is an openstack project that uses a orchestration tool
doesn't mean only one such project can exist. Nor that all approaches would
be the same, even if the end goal is the same (deploy openstack).

So I am going to remain neutral on this point and say what you are saying
is reasonable, though on the other hand it may not be compatible in some
situations.

Thanks,
SamYaple

I think its important to focus on the sense of OpenStack community
> building (not just Kolla community) and spreading knowledge I think it
> would be better not to try and keep everything to yourself if there's
> already a group of people in the community who specialize in a
> specific thing.  As an aside, I'd honestly like to see more
> contribution by the upstream projects into the puppet-* world because
> I think it's important for people to understand how the software they
> right actually gets consumed.
>
> Thanks,
> -Alex
>
> > Ad multi-deployment-tool friendly rivalry, it is meant to extend
> > breadth of the project indeed, but let's face it, religious wars are
> > real (and vim is better than emacs.);) I don't thing problem would be
> > ill intent tho, I could easily predict problem being rather in "I
> > don't have time to look at this review queue" sort. Stalling reviews
> > can kill lots of potentially great changes.
> >
> >
> > On 5 January 2017 at 09:02, Sam Yaple  wrote:
> >> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley 
> wrote:
> >>>
> >>> On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> >>> [...]
> >>> > I do feel this is slightly different than whats described. Since it
> is
> >>> > not
> >>> > unrelated services, but rather, for lack of a better word, competing
> >>> > services. To my knowledge infra doesn't have several service doing
> the
> >>> > same
> >>> > job with different core teams (though I could be wrong).
> >>>
> >>> True, though I do find it an interesting point of view that helping
> >>> Kolla support multiple and diverse configuration management and
> >>> automation ecosystems is a "competition" rather than merely
> >>> extending the breadth of the project as a whole.
> >>
> >>
> >> Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'?
> I
> >> expect these different deploy tools to bring new techniques that can
> then be
> >> reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
> >>
> >> Thanks,
> >> SamYaple
> >>>
> >>> --
> >>> Jeremy Stanley
> >>>
> >>> 
> __
> >>> OpenStack 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Michał Jastrzębski]

Oh you misunderstood good sir;) kolla-puppet is similar to tripleo -
it's would set up whole OpenStack using kolla containers deployed by
puppet manifests. I agree, if it would only install kolla - that
should go to openstack puppet, but kolla is a deployment tool.

On 5 January 2017 at 09:56, Alex Schultz  wrote:
> On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski  wrote:
>> Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
>> there is no reason in my mind for kolla-ansible/k8s core team to vote
>> on accepting new deliverable. I think this should be lightweight and
>> easy, we should allow experimentation (after all, kolla itself went
>> through few fail iterations before ansible).
>>
>> Ad disconnect, I think we all are interested in other orch tools more
>> or less, but it's more about "who should allow new one to be added",
>> and that requires more than interest as might potentially block adding
>> new deliverable. Avoiding this disconnect is exactly why I'd like to
>> keep all deliverable team under one Kolla umbrealla, keep everyone in
>> same community so they can make use of each others experience (that
>> would also mean, that kolla-puppet is what I'd like to see rather than
>> puppet-kolla:)).
>>
>
> I mean it depends on what a proposed 'kolla-puppet' does.  If it's
> like puppet-tripleo, which falls under the TripleO umbrella and not
> Puppet OpenStack because it configures more than just a single
> 'openstack' related service then that would make sense.  Since
> puppet-tripleo a way of deploying all things OpenStack it lives in the
> TripleO world.  But I don't necessarily agree that kolla-puppet should
> exist over puppet-kolla if it just configures 'kolla'.  I would like
> to see more cross group collaboration with the deployment tool groups
> and not keeping things to themselves.  As for the intricacies of the
> specific deployment tooling, because we already have patterns and
> plenty of tooling for deploying OpenStack related services in our
> other 40 or so modules I think the Puppet OpenStack community might be
> better suited to provide review feedback than say the Kolla group when
> it comes to puppet specific questions and best practices.  And
> speaking as the Puppet PTL there would not be anything stopping us
> from having Kolla cores also be cores on puppet-kolla.
>
> I think its important to focus on the sense of OpenStack community
> building (not just Kolla community) and spreading knowledge I think it
> would be better not to try and keep everything to yourself if there's
> already a group of people in the community who specialize in a
> specific thing.  As an aside, I'd honestly like to see more
> contribution by the upstream projects into the puppet-* world because
> I think it's important for people to understand how the software they
> right actually gets consumed.
>
> Thanks,
> -Alex
>
>> Ad multi-deployment-tool friendly rivalry, it is meant to extend
>> breadth of the project indeed, but let's face it, religious wars are
>> real (and vim is better than emacs.);) I don't thing problem would be
>> ill intent tho, I could easily predict problem being rather in "I
>> don't have time to look at this review queue" sort. Stalling reviews
>> can kill lots of potentially great changes.
>>
>>
>> On 5 January 2017 at 09:02, Sam Yaple  wrote:
>>> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley  wrote:

 On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
 [...]
 > I do feel this is slightly different than whats described. Since it is
 > not
 > unrelated services, but rather, for lack of a better word, competing
 > services. To my knowledge infra doesn't have several service doing the
 > same
 > job with different core teams (though I could be wrong).

 True, though I do find it an interesting point of view that helping
 Kolla support multiple and diverse configuration management and
 automation ecosystems is a "competition" rather than merely
 extending the breadth of the project as a whole.
>>>
>>>
>>> Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
>>> expect these different deploy tools to bring new techniques that can then be
>>> reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
>>>
>>> Thanks,
>>> SamYaple

 --
 Jeremy Stanley

 __
 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
>>> 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Alex Schultz]

On Thu, Jan 5, 2017 at 10:25 AM, Michał Jastrzębski  wrote:
> Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
> there is no reason in my mind for kolla-ansible/k8s core team to vote
> on accepting new deliverable. I think this should be lightweight and
> easy, we should allow experimentation (after all, kolla itself went
> through few fail iterations before ansible).
>
> Ad disconnect, I think we all are interested in other orch tools more
> or less, but it's more about "who should allow new one to be added",
> and that requires more than interest as might potentially block adding
> new deliverable. Avoiding this disconnect is exactly why I'd like to
> keep all deliverable team under one Kolla umbrealla, keep everyone in
> same community so they can make use of each others experience (that
> would also mean, that kolla-puppet is what I'd like to see rather than
> puppet-kolla:)).
>

I mean it depends on what a proposed 'kolla-puppet' does.  If it's
like puppet-tripleo, which falls under the TripleO umbrella and not
Puppet OpenStack because it configures more than just a single
'openstack' related service then that would make sense.  Since
puppet-tripleo a way of deploying all things OpenStack it lives in the
TripleO world.  But I don't necessarily agree that kolla-puppet should
exist over puppet-kolla if it just configures 'kolla'.  I would like
to see more cross group collaboration with the deployment tool groups
and not keeping things to themselves.  As for the intricacies of the
specific deployment tooling, because we already have patterns and
plenty of tooling for deploying OpenStack related services in our
other 40 or so modules I think the Puppet OpenStack community might be
better suited to provide review feedback than say the Kolla group when
it comes to puppet specific questions and best practices.  And
speaking as the Puppet PTL there would not be anything stopping us
from having Kolla cores also be cores on puppet-kolla.

I think its important to focus on the sense of OpenStack community
building (not just Kolla community) and spreading knowledge I think it
would be better not to try and keep everything to yourself if there's
already a group of people in the community who specialize in a
specific thing.  As an aside, I'd honestly like to see more
contribution by the upstream projects into the puppet-* world because
I think it's important for people to understand how the software they
right actually gets consumed.

Thanks,
-Alex

> Ad multi-deployment-tool friendly rivalry, it is meant to extend
> breadth of the project indeed, but let's face it, religious wars are
> real (and vim is better than emacs.);) I don't thing problem would be
> ill intent tho, I could easily predict problem being rather in "I
> don't have time to look at this review queue" sort. Stalling reviews
> can kill lots of potentially great changes.
>
>
> On 5 January 2017 at 09:02, Sam Yaple  wrote:
>> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley  wrote:
>>>
>>> On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
>>> [...]
>>> > I do feel this is slightly different than whats described. Since it is
>>> > not
>>> > unrelated services, but rather, for lack of a better word, competing
>>> > services. To my knowledge infra doesn't have several service doing the
>>> > same
>>> > job with different core teams (though I could be wrong).
>>>
>>> True, though I do find it an interesting point of view that helping
>>> Kolla support multiple and diverse configuration management and
>>> automation ecosystems is a "competition" rather than merely
>>> extending the breadth of the project as a whole.
>>
>>
>> Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
>> expect these different deploy tools to bring new techniques that can then be
>> reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
>>
>> Thanks,
>> SamYaple
>>>
>>> --
>>> Jeremy Stanley
>>>
>>> __
>>> 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 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Michał Jastrzębski]

Ad kolla-ansible core team +2ing new deliverable,I agree with Sam,
there is no reason in my mind for kolla-ansible/k8s core team to vote
on accepting new deliverable. I think this should be lightweight and
easy, we should allow experimentation (after all, kolla itself went
through few fail iterations before ansible).

Ad disconnect, I think we all are interested in other orch tools more
or less, but it's more about "who should allow new one to be added",
and that requires more than interest as might potentially block adding
new deliverable. Avoiding this disconnect is exactly why I'd like to
keep all deliverable team under one Kolla umbrealla, keep everyone in
same community so they can make use of each others experience (that
would also mean, that kolla-puppet is what I'd like to see rather than
puppet-kolla:)).

Ad multi-deployment-tool friendly rivalry, it is meant to extend
breadth of the project indeed, but let's face it, religious wars are
real (and vim is better than emacs.);) I don't thing problem would be
ill intent tho, I could easily predict problem being rather in "I
don't have time to look at this review queue" sort. Stalling reviews
can kill lots of potentially great changes.


On 5 January 2017 at 09:02, Sam Yaple  wrote:
> On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley  wrote:
>>
>> On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
>> [...]
>> > I do feel this is slightly different than whats described. Since it is
>> > not
>> > unrelated services, but rather, for lack of a better word, competing
>> > services. To my knowledge infra doesn't have several service doing the
>> > same
>> > job with different core teams (though I could be wrong).
>>
>> True, though I do find it an interesting point of view that helping
>> Kolla support multiple and diverse configuration management and
>> automation ecosystems is a "competition" rather than merely
>> extending the breadth of the project as a whole.
>
>
> Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
> expect these different deploy tools to bring new techniques that can then be
> reapplied to kolla-ansible and kolla-kubernetes to help out everyone.
>
> Thanks,
> SamYaple
>>
>> --
>> Jeremy Stanley
>>
>> __
>> 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

On Thu, Jan 5, 2017 at 4:54 PM, Jeremy Stanley  wrote:

> On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
> [...]
> > I do feel this is slightly different than whats described. Since it is
> not
> > unrelated services, but rather, for lack of a better word, competing
> > services. To my knowledge infra doesn't have several service doing the
> same
> > job with different core teams (though I could be wrong).
>
> True, though I do find it an interesting point of view that helping
> Kolla support multiple and diverse configuration management and
> automation ecosystems is a "competition" rather than merely
> extending the breadth of the project as a whole.
>

Yea I computer good, but I am no wordsmith. Perhaps 'friendly rivalry'? I
expect these different deploy tools to bring new techniques that can then
be reapplied to kolla-ansible and kolla-kubernetes to help out everyone.

Thanks,
SamYaple

> --
> Jeremy Stanley
>
> __
> 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Alex Schultz]

On Thu, Jan 5, 2017 at 8:58 AM, Sam Yaple  wrote:

> Involving kolla-ansible and kolla-kubernetes in a decision about
> kolla-salt (or kolla-puppet, or kolla-chef) is silly since the projects are
> unrelated. That would be like involving glance when cinder has a new
> service because they both use keystone. The kolla-core team is reasonable
> since those are the images being consumed.
>
>
Technically, I think if there was going to be a puppet module for kolla, it
should fall under the Puppet OpenStack namespace (as puppet-kolla).  So in
this case kolla-salt is only falling under the kolla namespace because
there's no longer a salt group in OpenStack right?  I don't have any skin
in the kolla game, but I would encourage a puppet-kolla if someone wanted
to contribute :)  Just to add my thoughts on the original question posed by
this thread as an outside observer, I would echo what Michal said since the
PTL should at the very least have a say.

Thanks,
-Alex


> Thanks,
> SamYaple
>
>
>
> Sam Yaple
>
> On Thu, Jan 5, 2017 at 12:31 AM, Steven Dake (stdake) 
> wrote:
>
>> Michal,
>>
>> Another option is 2 individuals from each core review team + PTL.  That
>> is lighter weight then 3 and 4, yet more constrained then 1 and 2 and would
>> be my preferred choice (or alternatively 3 or 4).  Adding a deliverable is
>> serious business ☺
>>
>> FWIW I don’t’ think we are at an impasse, it just requires a policy vote
>> as we do today.
>>
>> Regards
>> -steve
>>
>> -Original Message-
>> From: Michał Jastrzębski 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Date: Wednesday, January 4, 2017 at 3:38 PM
>> To: "OpenStack Development Mailing List (not for usage questions)" <
>> openstack-dev@lists.openstack.org>
>> Subject: [openstack-dev] [tc][kolla] Adding new deliverables
>>
>> Hello,
>>
>> New deliverable to Kolla was proposed, and we found ourselves in a bit
>> of an impasse regarding process of accepting new deliverables. Kolla
>> community grew a lot since we were singular project, and now we have 3
>> deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
>> one was proposed, kolla-salt, all of them having separate core teams
>> today. How to we proceed with this and following deliverables? How to
>> we accept them to kolla namespace? I can think of several ways.
>>
>> 1) Open door policy - whoever wants to create new deliverable, is just
>> free to do so.
>> 2) Lightweight agreement - just 2*+2 from Kolla core team to some list
>> of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
>> vote it would be good for PTL to know what he/she is PTL of;)
>> 3) Majority vote from Kolla core team - much like we do with policy
>> changes today
>> 4) Majority vote from all Kolla deliverables core teams
>>
>> My personal favorite is option 2+PTL vote. We want to encourage
>> experiments and new contributors to use our namespace, for both larger
>> community and ease of navigation for users.
>>
>> One caveat to this would be to note that pre-1.0 projects are
>> considered dev/experimental.
>>
>> Thoughts?
>>
>> Cheers,
>> Michal
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.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:unsubscrib
>> e
>> 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Jeremy Stanley]

On 2017-01-05 16:46:36 + (+), Sam Yaple wrote:
[...]
> I do feel this is slightly different than whats described. Since it is not
> unrelated services, but rather, for lack of a better word, competing
> services. To my knowledge infra doesn't have several service doing the same
> job with different core teams (though I could be wrong).

True, though I do find it an interesting point of view that helping
Kolla support multiple and diverse configuration management and
automation ecosystems is a "competition" rather than merely
extending the breadth of the project as a whole.
-- 
Jeremy Stanley

__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

On Thu, Jan 5, 2017 at 4:34 PM, Jeremy Stanley  wrote:

> On 2017-01-05 15:58:45 + (+), Sam Yaple wrote:
> > Involving kolla-ansible and kolla-kubernetes in a decision about
> kolla-salt
> > (or kolla-puppet, or kolla-chef) is silly since the projects are
> unrelated.
> > That would be like involving glance when cinder has a new service because
> > they both use keystone. The kolla-core team is reasonable since those are
> > the images being consumed.
>
> In contrast, the Infra team also has a vast number of fairly
> unrelated deliverables with their own dedicated core review teams.
> In our case, we refer to them as our "Infra Council" and ask them to
> weigh in with Roll-Call votes on proposals to the infra-specs repo.
> In short, just because people work primarily on one particular
> service doesn't mean they're incapable of providing useful feedback
> on and help prioritize proposals to add other (possibly unrelated)
> services.
>

I do feel this is slightly different than whats described. Since it is not
unrelated services, but rather, for lack of a better word, competing
services. To my knowledge infra doesn't have several service doing the same
job with different core teams (though I could be wrong).

Thanks,
SamYaple

> --
> Jeremy Stanley
>
> __
> 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

On Thu, Jan 5, 2017 at 4:06 PM, Doug Hellmann  wrote:

> Excerpts from Sam Yaple's message of 2017-01-05 15:58:45 +:
> > Involving kolla-ansible and kolla-kubernetes in a decision about
> kolla-salt
> > (or kolla-puppet, or kolla-chef) is silly since the projects are
> unrelated.
> > That would be like involving glance when cinder has a new service because
> > they both use keystone. The kolla-core team is reasonable since those are
> > the images being consumed.
>
> If those teams are so disconnected as to not have an interest in the
> work the other is doing, why are they part of the same umbrella project
> team?
>
> The disconnection is rather new, though it has been a long time coming. In
Newton, all of the kolla-ansible code existed in the kolla repo. It has
since been split to kolla-ansible to separate interests and allow for new
projects like kolla-kubernetes (and even kolla-salt) to have the same
advantages as kolla-ansible. Be a first-class citizen. Frankly, the kolla
namespace is _not_ needed for these projects anymore. Kolla-salt does not
need to be called kolla-salt at all. It could be called some other name
without much ado. However, the primary goal of the split was to encourage
projects like this to pop up under the kolla namespace, and keep different
deployment tools from interfering with each other.

As someone who works with Ansible and Salt, I don't personally think I
should be voting on the acceptance of a new deployment tool I have no
interest in that won't affect anything I am working on. Of course, this is
just my opinion.

Thanks,
SamYaple

Doug
>
> >
> > Thanks,
> > SamYaple
> >
> >
> >
> > Sam Yaple
> >
> > On Thu, Jan 5, 2017 at 12:31 AM, Steven Dake (stdake) 
> > wrote:
> >
> > > Michal,
> > >
> > > Another option is 2 individuals from each core review team + PTL.
> That is
> > > lighter weight then 3 and 4, yet more constrained then 1 and 2 and
> would be
> > > my preferred choice (or alternatively 3 or 4).  Adding a deliverable is
> > > serious business ☺
> > >
> > > FWIW I don’t’ think we are at an impasse, it just requires a policy
> vote
> > > as we do today.
> > >
> > > Regards
> > > -steve
> > >
> > > -Original Message-
> > > From: Michał Jastrzębski 
> > > Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <
> > > openstack-dev@lists.openstack.org>
> > > Date: Wednesday, January 4, 2017 at 3:38 PM
> > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > > openstack-dev@lists.openstack.org>
> > > Subject: [openstack-dev] [tc][kolla] Adding new deliverables
> > >
> > > Hello,
> > >
> > > New deliverable to Kolla was proposed, and we found ourselves in a
> bit
> > > of an impasse regarding process of accepting new deliverables.
> Kolla
> > > community grew a lot since we were singular project, and now we
> have 3
> > > deliverables already (kolla, kolla-ansible and kolla-kubernetes).
> 4th
> > > one was proposed, kolla-salt, all of them having separate core
> teams
> > > today. How to we proceed with this and following deliverables? How
> to
> > > we accept them to kolla namespace? I can think of several ways.
> > >
> > > 1) Open door policy - whoever wants to create new deliverable, is
> just
> > > free to do so.
> > > 2) Lightweight agreement - just 2*+2 from Kolla core team to some
> list
> > > of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
> > > vote it would be good for PTL to know what he/she is PTL of;)
> > > 3) Majority vote from Kolla core team - much like we do with policy
> > > changes today
> > > 4) Majority vote from all Kolla deliverables core teams
> > >
> > > My personal favorite is option 2+PTL vote. We want to encourage
> > > experiments and new contributors to use our namespace, for both
> larger
> > > community and ease of navigation for users.
> > >
> > > One caveat to this would be to note that pre-1.0 projects are
> > > considered dev/experimental.
> > >
> > > Thoughts?
> > >
> > > Cheers,
> > > Michal
> > >
> > > 
> > > __
> > > 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: 

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Jeremy Stanley]

On 2017-01-05 15:58:45 + (+), Sam Yaple wrote:
> Involving kolla-ansible and kolla-kubernetes in a decision about kolla-salt
> (or kolla-puppet, or kolla-chef) is silly since the projects are unrelated.
> That would be like involving glance when cinder has a new service because
> they both use keystone. The kolla-core team is reasonable since those are
> the images being consumed.

In contrast, the Infra team also has a vast number of fairly
unrelated deliverables with their own dedicated core review teams.
In our case, we refer to them as our "Infra Council" and ask them to
weigh in with Roll-Call votes on proposals to the infra-specs repo.
In short, just because people work primarily on one particular
service doesn't mean they're incapable of providing useful feedback
on and help prioritize proposals to add other (possibly unrelated)
services.
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Doug Hellmann]

Excerpts from Sam Yaple's message of 2017-01-05 15:58:45 +:
> Involving kolla-ansible and kolla-kubernetes in a decision about kolla-salt
> (or kolla-puppet, or kolla-chef) is silly since the projects are unrelated.
> That would be like involving glance when cinder has a new service because
> they both use keystone. The kolla-core team is reasonable since those are
> the images being consumed.

If those teams are so disconnected as to not have an interest in the
work the other is doing, why are they part of the same umbrella project
team?

Doug

> 
> Thanks,
> SamYaple
> 
> 
> 
> Sam Yaple
> 
> On Thu, Jan 5, 2017 at 12:31 AM, Steven Dake (stdake) 
> wrote:
> 
> > Michal,
> >
> > Another option is 2 individuals from each core review team + PTL.  That is
> > lighter weight then 3 and 4, yet more constrained then 1 and 2 and would be
> > my preferred choice (or alternatively 3 or 4).  Adding a deliverable is
> > serious business ☺
> >
> > FWIW I don’t’ think we are at an impasse, it just requires a policy vote
> > as we do today.
> >
> > Regards
> > -steve
> >
> > -Original Message-
> > From: Michał Jastrzębski 
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@lists.openstack.org>
> > Date: Wednesday, January 4, 2017 at 3:38 PM
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> > openstack-dev@lists.openstack.org>
> > Subject: [openstack-dev] [tc][kolla] Adding new deliverables
> >
> > Hello,
> >
> > New deliverable to Kolla was proposed, and we found ourselves in a bit
> > of an impasse regarding process of accepting new deliverables. Kolla
> > community grew a lot since we were singular project, and now we have 3
> > deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
> > one was proposed, kolla-salt, all of them having separate core teams
> > today. How to we proceed with this and following deliverables? How to
> > we accept them to kolla namespace? I can think of several ways.
> >
> > 1) Open door policy - whoever wants to create new deliverable, is just
> > free to do so.
> > 2) Lightweight agreement - just 2*+2 from Kolla core team to some list
> > of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
> > vote it would be good for PTL to know what he/she is PTL of;)
> > 3) Majority vote from Kolla core team - much like we do with policy
> > changes today
> > 4) Majority vote from all Kolla deliverables core teams
> >
> > My personal favorite is option 2+PTL vote. We want to encourage
> > experiments and new contributors to use our namespace, for both larger
> > community and ease of navigation for users.
> >
> > One caveat to this would be to note that pre-1.0 projects are
> > considered dev/experimental.
> >
> > Thoughts?
> >
> > Cheers,
> > Michal
> >
> > 
> > __
> > 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

Involving kolla-ansible and kolla-kubernetes in a decision about kolla-salt
(or kolla-puppet, or kolla-chef) is silly since the projects are unrelated.
That would be like involving glance when cinder has a new service because
they both use keystone. The kolla-core team is reasonable since those are
the images being consumed.

Thanks,
SamYaple



Sam Yaple

On Thu, Jan 5, 2017 at 12:31 AM, Steven Dake (stdake) 
wrote:

> Michal,
>
> Another option is 2 individuals from each core review team + PTL.  That is
> lighter weight then 3 and 4, yet more constrained then 1 and 2 and would be
> my preferred choice (or alternatively 3 or 4).  Adding a deliverable is
> serious business ☺
>
> FWIW I don’t’ think we are at an impasse, it just requires a policy vote
> as we do today.
>
> Regards
> -steve
>
> -Original Message-
> From: Michał Jastrzębski 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, January 4, 2017 at 3:38 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: [openstack-dev] [tc][kolla] Adding new deliverables
>
> Hello,
>
> New deliverable to Kolla was proposed, and we found ourselves in a bit
> of an impasse regarding process of accepting new deliverables. Kolla
> community grew a lot since we were singular project, and now we have 3
> deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
> one was proposed, kolla-salt, all of them having separate core teams
> today. How to we proceed with this and following deliverables? How to
> we accept them to kolla namespace? I can think of several ways.
>
> 1) Open door policy - whoever wants to create new deliverable, is just
> free to do so.
> 2) Lightweight agreement - just 2*+2 from Kolla core team to some list
> of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
> vote it would be good for PTL to know what he/she is PTL of;)
> 3) Majority vote from Kolla core team - much like we do with policy
> changes today
> 4) Majority vote from all Kolla deliverables core teams
>
> My personal favorite is option 2+PTL vote. We want to encourage
> experiments and new contributors to use our namespace, for both larger
> community and ease of navigation for users.
>
> One caveat to this would be to note that pre-1.0 projects are
> considered dev/experimental.
>
> Thoughts?
>
> Cheers,
> Michal
>
> 
> __
> 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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Steven Dake (stdake)]

Michal,

Another option is 2 individuals from each core review team + PTL.  That is 
lighter weight then 3 and 4, yet more constrained then 1 and 2 and would be my 
preferred choice (or alternatively 3 or 4).  Adding a deliverable is serious 
business ☺

FWIW I don’t’ think we are at an impasse, it just requires a policy vote as we 
do today.

Regards
-steve

-Original Message-
From: Michał Jastrzębski 
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 

Date: Wednesday, January 4, 2017 at 3:38 PM
To: "OpenStack Development Mailing List (not for usage questions)" 

Subject: [openstack-dev] [tc][kolla] Adding new deliverables

Hello,

New deliverable to Kolla was proposed, and we found ourselves in a bit
of an impasse regarding process of accepting new deliverables. Kolla
community grew a lot since we were singular project, and now we have 3
deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
one was proposed, kolla-salt, all of them having separate core teams
today. How to we proceed with this and following deliverables? How to
we accept them to kolla namespace? I can think of several ways.

1) Open door policy - whoever wants to create new deliverable, is just
free to do so.
2) Lightweight agreement - just 2*+2 from Kolla core team to some list
of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
vote it would be good for PTL to know what he/she is PTL of;)
3) Majority vote from Kolla core team - much like we do with policy
changes today
4) Majority vote from all Kolla deliverables core teams

My personal favorite is option 2+PTL vote. We want to encourage
experiments and new contributors to use our namespace, for both larger
community and ease of navigation for users.

One caveat to this would be to note that pre-1.0 projects are
considered dev/experimental.

Thoughts?

Cheers,
Michal

__
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

Re: [openstack-dev] [tc][kolla] Adding new deliverables

[Sam Yaple]

As the person purposing kolla-salt, I would like to weigh in. I like the
idea of option 2, I certainly feel the PTL should always be involved in
these things.

I would also agree with the pre-1.0 as dev/experimental so as to not be
tightly bound by rules for more stable and long term projects (like
backward compatibility) until after 1.0 is tagged. This would give the
flexibility for the project to reinvent itself as it grows.

What I do notice is lack of wording describing who would be committing to
work on the new deliverable, and I think that is important. It could be a
team of people wanting to work on it, or one person putting forth work for
a new deployment tool to use Kolla container and others joining in as they
see the potential of the project themselves. I would prefer to keep it that
way.

Thanks,
SamYaple

Sam Yaple

On Wed, Jan 4, 2017 at 11:38 PM, Michał Jastrzębski 
wrote:

> Hello,
>
> New deliverable to Kolla was proposed, and we found ourselves in a bit
> of an impasse regarding process of accepting new deliverables. Kolla
> community grew a lot since we were singular project, and now we have 3
> deliverables already (kolla, kolla-ansible and kolla-kubernetes). 4th
> one was proposed, kolla-salt, all of them having separate core teams
> today. How to we proceed with this and following deliverables? How to
> we accept them to kolla namespace? I can think of several ways.
>
> 1) Open door policy - whoever wants to create new deliverable, is just
> free to do so.
> 2) Lightweight agreement - just 2*+2 from Kolla core team to some list
> of deliveralbes that will sit in kolla repo, potentially 2*+2 + PTL
> vote it would be good for PTL to know what he/she is PTL of;)
> 3) Majority vote from Kolla core team - much like we do with policy
> changes today
> 4) Majority vote from all Kolla deliverables core teams
>
> My personal favorite is option 2+PTL vote. We want to encourage
> experiments and new contributors to use our namespace, for both larger
> community and ease of navigation for users.
>
> One caveat to this would be to note that pre-1.0 projects are
> considered dev/experimental.
>
> Thoughts?
>
> Cheers,
> Michal
>
> __
> 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