Open Stack

On Thu, Jan 5, 2017 at 4:06 PM, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Sam Yaple's message of 2017-01-05 15:58:45 +0000:
> > 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) <stdake at cisco.com>
> > 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 <inc007 at gmail.com>
> > > Reply-To: "OpenStack Development Mailing List (not for usage
> questions)" <
> > > openstack-dev at lists.openstack.org>
> > > Date: Wednesday, January 4, 2017 at 3:38 PM
> > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > > openstack-dev at 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-request at lists.openstack.org?subject:
> > > unsubscribe
> > >     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
> > >
> > > ____________________________________________________________
> ______________
> > > OpenStack Development Mailing List (not for usage questions)
> > > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:
> unsubscribe
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170105/8d6a56fd/attachment.html>