Skip to content
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

[codegen] adding best practice to update tags #327

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

ammokhov
Copy link
Contributor

@ammokhov ammokhov commented Nov 6, 2020

Issue #, if available:

Description of changes:

adding best practice to the codegen on how to handle tag update:

  • Stack level tags might be undesired tags, hence it's a best practice to catch permission issues.
  • Resource level tags is just another resource property, so if user wants to attach resource tags then we should enforce correct permission set

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@ammokhov ammokhov requested a review from wbingli November 6, 2020 07:30
@ammokhov ammokhov self-assigned this Nov 6, 2020
@ammokhov ammokhov added codegen It's like magic! enhancement New feature or request labels Nov 6, 2020
@sungkkim
Copy link
Contributor

sungkkim commented Nov 6, 2020

I can see the why we'd want to do this for backwards compatibility of existing resources, but do we really want to enforce this on newly introduced resources? Also, Create handler will have the same issue and if we go the same route, there could be issues with tag based access control. I'd like to hear some others' opinions as well.

})

// If your resource supports tags, then the following pattern is required to handle resource level tags
// STEP 5 [update resource level tags progress chain]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused. Is the Step 4 and 5 are the same?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

step 4 has different translate request method - uses only stack tags:

(model) -> Translator.translateToStackTagUpdateRequest(request.getPreviousResourceTags(), request.getDesiredResourceTags())

Step 5 has normal request translator - involves previous and current model

.translateToServiceRequest((model) -> Translator.translateToResourceTagUpdateRequest(previousModel, model))

* Each BaseHandlerException maps to a specific error code, and you should map service exceptions as closely as possible
* to more specific error codes
*/
throw new CfnGeneralServiceException(ResourceModel.TYPE_NAME, e);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Then why this is a soft-failing?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stack level tags are not always intentional attachment by the customer so we dont really wanna enforce additional permissions when stack has not been changed on update

@nina-ctrlv
Copy link
Contributor

I can see the why we'd want to do this for backwards compatibility of existing resources, but do we really want to enforce this on newly introduced resources? Also, Create handler will have the same issue and if we go the same route, there could be issues with tag based access control. I'd like to hear some others' opinions as well.

Yea, I don't think this will be solving the problem of existing resources adding tagging in a backwards incompatible manner. This code will have already been deleted for resources that are adding tagging later. We would also need to do it for create as well to cover replacement update operations

@wbingli
Copy link
Contributor

wbingli commented Nov 23, 2020

I agree this additional step is confusing to understand and I don't think it's a best practice for resource especially for any new resource and we don't want to encourage to ignore the stack level tag update.

Adding a new comments to mention to handler stack level tag properly would be better than this. We should leverage other tools to prevent this happen instead of here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codegen It's like magic! enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants