brettswift/cumulus

Opinionated but flexible, composable, resusable cloudformation.

cumulus's Issues

Logical resource naming convention

• Cumulus version: 0.1.6

Description

Logical resource names benefit from conventions in the cloudformation console, as well as the console of wherever the resource belongs.

Sometimes its "%s%s" % (self.name, instance_name) and sometimes it's reversed. Sometimes there's a dash. Sometimes it's not instance name that's used, but something else.

We should come up with a convention for this and sweep through the repo before much more code is written.

If there is some kind of helper function that would .. uh.. . help the convention here, maybe we can use it.

Mapping support

• Cumulus version: 0.1.5

Description

the asg PR #11 makes use of mappings that it expects from the template, but there isn't help or documentation on what that mapping should look like.

This should be documented, and if it requires a mapping structure, maybe validating that the template the step receives, has a valid mapping structure.

Make cloudformation action more open to configuration

• Cumulus version: 0.1.6

Description

This role here:
https://github.com/brettswift/cumulus/blob/master/cumulus/steps/dev_tools/cloud_formation_action.py#L47

Is a useful default.

However, in experience with going cross account, I need to replace that role.

I also may need to change other configurations in the cloudformation action.configuration object.

We should find a way to do things like this in general with cumulus, where we reduce the risk of a pull request, but also don't go to the other extreme of just re-writing troposphere.

Revisit release process

• Cumulus version: 0.1.7

We've restricted the master branch to require PR's. Maybe we should do this via a PR now ?

bumpversion is old and the docs should say bump2version, and dependencies should be installed when deploying (docs or via setup-requirements in setup.py).

This issue is to fix and re-document the deployment process.

Source userdata scripts from flat files

• Cumulus version: 0.1.5
• Python version:
• Operating System:

Description

userdata is currently inline, within a python file. Testing etc is easier if this is outside the file, and is slurped into the template directly.

They're fairly small so we probably don't need to have these copied to S3, and it makes it easier for consumers of cumulus if they're still brought into the template.

Switch prints for using the python logger

New structure for working examples

Description

The goals here are two-fold:

A complete intact mini project in an examples folder of how to use cumulus for a specific purpose.

Regression testing PR's to ensure old use cases are still functional.

Right now stacker is used to run these. It doesn't have to be stacker though...

There is a ./tests/ci/stacker_test folder but maybe we just need an examples folder.

In the case of a stacker test case, the structure would look like this:

maybe a pipeline stacker project:

cd ./tests/examples/pipeline
./conf.env
./stacker.yaml
./pipeline_blueprint.py
./deploy.sh

and a different serverless example

cd ./tests/examples/serverless
ls -lah
./serverless.yaml
./handler.js
./package.json

Thoughts? This might make it trickier if running from automation tests, so maybe this belongs in it's own repository.. or maybe just at the root in ./examples?