-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tag AWS resources created with Terraform (#1552) #1701
Conversation
d0fe56a
to
c96df34
Compare
Codecov Report
@@ Coverage Diff @@
## develop #1701 +/- ##
===========================================
- Coverage 85.11% 85.10% -0.02%
===========================================
Files 123 125 +2
Lines 12636 12822 +186
===========================================
+ Hits 10755 10912 +157
- Misses 1881 1910 +29
Continue to review full report at Codecov.
|
Pull Request Test Coverage Report for Build 8318
💛 - Coveralls |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have some questions and suggestions on resource names:
- Do the names need to be unique across resource types? I don't think it's necessary. For example, I don't think it's ambiguous to have an EC2 instance called
Jesse
and also an S3 bucket withName
asJesse
. - I think using proper capitalization and spaces instead of _ or - is more appropriate since this is a "human readable name"
- I think it would make more sense to change the signature of
get_aws_tags
toand if you need adef get_aws_tags(resource_name: str, **kwargs) -> dict`
config.qualified_resource_name
, you can do it at the call site ofget_aws_tags
.
21423f0
to
54f501a
Compare
Some notes on this latest revision:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! this is coming together.
It still seems kind of weird to me to have the two distinct ways of specifying the name
tag (either explicitly, or via **kwargs
). For example what happens if resource_name
is not specified and neither is the name
kwarg passed in explicitly? I think it could be more elegant to consolidate those two code paths, but I'm pretty sure that doing it this way was Hannes's specification, in which case it should be left as it is.
I'm also uncertain about the values specified when overwriting name
directly (via kwargs). I don't really see a pattern for how the names are determined nor what they're modelled after. I think it would be useful to make the naming conventions clear so that when future resources are added, the tagging stays consistent.
|
5093131
to
13c73b6
Compare
Okay, new revision! I've made the following changes:
|
13c73b6
to
524695e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See the one change requested, but otherwise I approve.
9dcf35d
to
421a914
Compare
scripts/prepare_lambda_deployment.py
Outdated
for oldref, newref in replace.items(): | ||
value = value.replace(oldref, newref) | ||
return value | ||
pattern = re.compile(r'\${(\w+\.\w+)(?:-event)(\.\w+)}') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're missing the point of re.compile. If it is used, it should be in a scope more long-lived than that of the usages of its result. So either do that or don't use it at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I dislike how the name translation is coded twice, once as a string operation in _patch_name and as regex replacement here. Change the regex to match a TF reference and send the matches through _patch_name.
src/azul/deployment.py
Outdated
def tracked_schema(self) -> JSON: | ||
return self._tracked_schema_json()['schema'] | ||
|
||
def check_tracked_versions(self, versions: str) -> bool: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure why we need a method for a simple ==
comparison. The comparison is NOT an implementation detail that should abstracted away, nor does this method reduce code or duplication. It only has one effect: obfuscation. Inline and remove.
6211483
to
c492344
Compare
f4de671
to
9275baa
Compare
62bd0b6
to
6555ddb
Compare
cff5cf5
to
60ed45f
Compare
For demo, show labelled resources. |
Author (check before every review)
DCP/1
label or this PR does not target anhca/*
branchr
tag to commit title or this PR does not require reindexingreindex
label to PR or this PR does not require reindexingchain
label to the blocking PR or this PR is not chained to another PRmake requirements_update
or this PR leaves requirements*.txt, common.mk and Makefile untouchedR
tag to commit title or this PR leaves requirements*.txt untouchedreqs
label to PR or this PR leaves requirements*.txt untouchedu
tag to commit title or this PR does not require upgradingupgrade
label to PR or this PR does not require upgradingmake integration_test
passes in personal deployment or this PR does not touch functionality that could break the ITdevelop
Primary reviewer (before pushing merge commit)
reindex
label andr
commit title tagsandbox
or addedno sandbox
labelsandbox
or this PR does not require reindexingPrimary reviewer (after pushing merge commit)
N reviews
labelling is accurateno demo
dev
or this PR does not require reindexingAmend Terraform configuration to tag all AWS resources with some
Azul-specific tags (Owner, AzulDeployment, Creator, Name) and some tags that
are specified in DCP RFC 0006 (project, env, owner, service, Name,
managedBy).
Update documentation in README.md to specify that manually-created resources
should be tagged in a manner consistent with those maintained by Terraform.
If all tags were static, it would make sense to contain tags in the shared
Terraform configuration. Because the content of the tags depends on user config
it is reasonable to maintain helper code in
azul.deployment
.