-
Notifications
You must be signed in to change notification settings - Fork 519
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
Fargate tasks not starting with "ResourceInitializationError: unable to pull secrets or registry auth" #2194
Comments
Thanks @NoelLH! Looking into it - that permission should be added automatically without you needing to do anything. |
Hi, we encountered the same issue today. We resolved it by manually removing all resources on AWS which forced artillery to recreate everything again, so it looks like some old setting got cached somewhere. |
Thanks both! I'm tight for time at the moment so trying to avoid setting up a distinct AWS account for this if possible @hassy. I first removed all CloudFormation stacks I could find in all relevant regions & waited for the resource deletions (there was stuff from Artillery Pro and also old Serverless Artillery experiments), but this seemed to make no difference. I then delete the IAM role "artilleryio-ecs-worker-role" which had no permissions attached, and that changed the
Each time, it seems to create the worker role again OK but not any permissions/policies for it. |
I think I've sorted this for our account. I believe the problems were a combination of the all-or-nothing approach to the worker role creation, and 2 errors in the Artillery docs for Fargate which meant some of the required permissions weren't there when enough of the IAM resources were repeatedly deleted for Artillery to attempt their recreation:
|
I am unable to use fargate now with the new task definitions that have parameter store secrets. I was able to run in fargate a few months ago. This is what I am getting as a reason for task stopping. ResourceInitializationError: unable to pull secrets or registry auth: execution resource retrieval failed: unable to retrieve secrets from ssm: service call has been retried 1 time(s): invalid ssm parameters: /artilleryio/ARTIFACTORY_AUTH,/artilleryio/ARTIFACTORY_EMAIL,/artilleryio/NPMRC,/artilleryio/NPM_REGISTRY,/artilleryio/NPM_SCOPE,/artilleryio/NPM_SCOPE_REGISTRY,/artilleryio/NPM_TOKEN' |
Attempting use of Artillery for the first time in an AWS account, and experiencing the same thing as @zeeshanpolaris above. Looks like there is a function Perhaps this was missed in testing of the migration of the fargate support code in #2297 ? ( parameters already existing in test environment? ) |
@RobMullen @zeeshanpolaris apologies, fix incoming |
Thank you. Appreciate it. |
Thanks again for reporting the issue @zeeshanpolaris @RobMullen Fix is in this PR: #2354 A canary version of Artillery will be published once we merge to |
Thanks. I added those default values manually and got it working. However, I had to add these two additional permissions for cloudwatch logs in the policy used by the role. { |
Thank you very much, @hassy , for jumping on this quickly!! |
I'm trying to use the new Fargate approach in eu-central-1. (The same test repo has been used with Artillery Pro in eu-west-2 before.)
I've confirmed I have a VPC in the region, 3 public subnets, and that Artillery is correctly automatically using those subnets, so I don't think networking per se is the problem.
I've set up a user with the permissions as documented today. I created what's in the docs as a policy and attached this directly to a user group which my user is in – I wasn't totally clear how a role should be used if created.
It seems the
ecr:GetAuthorizationToken
is part of a policy that Artillery itself sets up via a worker role, and that's why it isn't in the documented policy to be set up manually in AWS. But I'm not sure what to try now to get it to run.Version info:
Running this command:
I expected to see this happen:
A test run on Fargate
Instead, this happened:
Test stopped with:
The text was updated successfully, but these errors were encountered: