Support Helm-style templating about krane HOT 6 CLOSED

A few notes:

• We will probably stick with ERB after all @camilo still feels quite strongly about this. How about Liquid? Camilo has reluctantly stated that he doesn't have any good arguments against it. 😛
• We need to re-survey the state of the community tooling and opinion on this before implementing anything. Relevant:
  • Whitebox COTS application management (need to join sig-apps google group for access)
  • Templates design proposal (notably argues against partials)
  • Rust prototype based on that proposal
  • PodTemplate may eventually become independently usable: issue1, issue2

cc @xldenis

from krane.

Have you seen my kubegen project? Lately, I've been playing around with some ideas around a macro syntax that would be native to YAML/JSON (somewhat alike CloudFormation), happy to chat more. I feel like plain text templating engines make the whole problem much more complex at times, and don't really guarantee valid output.

from krane.

Hi @errordeveloper! I did check out your project at some point and it looks pretty cool. 😄 I've also got my eye on the ksonnet project's solution to this problem. Shopify is still using regular yamls for the time being, but we're actively exploring other options. As far as kubernetes-deploy is concerned, I'm currently thinking we'll either expect users to generate regular k8s defs with the tool of their choice before invoking it or at most add some sort of preprocessing plug-ins hooks. Making it super opinionated about a proprietary template format seems like the wrong way to go.

from krane.

The main pain point for us are cronjobs. One of our teams has 20 of them. Just writing them down is an ordeal. Keeping them consistent after changes, for example in env variables, is a nightmare. I would love to have partials to solve this problem.

from krane.

I have submitted a PR for a rather simple partials implementation which would nonetheless fulfill our needs. See #207

from krane.

After giving this further thought, this is what I think we should do:

• extract our existing renderer into a separate class, and additionally expose it via a separate command (per #228)
• add partial support to the renderer (per #207)
• accept fully rendered templates from $stdin as an alternative to a template directory (like the -f option to kubectl apply)
• When we hit v1.0 (#229), disable ERB rendering in the deploy command by default (either add a flag to trigger it or require piping the output of the rendering command)

This gem's purpose is to be a deploy tool, not a templating engine. Basic ERB rendering is great for convenience, and we should keep it available in some form. However, there are many better community tools available for k8s templating, and our focus should be on cross-compatibility with those.

from krane.