[openstack-dev] [kolla][tc][openstack-helm][tripleo]propose retire kolla-kubernetes project

Brandon Jozsa bjozsa at jinkit.com
Wed Apr 4 21:45:04 UTC 2018


I’ve been a part of the OpenStack-Helm project from the very beginning, and there was a lot of early brainstorming on how we could collaborate and contribute directly to Kolla-Kubernetes. In fact, this was the original intent when we met with Kolla back in Barcelona. We didn’t like the idea of fragmenting interested Kubernetes developers/operators in the OpenStack-via-Kubernetes space. Whatever the project, we wanted all the domain expertise concentrated on a single deployment effort. Even though OSH/K-k8s couldn’t reach an agreement on how to handle configmaps (our biggest difference from the start), there was a lot of early collaboration between the project cores. Early K-k8s contributors may remember Halcyon, which cores from both sides promoted for early development of OpenStack-via-Kubernetes, regardless of the project.

One of the requests from the initial OSH team (in Barcelona) was to formally separate Kolla from Kolla-foo deployment projects, both at a project level and from a core perspective. Why have the same cores giving +2’s to Kolla, Kolla-Ansible, Kolla-Mesos (now dead) and Kolla-Kubernetes, who may not have any interest in another given discipline? We wanted reviews to be timely, and laser-focused, and we felt that this more atomic approach would benefit Kolla in the end. But unfortunately there was heavy resistance with limited yet very influential cores. I honestly think pushback was also because it would mean that any Kolla sub-projects would be subject to re-acceptance as big tent projects.

There were also countless discussions about the preservation of the Kolla API, or Ansible + Jinja portions of Kolla-Ansible. It became clear to us that Kubernetes wasn’t going to be the first class citizen for the deployment model in Kolla-Kubernetes, forcing operators to troubleshoot between OpenStack, Kolla (container builds), Ansible, Kubernetes, and Helm. This is apparent still today. And while I understand the hesitation to change Kolla/Kolla-Ansible, I think this code-debt has somewhat contributed to sustainability of Kolla-Kubernetes. Somewhat to the point of tension, I very much agree with Thierry’s comments earlier.

I want all of these projects to succeed but consolidation with purposeful and deliberate planning, which Rich has so kindly agreed to do, could be the right answer. So I +1 the idea, because I think it puts all like-minded individuals on the same focus (for the overall benefit of OpenStack and the overall OpenStack community). But we have to make sure there isn’t a lot of fallout from the decision either. To Steve Dake's previous point, there could be orphaned users/operators who feel “forced” into another project. I would hate to see that. It would be nice to at least plan this with the user-base and give them fair warning. And to this point, what is the active specific Kolla-Kubernetes core? Who is “PTL” of Kolla-Kubernetes today?

On the other hand, I think that OSH has some improvements to make as well. Gating could use some help and the OpenStack-Infra team has been kindly helping out recently (a huge "thank you" to them). Docs…I think docs could always use some love. Please offer your experiences to the OSH team! We would love to hear your user input. Ultimately, if users/operators want to run something that even closely resembles production, then we need some decent production quality docs as opposed to leveraging the nascent gate scripts (Zuulv3 ansible+heat). Releases and release planning should be addressed, as users/vendors are going to want to be closer to OpenStack release dates (recent versions of OpenStack, Helm and Kubernetes). Clear and open roadmaps, with potential use of community-led planning tools. Open elections for PTL. Finally, the OSH team may still be be interested in diversifying it’s core-base. Matt M. would have to address this. I know that I was actively seeking cores when I was initially PTL, and truthfully…there’s nobody nicer or easier to work with than Matt. He’s an awesome PTL, and any project would be fortunate to have him. All these things could all be improved on, but it requires a diverse base with a lot of great ideas.

That said, I am in favor of consolidation…if it makes sense and if there's a strong argument for it. We just need to think what’s best for the OpenStack community as a whole, and put away the positions of the individual projects for a moment. To me, that makes things pretty clear, regardless of where the commits are going. And with the +1’s, I think we’re hearing you. Now we just have to plan it out and take action (on both sides).

Brandon



On April 2, 2018 at 11:14:01 AM, Martin André (m.andre at redhat.com<mailto:m.andre at redhat.com>) wrote:

