Adopt a standard and well integrated templating module

[niemeyer]

There would be benefits in the operator framework adopting a well integrated templating language.

For example:

• Encourages a single template language to be used
• Encourages a single path in the filesystem for templates
• Makes reading arbitrary charms easier
• Independent libraries can more easily use the same approach when integrated

If that sounds reasonable, some research is needed to see what's the best and most well known templating package for Python.

[exceptorr]

I'd personally vote for https://palletsprojects.com/p/jinja/ - it's lightweight, well-known in the community and, actually, is already used in some charms (example: https://github.com/canonical/charm-nats/blob/master/.gitmodules#L4 and https://github.com/charmed-lma/charm-k8s-prometheus/pull/25/files#diff-8903239df476d7401cf9e76af0252622R4)

[facundobatista]

We think there's value in providing a thin layer above Jinja2.

So, we could have something that lets the user to do the right thing easily. For example:

• have a method to load the template and render it to a file... something like render_to_file("mytemplate", somedict, destination_path)... so that will load the specific file from the templates directory, render it, and save it to the final path

• have a method to load the template but to memory... e.g. render_to_string("mytemplate", somedict) (this will just return the string).

• these methods should fail if the dict provided doesn't fully render the template (which may obscure bugs in the future... you don't want a half-rendered config files for infrastructure).

[rgildein]

I really like the idea of using Jinja2 and I created an issue that is duplicated with this. I'll close it and put an original description here.

I think it would be useful if ops.lib included features for rendering templates. Something similar to the already existing function 1 in charmhelpers.

---

[sed-i]

Additional examples:

pytest-operator

• def render_charm(self, charm_path, include=None, exclude=None, context=None, **kwcontext) - Render a templated charm using Jinja2.
• def render_bundle(self, bundle, context=None, **kwcontext) - Render a templated bundle using Jinja2.

More examples within.

lma-light bundle

./render_bundle.py bundle.yaml --testing=yes --channel=edge - render bundle from CLI for use in a tox env.

[benhoyt]

@niemeyer @jnsgruk It seems to me we can close this given our planned approach via Scriptlets + Juju templating, right? Once that's done we can open a separate issue to call into the hook tools that Juju templating exposes for Operator Framework use.

[jnsgruk]

Correct - we will be enabling a common templating approach for charms. It will be facilitated by the unit agent and the scriptlet interpreter, exposed through the operator framework.

[benhoyt]

Closing given the above. We can open a new issue when it comes time to expose scriplets/Juju templates in ops.