Comment by SEJeff | Hacker News Reader

Comment by SEJeff | Hacker News Reader

Parent Full thread

What does Canonical work on in upstream Kubernetes? I see hundreds+ of commits from Redhat and CoreOS in Kubernetes and the associated projects?

In the main kubernetes git repo, I see 39 non-merge from @canonical commits, 99% of which are under cluster/juju/* and 1 doc fix for juju, so not really a value add to Kubernetes at all. How can I, as someone deploying kubernetes on bare metal, trust you to manage a difficult project when Canonical doesn't seem to contribute much at all to the project or ecosystem?

It is great that you're making kubernetes easy to manage and deploy, but other than ease of use (which GKE does an excellent job of as well from the authors of k8s), what is Canonical's actual value add for paying you to manage k8s? Sorry for the terseness, but I'm genuinely curious what value add there is here. As a purely tech focused person, I simply don't see it. Even other firms doing exactly what you do (Apcera) have actual code change commits. I don't see a single one from Canonical that does.

Unlike other companies, we don't jump in to upstream projects and throw weight around to influence a project to make it more marketable for us. Kubernetes has a vibrant, and powerful core contributor base already. When it makes sense, for any changes we make, we'll be happy to package those back upstream. Primarily, our contributions to Kubernetes is around operations. What happens 1 week, 1 month, 1 year after setting up a cluster.

GKE is great, but GKE is Google only. It's not on-prem, it's not cross cloud, and it's not portable. That's important to some people. Our contributions to cluster/juju is the distillation of our operational knowledge in running Kubernetes everywhere. The same upstream k8s, deployed with the same tooling, everywhere.

Not all value can be measured in commits :)

The way you start this off is a pretty poor response to my original question, whereas the rest is fantastic. It isn't about throwing one's weight around or even making it more marketable, but about improving the product for new use cases (such as Apprenda wanting to better Kubernetes via the on-premise sig).

Thanks for your response, I was curious as to the value add and this helps.

We're participating in the on-prem sig now that it's been acked, along with Apprenda, CoreOS, Mirantis, and I'm sure some others.

Thanks for the feedback, my original sentence may have been a bit hasty, but the core of the message is there. I see Canonical's role as the expediter/server in a kitchen instead of donning another chef hat when dish are piling up to go out. We want to celebrate and get the amazing work of the community into as many hands as possible.

We participate in SIGs as well, sig-on-premise being one we co-chair and co-founded. We've planning on helping the project in ways other than code contributions.

Sorry I meant even Apprenda has actual golang feature commits. That was my point Re: Apprenda and contributions.

This seems to be Canonical's general direction. It just makes me sad that is is more on marketing than engineering. I wish it was more of both as clearly Canonical does Linux + marketing better than basically anyone or there wouldn't be so much Ubuntu everywhere :)

In defense of Canonical, it's preferable that an organization leave the code alone rather than influence it for their own benefit. If Canonical is able to offer a useful embellishment upon k8s without changing much k8s code, good for them. (I have no stake in this personally, though I am still a bit spiteful toward Canonical over Unity :p )

Operational ease of use and distribution is our contribution, and we've only just recently joined the Kubernetes community, but as pointed out we see our role value as getting Kubernetes into as many hands as easy and quickly as possible.

EDIT: My first response might of come off as rude, so I fixed it.

That's fair, your response seems reasonable, and Canonical has done an excellent amount of this. Setting up kubernetes is hard, but should be surmountable by anyone wanting to seriously use it. Fixing it when it breaks, or figuring out how to run apps when there are issues is what is hard. Perhaps I rely too much on core engineers to fix those issues when it happens and discounted the value add proposition of Canonical on this.

Thanks for the excellent response!

Looking at commits to the code base alone is a risky way to judge engagement. It would be like saying you cannot use AWS unless you contribute to the code. We saw the same false logic in the OpenStack community that drive a lot of marginal activity into the code base instead of demanding operability.

We really want these projects to have vibrant ecosystems. Canonical (and others) is contributing to that and helping users build solutions based on the existing code base. Adding features is great. Adding users is equally important.

Reply on news.ycombinator.com