Create an updated style/best practices guide for kustomize packages. #1144
Conversation
* See http://bit.ly/kf_kustomize_v3 * Its been over a year since we started migrating to kustomize. In that time kustomize has evolved and we have learned a lot about how to use kustomize effectively. * Some of the initial usage patterns have turned out to be problematic (e.g. vars) and there are now better options. * Update the style guide to better document best practices. Related to kubeflow#1062
|
This change is |
|
@Bobgy @rmgogogo @yanniszark @johnugeorge @krishnadurai @yanniszark |
|
/lgtm /cc @rmgogogo you may be interested in the part about var replacement |
|
@Bobgy: GitHub didn't allow me to request PR reviews from the following users: var, in, the, interested, part, replacement, you, may, be. Note that only kubeflow members and repo collaborators can review this PR, and authors cannot review their own PRs. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
docs/KustomizeBestPractices.md
Outdated
|
|
||
| For more info see [kubeflow/manifests#1131](https://github.com/kubeflow/manifests/issues/1131) | ||
|
|
||
| ###Resource file naming |
|
@jlewi Thanks for putting this together! This is very useful. One general comment: would it be a good idea to provide an example that follows all these best practices so that we can point to specific lines from this example when illustrating each best practice. |
|
|
||
| Currently we only have one use case which is substituting in cluster domain into virtual services ([ref](https://docs.google.com/document/d/1jBayuR5YvhuGcIVAgB1F_q4NrlzUryZPyI9lCdkFTcw/edit#heading=h.vyq4iltpirga)). | ||
|
|
||
| We would ultimately like to get rid of the use of vars in these cases but have not settled on precise solutions. Some possible options are |
There was a problem hiding this comment.
IMO stating that you should not use global substitution except where there is no other option is enough in the best practices, no need to delve into possible solutions. Maybe just make a overarching issue where discussion can be had and just link there "if you want more info"?
Its fine as is. just my preference.
There was a problem hiding this comment.
I think I'd like to nudge people towards using kpt setters. I guess we could just as easily link to an issue with recommended patterns and describe uses there.
There was a problem hiding this comment.
|
@jlewi thanks a lot for putting this together!
|
Done.
I'd forgotten about that. The global configmap seems like an inferior solution to kpt setters. So I think I'd rather nudge people to kpt setters. The problem with the global configmap is that we then need to have variations of the application package which use the global config map as opposed to the application configmap. With kpt setters we should be able to kustomize package complete on its own while also allowing global parameters to be set once. |
|
@yanniszark @krishnadurai could one of you LGTM please? |
|
/lgtm |
|
Thanks /approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jlewi The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
See http://bit.ly/kf_kustomize_v3
Its been over a year since we started migrating to kustomize. In that time
kustomize has evolved and we have learned a lot about how to use
kustomize effectively.
Some of the initial usage patterns have turned out to be problematic (e.g. vars) and there are now better options.
Update the style guide to better document best practices.
Related to #1062