News for hackers. Stuff that matters.
Re:Show HN: konfd – Manage Kubernetes secrets and configmaps... by otterley on Monday December 05, 2016 @01:11PM (#13107671)
I appreciate your efforts here, Kelsey. What I'm looking for (and I realize I'm not your manager; this is just my opinion borne of a year of experience with K8S) is a focus on strengthening the core first, then going back to the veneer. Great edifices start with a strong foundation.

Also, the engineering teams need to do a better job of integrating community PRs that address implementor demands. For example, Consul K/V support has been asked for since 2014 [1], yet nobody seems to be in a hurry to integrate the (generously-provided) functionality [2].

Finally, I'd like to see deadlines and decision-makers appointed for making decisions such as the one you discuss, so we can avoid endless debates and make forward progress quickly.

[1] https://github.com/kubernetes/kubernetes/issues/1957

[2] https://github.com/kubernetes/kubernetes/pull/31622

Re:Show HN: konfd – Manage Kubernetes secrets and configmaps... by kelseyhightower on Monday December 05, 2016 @01:18PM (#13107745)
We all want a strong foundation and will continue to work to create one. In parallel, many of us like building and sharing things, and given that most things in Kubernetes are just abstractions, the things we are building today will continue to work tomorrow, even if the "secrets" backend is reimplemented on top of something like Vault.

I'm hopeful people find things like konfd useful, even if you only use configmaps and avoid secrets entirely -- a use case supported by konfd.

Re:Show HN: konfd – Manage Kubernetes secrets and configmaps... by Terretta on Tuesday December 06, 2016 @09:21AM (#13114723)
Also consider Consul/Vault so you can leverage the remarkably uncoupled portability of envconsul: https://github.com/hashicorp/envconsul

// PS. To help avoid confusion, I wish K8s (not really) secrets examples didn't use the word "vault" unless using, you know, "vault".