On Mon, Apr 2, 2018 at 4:38 PM, Steven Dake (stdake) <stdake at cisco.com> wrote:
>
>
>
> On April 2, 2018 at 6:00:15 AM, Martin André (m.andre at redhat.com) wrote:
>
> On Sun, Apr 1, 2018 at 12:07 AM, Steven Dake (stdake) <stdake at cisco.com>
> wrote:
>> My viewpoint is as all deployments projects are already on an equal
>> footing
>> when using Kolla containers.
>
> While I acknowledge Kolla reviewers are doing a very good job at
> treating all incoming reviews equally, we can't realistically state
> these projects stand on an equal footing today.
>
>
> At the very least we need to have kolla changes _gating_ on TripleO
> and OSH jobs before we can say so. Of course, I'm not saying other
> kolla devs are opposed to adding more CI jobs to kolla, I'm pretty
> sure they would welcome the changes if someone volunteers for it, but
> right now when I'm approving a kolla patches I can only say with
> confidence that it does not break kolla-ansible. In that sense,
> kolla_ansible is special.
>
> Martin,
>
> Personally I think all of OpenStack projects that have a dependency or
> inverse dependency should cross-gate. For example, Nova should gate on
> kolla-ansible, and at one point I think they agreed to this, if we submitted
> gate work to do so. We never did that.
>
> Nobody from TripleO or OSH has submitted gates for Kolla. Submit them and
> they will follow the standard mechanism used in OpenStack
> experimental->non-voting->voting (if people are on-call to resolve
> problems). I don't think gating is relevant to equal footing. TripleO for
> the moment has chosen to gate on their own image builds, which is fine. If
> the gating should be enhanced, write the gates :)
>
> Here is a simple definition from the internet:
>
> "with the same rights and conditions as someone you are competing with"
>
> Does that mean if you want to split the kolla repo into 40+ repos for each
> separate project, the core team will do that? No. Does that mean if there
> is a reasonable addition to the API the patch would merge? Yes.
>
> Thats right, deployment tools compete, but they also cooperate and
> collaborate. The containers (atleast from my perspective) are an area where
> Kolla has chosen to collaborate. FWIW I also think we have chosen to
> collobrate a bit in areas we compete (the deployment tooling itself). Its a
> very complex topic. Splitting the governance and PTLs doesn't change the
> makeup of the core review team who ultimately makes the decision about what
> is reasonable.

Collaboration is good, there is no question about it.
I suppose the question we need to answer is "would splitting kolla and
kolla-ansible further benefit kolla and the projects that consume
it?". I believe if you look at it from this angle maybe you'll find
areas that are neglected because they are lower priority for
kolla-ansible developers.

>> I would invite the TripleO team who did integration with the Kolla API to
>> provide their thoughts.
>
> The Kolla API is stable and incredibly useful... it's also
> undocumented. I have a stub for a documentation change that's been
> collecting dust on my hard drive for month, maybe it's time I brush it
>
> Most of Kolla unfortunately is undocumented. The API is simple and
> straightforward enough that TripleO, OSH, and several proprietary vendors
> (the ones Jeffrey mentioned) have managed to implement deployment tooling
> that consume the API. Documentation for any part of Kolla would be highly
> valued - IMO it is the Kolla project's biggest weakness.
>
>
> up and finally submit it. Today unless you're a kolla developer
> yourself, it's difficult to understand how to use the API, not the
> most user friendly.
>
> Another thing that comes for free with Kolla, the extend_start.sh
> scripts are for the most part only useful in the context of
> kolla_ansible. For instance, hardcoding path for log dirs to
> /var/log/kolla and changing groups to 'kolla'.
> In TripleO, we've chosen to not depend on the extend_start.sh scripts
> whenever possible for this exact reason.
>
> I don't disagree. I was never fond of extend_start, and thought any special
> operations it provided belong in the API itself. This is why there are
> mkdir operations and chmod/chown -R operations in the API. The JSON blob
> handed to the API during runtime is where the API begins and ends. The
> implementation (what set_cfg.py does with start.sh and extend_start.sh) are
> not part of the API but part of the API implementation.

One could argue that the environment variables we pass to the
containers to control what extend_start.sh does are also part of the
API. That's not my point. There is a lot of cruft in these scripts
that remain from the days where kolla-ansible was the only consumer of
kolla images.

> I don't think I said anywhere the API is perfectly implemented. I'm not
> sure I've ever seen this mythical perfection thing in an API anyway :)
>
> Patches are welcome to improve the API to make it more general, as long as
> they maintain backward compatibility.
>
>
>
> The other critical kolla feature we're making extensive use of in
> TripleO is the ability to customize the image in any imaginable way
> thanks to the template override mechanism. There would be no
> containerized deployments via TripleO without it.
>
>
> We knew people would find creative ways to use the plugin templating
> technology, and help drive adoption of Kolla as a standard...
>
> Kolla is a great framework for building container images for OpenStack
> services any project can consume. We could do a better job at
> advertising it. I guess bringing kolla and kolla-kubernetes under
> separate governance (even it the team remains mostly the same) is one
> way to enforce the independence of kolla-the-images project and
> recognize people may be interested in the images but not the
> deployment tools.
>
> One last though. Would you imagine a kolla PTL who is not heavily
> invested in kolla_ansible?
>
>
> Do you mean to imply a conflict of interest? I guess I don't understand the
> statement. Would you clarify please?

All I'm saying is that we can't truly claim we've fully decoupled
Kolla and Kolla-ansible until we're ready to accept someone who is not
a dedicated contributor to kolla-ansible as kolla PTL. Until then,
some might rightfully say kolla-ansible is driving the kolla project.
It's OK, maybe as the kolla community that's what we want, but we
can't legitimately say all consumers are on an equal footing.

Martin

__________________________________________________________________________
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/20180404/2e7502d5/attachment.html>


More information about the OpenStack-dev mailing list