kube-lego
kube-lego copied to clipboard
jetstack
"Non-production use case 😆" ?
Can you please elaborate why is this a requirement? Should we treat this software unfit for running applications in production? In any case, explaining the why next to the statement would be helpful.
Just stumbled accross this, too. Why is this non-production? What would you suggest for prod? Searching for let's encrypt integration for our prod cluster this seemed to me the most trustworthy (until now)
I get that it's most likely a tongue-in-cheek gesture but it's not really reassuring any Kube admins running production environments. If the software is in beta, which it seems to be, then by all means. Otherwise the intended use for Kube-Lego should be clarified.
+1 It's not clear whether there's a fundamental reason why it's not suitable for production or if it means that the software is buggy/not stable.
When I wrote the README, I was using the lego library and they have a similar statement in their README
As we are now using acme library and I use it in my production environment for quite while (and so do many others), we should rephrase that 😉
Interesting, should this project’s name still be kube-lego? I believe lego is the name of the Go library for LE. It appears like golang.org/x/crypto/acme makes no stability promises either:
This package is a work in progress and makes no API stability promises. https://godoc.org/golang.org/x/crypto/acme
@ahmetb At least they're not they're not explicitly warning you to avoid production use. I think saying something is still in beta is quite different from saying "this isn't production-ready software".
Meanwhile this is the only/best project around for Kubernetes HTTPS deployments, suggested by the official Kubernertes account themselves and we're all running it on production websites! :stuck_out_tongue:
@chepurko I suggest you don't take that sign as "recommended". It's not by the "official Kubernetes account". It's contributed by someone and it is just mentioned in the ingress documentation as a way to do something. It might as well be another project.
Meanwhile this is the only/best project around for Kubernetes HTTPS deployments
A big [citation needed] here. What's your metric?
and we're all running it on production websites! 😛
Hardly a reason for others to run it on their production websites, too.
There's relevant discussion on https://github.com/PalmStoneGames/kube-cert-manager/issues/33 whether this project, or kube-cert-manager or another way should make its way to kubernetes-incubator. Right now there is no official suggestion.
@ahmetb Fair enough. It's mentioned by the Ingress project on the official Kubernetes GitHub account. Not an official recommendation.
Meanwhile this is the only/best project around for Kubernetes HTTPS deployments
Okay, not only project. Best? Let's guage that by a Google search and then by stars/forks/contributors on the two top Let's Encrypt-based projects. I think it's fair to say most popular then, if you like.
and we're all running it on production websites! :stuck_out_tongue:
Sure. That was just a hint of irony on my part. We're just talking semantics here.
The point is everyone would more or less agree with your first comment here; is there a reason for the non-production use case point? Or has that point been outlived? Maybe to answer that last question there needs to be a discussion around the stability of this project.
I would venture to suspect that given the fact that this issue was opened, maybe people view this as being pretty stable for the correct use-cases. It does what it says when you set it up right. At least in my experience... Why say avoid production servers then? Just give it a beta or prerelease or something else tag (which is what @simonswine seems to be saying. Just "rephrase" that).
The only other thing I would say is I don't think the Go ACME library documentation not promising stability would prohibit rephrasing "non-production use case".
then by stars/forks/contributors on the two top Let's Encrypt-based projects. I think it's fair to say most popular then, if you like.
If you stay on the front page on Hacker News (which is completely based on luck, not something you can engineer) you can get 1000+ stars and that doesn't mean anything. Evaluation purely based on stars or Google trends or SEO is not a great measurement of merit.
If you stay on the front page on Hacker News (which is completely based on luck, not something you can engineer) you can get 1000+ stars and that doesn't mean anything. Evaluation purely based on stars or Google trends or SEO is not a great measurement of merit.
I completely agree with you here - I don't think we should measure the stability of this project based on it's popularity.
As @simonswine says, the lego library explicitly states that the project shouldn't be used in production, hence why that warning was adopted by kube-lego at the time. Now that we're using golang.org/x/crypto/acme, I still think it is worth reviewing this - the new package states This package is a work in progress and makes no API stability promises. - API stability is the developers problem to keep up to date with. We vendor our dependencies and have automated tests in order to detect functional changes. Our code just won't compile if the API changes.
Perhaps replacing this line in the README with a paragraph that briefly explains the current state of kube-lego, so that end-users can decide for themselves if this is production ready for them? As we all know, 'production ready' has many different definitions in the OSS world and I think the issue brought up here stems from that fact.
Does replacing that warning with a paragraph explaining the projects status work better?
- We're based on
golang.org/x/crypto/acme, which is still a work in progress package, however have automated tests to detect functional changes when upgrading this dependency. - The project is not scale-tested. (and anything more people have to add here)
More people using this and having a positive experience is a good sign, but I do wonder what the official criteria for Kubernetes graduating to 'stable' was? Perhaps we can use a similar criteria here for removing this statement. Ingress & Deployments as k8s objects are only declared 'beta' as it is, and we depend upon those in this project (which in k8s instance means the API is stable - which it's fair to say the kube-lego API hasn't changed for a very long time).
Likely the successor of this project, https://github.com/jetstack-experimental/cert-manager , will be driven to a state where it is production ready in the future.
Do you know the state of that project in relation to this one? I will be needing a solution to this asap, so I guess I have to choose between these two :)
@johan-lejdung you'll be choosing between two pre-stable software. I cannot suggest you to use either. :)
@ahmetb I am of course aware of that, not looking for any suggestions. Just generally curious what the state is on the two project. Seems a bit odd that there are two, almost the same, projects in active development by some of the same people (one surely has to take up the most of the time).
Maybe you cannot clear this up, then I would hope for an answer from someone else, maybe @simonswine