garyd203 / ssmash Goto Github PK

• Dependency management: Dependency ranges, freeze transitive dependencies, etc.
• Config file: Do we use pyproject.toml or setup.cfg or ...
• Inject dependencies into various places in setup.py

Versions required:

• Python 2.7
• Python 3 up to v3.5

Work (I think):

• Setup test runs with those versions
• Use six where necessary

Note that this is likely to be bigger than it looks, because flying-circus is also Python v3.6+ (for the same reasons as us, mainly because f strings and type annotations are appealing)

As a user I can specify invalidation parameters inside the YAML config file, so that I can invalidate services for subsections of the parameters

As a user I can specify parameters with a list value

Use click's command chaining to string together multiple semi-independent transformations.

Add a CLI option for --version

There is a non-trivial amount of shell scripting fuss involved in calling ssmash to create a cloud formation template, then uploading that template to cloudformation (with the right parameters), then potentially restarting your ECS service or whatever else.

Add some CLI options to make this process built-in to ssmash. It's within the scope of what we want to do ("make it easy to manage application configuration in SSM Parameter Store"), and would deliver reasonable value.

We don't really want to re-implement the create-or-update semantics of the AWS CLI deploy command, but perhaps see https://github.com/aws/aws-cli/blob/develop/awscli/customizations/cloudformation/deploy.py for a minimal amount of skeleton code we could copy

As a user I can convert a simple app config specification in YAML, into an AWS CloudFormation template that creates SSM parameters

Move AWS-specific hypothesis strategies into an external library

• pre-merge build
• post-merge release
• style checks
• tests

Support AWS tags specified at any node in the input configuration, which get applied to that node and lower. Specify them using a custom YAML tag? or perhaps just a well-defined and unusual field name.

Also support tags specified at the command line, to be applied to the entire tree

When an ECS Service (or other dependency, like a Lambda Function) is invalidated after changing the parameters, we implement this in CloudFormation by "updating" a custom resource. In terms of the CloudFormation lifecycle, this means that we create + update SSM parameters, then restart the dependent service, and then delete SSM Parameters that have been removed. Obviously, this means that the service is restarted too early, and will detect the old parameters that should be removed :-(

We can solve this by hooking into the CloudFormation "Delete" signal, and using that to perform a second restart if necessary.

Specifically, we can:

• Ensure the resource delete is not unnecessarily invoked by having a resource ID that reflects the dependent parameters (eg. a hash of all their names)
• Have the resource delete only restart after dependent parameters have been deleted (only restart when required) by getting it to introspect it's own stack and wait for any SSM Parameter Resources that are being deleted.

h/t @v-do for finding the bug

Hi, users are unable to run ssmash due to dependency conflict with pyyaml package. As shown in the following full dependency graph of ssmash, ssmash requires pyyaml >=5.1,<6，while flying-circus requires <5.2.0,>=5.1.1.

According to pip’s “first found wins” installation strategy, pyyaml 5.2 is the actually installed version. However, pyyaml 5.2 does not satisfy PyYAML<5.2.0,>=5.1.1.

Dependency tree-----------

ssmash - 2.0.1
| +- click(install version:7.0 version range:>=7.0,<8)
| +- flying-circus(install version:0.7.2 version range:>=0.7,<0.8)
| | +- attrs(install version:19.3.0 version range:>=18.2.0)
| | +- inflection(install version:0.3.1 version range:<0.4,>=0.3.1)
| | +- pyyaml(install version:3.13 version range:<5.2.0,>=5.1.1)
| +- inflection(install version:0.3.1 version range:==0.3.1)
| +- pyyaml(install version:5.2 version range:>=5.1,<6)

Thanks for your help.
Best,
Neolith