Closed bgrant0607 closed 6 years ago
To be honest, we usually try to use extensions that other editors on the system will recognize, rather than claiming our own. I think we'd assumed we could live with .json / .yaml for the most part - since most users on the CLI are providing paths, the extension hasn't jumped up much. We definitely want to ensure kubectl edit is using an extension that matches the format (but that can be kept separate).
On Fri, Oct 9, 2015 at 1:35 PM, Brian Grant notifications@github.com wrote:
Currently kubectl looks for files with extensions .yaml, .yml, and .json, and Kubelet reads .manifest files, at least by convention, for legacy reasons.
None of these extensions indicate that the files are Kubernetes-specific. Ironically, we don't even use the extensions to infer the encoding type -- a .json file could contain YAML, for instance.
As users build preprocessors and/or adopt higher-level orchestration tools (e.g., nulecule, terraform, deployment manager), they'll use config files of multiple formats, consumed by multiple systems. We should choose an extension that makes it clear that the files can be consumed by kubectl.
How about .kube?
Openshift uses the same format and tooling. Would it use .kube files, or choose a different extension, such as .os? Or should we choose something more neutral, like .sic -- self-identifying config (contains apiVersion and kind)?
@smarterclayton https://github.com/smarterclayton
— Reply to this email directly or view it on GitHub https://github.com/kubernetes/kubernetes/issues/15387.
I've been pretty happy with the current setup and I don't see a problem with the .yaml or .json file extensions, but it might be a good idea to validate the proper encoding. One benefit of using the "native" file extensions is better integration with other tools and editors that may be used to generate these configs and possibly consume them in the future.
Editor recognition is an interesting point.
Another idea that's popped up (e.g., in #14993) is that it would be useful to encode the content type in the file rather than via the extension, since that would work for stdin, http, packages (e.g., Helm), etc.
The Nulecule approach requires a separate manifest: https://github.com/projectatomic/nulecule/blob/master/examples/guestbook-go/Nulecule
@kubernetes/sig-cli-misc
Something like file.kube.yaml
would be recognized by all existing editors but then editors could also add kubernetes-specific support.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
Prevent issues from auto-closing with an /lifecycle frozen
comment.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or @fejta
.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten /remove-lifecycle stale
Currently kubectl looks for files with extensions .yaml, .yml, and .json, and Kubelet reads .manifest files, at least by convention, for legacy reasons.
None of these extensions indicate that the files are Kubernetes-specific. Ironically, we don't even use the extensions to infer the encoding type -- a .json file could contain YAML, for instance.
As users build preprocessors and/or adopt higher-level orchestration tools (e.g., nulecule, terraform, deployment manager), they'll use config files of multiple formats, consumed by multiple systems. We should choose an extension that makes it clear that the files can be consumed by kubectl.
How about .kube?
Openshift uses the same format and tooling. Would it use .kube files, or choose a different extension, such as .os? Or should we choose something more neutral, like .sic -- self-identifying config (contains apiVersion and kind)?
@smarterclayton