-
Notifications
You must be signed in to change notification settings - Fork 35
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
After upgrade to 4.0.0 get error "extraneous key [DatadogCredentials] is not permitted" #158
Comments
Hi, I also ran into this issue. It seems that DatadogCredentials has been moved from being a property to be a registry option: As part of the 2.x release: #142 |
@allistera Thank you for the info. I still do not fully get it but my understanding so far: when register Datadog::Monitors::Monitor, we provide ApiKey and ApplicationKey, and in serverless yml we just remove those? |
Yes that is correct. There is an example in README.md of the data required when registering the type:
In this example it pulls in the keys from Secrets Manager - although you could hard-code it at this place it is highly recommended to store them within Secrets Manager. The primary advantage of this approach is that you do not need to give your users (those that area creating CF stacks) credentials. So the setup approach would be:
|
We believe it is a mistake to reject the key and fail. It made the deployments not backward compatible. It is kind of impossible for us to upgrade the version and change all project templates currently providing the |
Hi @sunshineo Just a heads up I don't work at Datadog so can't speak on their behalf. I am also in the same boat with 60+ AWS accounts needing updated. It is worth of note that the project seems to follow semver which permits backboard compatible breaking changes for the 1.x.x to 2.x.x release. One possible solution - and one we may adopt is to centralise the API/APP key in one account as Secrets Manager allows cross account access |
Thanks for your contribution! This issue has been automatically marked as stale because it has not had activity in the last 30 days. Note that the issue will not be automatically closed, but this notification will remind us to investigate why there's been inactivity. Thank you for participating in the Datadog open source community. If you would like this issue to remain open:
|
I have opened a ticket to Datadog and hopefully someone will take a look |
Hi all, apologies for the delayed response on this issue. The steps for setting up the resources from aws public registry are outlined here If you are privately registering the resource, please make sure to set the TypeConfiguration after upgrading to the latest version https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/registry-register.html#registry-set-configuration The monitors resource 4.x.x release is not backward compatible in this case with the previous major versions as we switched over to use TypeConfiguration for added security as the api/app keys were not hidden. To upgrade your existing resources to new extension versions, there are 2 options at the moment:
|
If you would put the major version into the resource type name, then people could move gradually to the new resources from the private registry. AWS does the same, see for example |
@elruwen Very good idea |
This is unfortunately too late for that approach. |
Is it? You can still publish Datadog::Monitors::Monitor as Datadog::Monitors::MonitorV4, too. I got over 100 monitors, owned by various teams. Manually deleting all those monitors from cloudformation, then uninstall the extension and then reimport them takes quite a bit of time. And while that is in progress, people need to create new monitors by hand. And temporarily deleting all those monitors is also not really an option. |
The problem is not just the monitor resource though, we have 5 other resources, and we'd need to publish on 26 regions. |
@therve Have you received any complains about the other 4 resources? Have you received complains from customers from all 26 regions or just North America? |
Any updates on that? |
Hi all, we have the following branch up to help ease the upgrade process: #200 S3 link: The 2 main changes in the PR are:
Upgrade instructions for resource major versions
|
@skarimo What I see in the 3.1.0b1 schema.json and after register the type on AWS, the configuration json shows:
What should we do? |
I cannot even rollback and I cannot even delete the stack. This is very broken
|
@sunshineo Could you make sure the type configuration is set up properly? It doesn't seem to conform to what aws expects. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/dynamic-references.html#dynamic-references-secretsmanager Try setting the TypeConfiguration to an empty object |
Thank you @skarimo . You are right. We need that "SecretString" exactly like that. It's a required hard coded thing.
|
I must say I have been disappointed how the version upgrades have been handled. We jumped on this pretty early in my organization and we are encountering these issues as well now when trying to upgrade. It's a not a big pain if you have a couple of resources in a single stack, but in our case we are talking dozens of CF stacks deployed across dozens of AWS and AWS CN accounts, handled by multiple teams. When we roll out the new version in an AWS account suddenly nobody can deploy their stacks due to a breaking change - and there is no way of doing a smooth transition of this, save for forking the resource type and making our own version if it with a different CloudFormation TypeName The planned change in #200 is a step in the right direction and we very much appreciate that effort, and hope it will be available soon. We would have preferred if you had
|
@sunshineo Great, were you able to update the resources successfully? |
@skarimo We have updated to 3.0.1b and removed the credentials from several of our services and it seems good. But it will take some time till all services remove the credentials. Then we will try to go to v4 |
it's possible to configure the datadog private extensions using Cfn/CDK like this
but it seems NOT possible to then perform a SetTypeConfiguration via cdk or cloudformation directly. how are people automating this? irritatingly I guess downgrading is the way to go as I don't want to use CLI to enable this across my accounts? |
Hi! There is no other way that doing the CLI. Not even Terraform. Please create an AWS support ticket so they can add you to the internal feature request. There is already one ;) We are doing it via CLI for now :( |
@skarimo you can also create an AWS support ticket please? |
Thanks, I've created a ticket for this. For anyone else that winds up here reading this thread, the issue that would make this changeable via cloudformation/CDK is here and could use a thumbs up. |
Yeah I was actually thinking about creating my own resource type for that ;) |
@dogfish182 i'm currently attempting to use the CfnHookTypeConfig resource. I can see in CloudTrail that it's trying to call |
It seems like this is the resource for configuring cloudformation hooks though right? Don't think it actually relates to setting type config on an activated extension? |
@dogfish182 ah yes my mistake it must only work for hook types, which is probably why i was having trouble getting it to work. looks like a custom resource is the way to go then. |
We are using serverless, here is our yml
What is the new way to do this? I did not find any documentation
The text was updated successfully, but these errors were encountered: