Open Stack

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) <bhouser at 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 at port.direct>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Thursday, January 5, 2017 at 9:06 PM
>
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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) <bhouser at 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 at port.direct>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev at lists.openstack.org>
> *Date: *Thursday, January 5, 2017 at 6:47 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at 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 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 <wilkers.steve at gmail.com>
> 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 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 <doug at doughellmann.com>
> 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-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
>
>
>
>
>
> --
>
> [image: rt.direct] <https://port.direct>
>
> *Pete Birley* / Director
> pete at port.direct / +447446862551 <+44%207446%20862551>
>
> *PORT.**DIRECT*
> United Kingdom
> https://port.direct
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended recipient(s).
> Any unauthorized disclosure, dissemination, distribution, copying or the
> taking of any action in reliance on the information herein is prohibited.
> E-mails are not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, or contain viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted these risks. Port.direct is
> not responsible for errors or omissions in this message and denies any
> responsibility for any damage arising from the use of e-mail. Any opinion
> and other statement contained in this message and any attachment are solely
> those of the author and do not necessarily represent those of the company.
>
>
>
>
> __________________________________________________________________________
> 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
>
>
>
>
>
> --
>
> [image: ort.direct] <https://port.direct>
>
> *Pete Birley* / Director
> pete at port.direct / +447446862551 <+44%207446%20862551>
>
> *PORT.**DIRECT*
> United Kingdom
> https://port.direct
>
> This e-mail message may contain confidential or legally privileged
> information and is intended only for the use of the intended recipient(s).
> Any unauthorized disclosure, dissemination, distribution, copying or the
> taking of any action in reliance on the information herein is prohibited.
> E-mails are not secure and cannot be guaranteed to be error free as they
> can be intercepted, amended, or contain viruses. Anyone who communicates
> with us by e-mail is deemed to have accepted these risks. Port.direct is
> not responsible for errors or omissions in this message and denies any
> responsibility for any damage arising from the use of e-mail. Any opinion
> and other statement contained in this message and any attachment are solely
> those of the author and do not necessarily represent those of the company.
>
>
>
> __________________________________________________________________________
> 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/20170110/861214da/attachment.html>