Issues
Issues copied to clipboard
OctopusDeploy
Change AWS Account Fallback behaviour
The Problem
The current behaviour when using AWS accounts is to fallback to using an AWS service role such as those for an EC2 instance. Unfortunately this can result in error message such as the following in sutations where you would not expect it to happen:
AWS-LOGIN-ERROR-0003: Failed to access the role information under http://169.254.169.254/latest/meta-data/iam/security-credentials/, or failed to parse the response. This may be because the instance does not have a role assigned to it. For more information visit https://g.octopushq.com/AwsCloudFormationDeploy#aws-login-error-0003
This error is likely to happen when a user incorrectly scopes an account, which effectively means that the account is not found and falls back to the EC2 instance role. We have an explicit option for this.
Proposed Change
The behaviour should be modified to throw an error if an account is not contributed such as when scoping is wrong when a user provides an AWS account. We should remove the fallback behavior and make it explicit. This will result in more deterministic behaviour and avoid confusing error messages.
Hey @shaunmarx - some serious necromancy going on here, but any chance we could get a set of reproduction steps for the problem this enhancement is trying to solve, so that whoever picks it up in Steps-land can clearly understand the undesirable behaviour?
Popping this on our Steps backlog, but it may become unnecessary if we proceed with some remodelling of how cloud-account connections work.
The behaviour should be modified to throw an error if an account is not contributed such as when scoping is wrong when a user provides an AWS account.
This was the behaviour until recently. We would "fail fast" when starting the deployment if we could not find an account to contribute.
We have had to change this behaviour in response to https://github.com/OctopusDeploy/Issues/issues/8551
