-
Notifications
You must be signed in to change notification settings - Fork 39.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Implement templates #23896
Comments
cc @mfojtik |
/cc @bparees |
An implementation in Rust: |
Can we have a template feature in https://github.com/kubernetes/features as an umbrella for the ongoing implementations? |
I'll create one. |
@danielqsj offered to help. |
Does that mean we have review bandwidth? |
I have review bandwidth, though my review perspective is largely limited to the original proposal intent and what was done in openshift, not so much "is this how we want it to be integrated into k8s" |
SGTM. Let me sync up with Brian on our goals. A good chunk of Templates is implemented. Would like to get feedback on some changes I made to the original proposal. |
Before, all images are pushed with the SHA and the `latest` tag. With this commit, pushing an image will tag it with the branch name as well for easier use while developing. Unfortunately, k8s doesn't support templating yet (kubernetes/kubernetes#23896) so you'll still have to manually change the image tag in the `manifest.yaml` file back and forth but it's definitely easier than before. Now, the workflow is: 1. Work on image 2. Push with `make release-all` 3. Edit `manifest.yaml` to use images for your branch to test 4. Edit it back when making a PR.
Before, all images are pushed with the SHA and the `latest` tag. With this commit, pushing an image will tag it with the branch name as well for easier use while developing. Unfortunately, k8s doesn't support templating yet (kubernetes/kubernetes#23896) so you'll still have to manually change the image tag in the `manifest.yaml` file back and forth but it's definitely easier than before. Now, the workflow is: 1. Work on image 2. Push with `make release-all` 3. Edit `manifest.yaml` to use images for your branch to test 4. Edit it back when making a PR.
Independent implementation: |
When do you suppose this will come to fruition? I'm having to jerry rig Yaml file parametrization using some other bash str sub tool. |
@evictor I don't think a lot of work is being done on this, in favour of third-party tools. The "big" one is Helm, but it comes with a lot of added complexity (but also a lot of pre-packaged "charts"). If you're looking for something simpler (templating with a notion of different environments/clusters), take a look at kontemplate. |
Thanks for the pointers. Kontemplate looks good. For POC purposes I am using |
@rot26 I was able to install it relatively painlessly using |
There are many, many tools that can do parameter substitution and other forms of config generation: (links will go elsewhere) For now, the client-side implementation exists. |
Automatic merge from submit-queue. Parameterise ES cluster yaml in tests Allows me to override the ES pilot image parameters when I'm running tests manually on GKE. Using `envsubst` as a much lighter weight alternative to using helm chart. Discovered via: kubernetes/kubernetes#23896 (comment) Stacked on #177 **Release note**: ```release-note NONE ```
Deleted snarky comments aside, we use Kubernetes because it is an opinionated framework. Kubernetes is able to grow so quickly because there is one good implementation of every needed feature for the rest of the Kubernetes community to build on. IMO, it doesn't make sense for Kubernetes to be opinionated about everything except templating. |
I suggest that people interested in helping with this topic participate in the Application Definition Working Group: https://github.com/kubernetes/community/tree/master/wg-app-def |
Tracks the implementation of the templating proposal: https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/templates.md.
This wip is essentially a quick merge of os templates with HEAD + some modifications to get the core substitution logic and resource to work with apiserver: #23895
See proposal for details on what remains, from memory:
(())
syntax/processedTemplates
and/templates
api endpointsOther items to track
@bgrant0607 mentioned someone from @kubernetes/kubectl might be interested.
@bparees since you had the original proposal.
The text was updated successfully, but these errors were encountered: