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.

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 :)

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.

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.

Is a something we could use in production ? I am looking for a kubernetes solution on azure: using persistant disk etc.

You certainly could. You'd be incurring another service running on azure to act as the disk broker. A lot of end users prefer to use things like the providers persistent disk and acknowledge the limitations there in (like 16 disk maximum per instance, and heightened costs for having managed storage)

But there's nothing stopping you from enlisting Azure PV's as a resource, Ceph managed PV's, and other incantations of durable storage. I only ask that you really consider the cost/benefit of each, and pick what makes the most sense to you.

My thoughts would be to use the azure PV disk type, and if that's not dynamic enough to meet your needs, then enlist ceph + large volumes and carve those up into RDB's to share among your workloads.

I'm sure there are others with differing opinions, and I'm happy to help you work through them (but not on a HN comment thread)

Seek me out in Slack as @lazypower, or ping me on the Juju IRC channel irc.freenode.net #juju I'm @lazypower there as well.

And finally, our juju user mailing list is another great resource for supporting questions like the above:

[email protected]

How do you deal with storage on bare metal?

As Marco alluded, our only supported storage mechanism to date (Which is represented and managed via the charm) is Ceph backed by RBD storage.

We have plans on including other storage vendors and mechanisms, but they aren't on the roadmap for the very near term. If end users start requesting a specific storage solution, it would go in our planning doc and get added to the roadmap. We're quite active with our early adopters that give us feedback and file bugs/requests.

To date you could continue to use alternative storage providers such as NFS or Gluster - but we don't have the PV creation+enlistment captured in the charm code just yet, but again, due to priorities. End users pretty much set the priorities for us, and we then circle back with some light weight planning and execution.

Hope this helps!

Typically ceph for rbd