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 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.st...@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 <d...@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-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 > > > > > > -- > > [image: rt.direct] <https://port.direct> > > *Pete Birley* / Director > pete@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-requ...@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@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-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