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 +0000:
> 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
> 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
>
>
> __________________________________________________________________________
> 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
