kubernetes
sort yaml examples pod storage
Let's make documentation more human readable while sorting keys in example yaml files alphabetically. I wrote this sort-yaml.go to fullfill this half-automatically. I would continue to other example files if this PR is accepted. From user experience it's easier to review examples in a logical way with readings from a-z, but that can only be in my opinion :-)
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: Once this PR has been reviewed and has the lgtm label, please assign katcosgrove for approval. For more information see the Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
Pull request preview available for checking
Built without sensitive environment variables
| Name | Link |
|---|---|
| Latest commit | 273b80300a696979579cecb5208405b667c6c64e |
| Latest deploy log | https://app.netlify.com/sites/kubernetes-io-main-staging/deploys/666876de2648e60008f3080d |
| Deploy Preview | https://deploy-preview-46784--kubernetes-io-main-staging.netlify.app |
| Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
@eumel8 : I am unsure of how helpful or not this change is, since both read just fine to me. However, that may also be because I'm not the target audience for the improvements made.
To all reviewers/approvers: If you have strong opinions for the merge of this PR, please feel free to proceed with your approval.
@divya-mohan0209 yeah, understandable. For an expert it's not a problem at all. But I used this example the last days during an exam and it was confusing to me to find the volumes part in the beginning of spec which Kubernetes sorts server-side automatically at the end. For me it's a logical step.
Figured I'd chime in for some feedback. My take is probably biased as well since I've been using this for awhile. But in practice, I most often seen specs starting out with spec.name, then spec.image. That's kind of the base requirement, so it's becomes normal for the two properties to be the first two things. Occasionally, but not always, you need to override the default command, add some volume mountpaths, and do other optional things with the configuration.
It just feels weird to me to have command listed before name. Or for mounts, to have the mountPath listed before the name of the volume. So just speaking personally, I find this less readable rather than more, so my preference would actually be to keep things like they are.
@eumel8, The above changes are favourable when other 3rd party websites or blogs will follow the format mentioned in your PR.
As, Most of the Users turn to Kubernetes/website for reference, as you can find in other or k8s website the default setup has been in use for quite a few years.
Also, looking at the changes, these are limited to the pods, but these spec-format is also followed in deployment and replicaset template and other kubernetes concepts.