Packaged Template Management

[dboitnot]

Packaged Template Management

Managing shared templates for multiple sites I've found that it's critical that a change implemented for one stack at one site not propagate unintentionally to another. I'd previously handled this with careful use of git sub-repos but that was very unwieldy. To deal with this I created a template handler which fetches and version-pins templates published to a repository. This has been working very well for months so I thought I'd mention it here in case it could be useful to others.

https://github.com/sigdba/sceptre_package_template_handler

[zaro0508]

Sorry if I don't fully understand the problem. If you don't want to propagate a change to a shared template across all locations why not just employ the general library dependency pattern? Just version your source repo or files then select the version you want to deploy? We use this pattern on our deployments where we pick either a specific version or a latest (aka master) version to deploy using the basic sceptre file handler.

example (specific version):

template:
  type: http
  url: https://raw.githubusercontent.com/Sage-Bionetworks/aws-infra/v0.3.7/templates/PyPlate/python.yaml

example (latest version):

template:
  type: http
  url: https://raw.githubusercontent.com/Sage-Bionetworks/aws-infra/master/templates/PyPlate/python.yaml

[dboitnot]

I think your example is perfectly valid but my solution does a few other things:

1. Most of our templates are multi-file Python templates. The package manager handles downloading, unzipping, and identifying the correct entry point for the template.
2. By default, the plugin stages downloaded templates into the repository where they can be included in version control. This may not be desirable for everybody (in which case they can be added to .gitignore) but it's a requirement for us.
3. The plugin presents a simple interface for my users where the only thing they need to specify in their stack configuration is the name of the template and it's release number.

[zaro0508]

Ahh ok, it makes sense now @dboitnot. I think it would really help users if you could provide some context around the motivation behind your template handler. Maybe you can add it to the handler's README doc?

If you would like to make your handler more easily discoverable we would be happy to host the repo on the github Sceptre org. We hang out at the og-aws slack come by to discuss and we can work with you to make that happen.

[jfalkenstein]

I agree that it could be good. However, looking at the code, there appears to be almost no docs or docstrings. I struggle to understand how one would go up to set up such a "repository" in a way that lets them do this. Finally, it'd be great if it included support for other template types. In other words, if there was a "sub-type" on the template handler, so you could do something like pull over a package for a SAM application and use the sam template handler type to actually invoke it now that it's been pulled over. For this to be optimally compatible, it would need to unpackage the things somewhere within the project's templates/ directory.

[jfalkenstein]

Along those lines, now that you have essentially your "proof of concept" in your repo, we could spawn a brand new repo within the Sceptre org for you and you could create Pull requests into the repo to make something ready for global, generalizable consumption (with maximum Sceptre compatibility). I would be happy to work with you on that and participate in reviews, etc...

How does that sound?

[dboitnot]

I'm up for standing up a new repository. Here's what I'd like to address, probably in the original repo, before proceeding:

1. Documentation - Need a guide to setting up your own repository.
2. Code Quality - Need to get this past the PoC phase and add docstrings, unit tests, type hints, etc.
3. Package Signature Support - In a world where people are sharing templates extensively it'd be a good idea if the user could specify a set of trusted keys.