-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
Support tagging per resource type #11722
Comments
@ROSeaboyer per definition |
@medikoo Right, so that would allow us to avoid the need for adding If I were to remove the |
@ROSeaboyer can you reclarify the use case then, as what you've explained as:
Can be addressed with If that's not a solution, then I believe the use case was not explained well (or I have problems in understanding it) |
@medikoo I do have to add tags to each resource, but some of the tags I need to add are per resource type (ie all log groups), and some are individual to each individual resource, which is why I'm proposing a |
@ROSeaboyer thanks, that's clearer. This looks a rare use case that rather should be solved via external plugin. Still we can leave issue open, and if it gains significant interest we may consider taking that in. |
@medikoo a quick related question. Is there a way to (specifically) tag the Rest API, not the stages, other than using The concern is using 'stackTags' make many tagged resources irrelevant to the tag |
@spongenee |
You can create a custom Serverless plugin and make a CloudWatchLogs:tagResource request |
Is there an existing issue for this?
Use case description
I have a large number of lambda functions in a few stacks, and a requirement to add tags to every resource being deployed. Right now, we're using the deprecated serverless-plugin-tag-cloud-watch-logs but are looking to replace that, preferably with native functionality as the approach used in that plugin causes throttling for us in some cases.
Proposed solution (optional)
provider.logs
object, add an attribute calledtags
for global tags added to all serverless-controlled log groups (for lambda functions, httpApi, apiGateway, and websocket).provider.log
settings for each of httpApi, apiGateway, and websocket to allow for independent tags in a property calledtags
logGroupTags
in the function orlogs.tags
(the latter option for consistency with theprovider
section) to allow for specific tagging for the log group for a specific functionapplyProviderTagsToLogGroups
to allow for applyingprovider.tags
to all log groups; this would default to false as it would be a breaking changeThe hierarchy would be
provider.tags
(if enabled) ->provider.log.tags
->provider.logs.<event>.tags
/function[].logs.tags
I understand that there's been a lot of back and forth on this over the years, but I'm cautiously optimistic that this approach solves the long-standing concerns that people have around tagging.
The text was updated successfully, but these errors were encountered: