canonical / canonical/multipass
jinja templates are not honored in cloud-init config
- Dominant language
- C++
- Stars
- 9.2k
- Forks
- 828
- Avg merge
- 3d 1h
- Merged PRs (30d)
- 44
Description
We'd like to use multipass to speed up prototyping cloud-init configurations used with AWS on our local systems. Unfortunately, more complex configurations leveraging jinja templates are currently not possible, as multipass strips out relevant headers from the user-data, along with anything that may be commented out and containing valid jinja commands.
For example, this input cloud-init config:
```
## template: jinja
#cloud-config
#
# cloud-init config : create packer instance
#
# Jinja variables:
# {% set PACKER_VER='1.5.1' %}
package_update: true
package_upgrade: true
```
Should result in the following /var/lib/cloud/instance/user-data.txt (as tested on EC2):
```
## template: jinja
#cloud-config
#
# cloud-init config : create packer instance
#
# Jinja variables:
# {% set PACKER_VER='1.5.1' %}
package_update: true
package_upgrade: true
```
Instead, we lose the required header and variable setting:
```
#cloud-config
package_update: true
package_upgrade: true
```
This severely limits our options of using multipass for the goal of being a local stage area for cloud-init, and we'd love to avoid having to use external scripts or other workarounds.
Thanks!
Contributor guide
Research direction
The issue provides no file or test path. Start by tracing how Multipass receives and serializes cloud-init user-data, using the supplied input and expected /var/lib/cloud/instance/user-data.txt as fixtures; done means preserving the Jinja header and commented Jinja variable lines while retaining the existing config content.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 35/100