ISSUE-125 | add --skip-validation flag to documentation

[juanmatias]

Added --skip-validation to lines in documentation when there is no S3 set yet.

What?

• Description on whether to add this flag added to these files:
  • docs/first-steps/management-account.md
  • docs/first-steps/security-and-shared-accounts.md
  • docs/user-guide/ref-architecture-aws/tf-state-workflow.md

Why?

• When leverage terraform init is run for the very first time, there is no S3 bucket created to be set as a backend. The command as it is will fail.
• The flag --skip-validation allows to run the command, creating the bucket.
• After it is created, the backend can be set and the init command can be run with no errors.
• Close Doc/ update user-guide => Terraform - S3 & DynamoDB for Remote State Storage & Locking section #125

References

• URLs belonging to modified files:
  • https://leverage.binbash.com.ar/first-steps/management-account/#terraform-backend-layer
  • https://leverage.binbash.com.ar/first-steps/security-and-shared-accounts/#terraform-backend-layer
  • https://leverage.binbash.com.ar/user-guide/ref-architecture-aws/tf-state-workflow/#set-up

[rodriguez-matias]

Hi @juanmatias !
Im testing the Leverage landing zone and I found a similar issue in the step "Deploy Management/Identity layer".
https://leverage.binbash.com.ar/first-steps/management-account/#identities-layer

Maybe we could also inlude the same solution here for this step
management/global/base-identities/
$ leverage terraform init --skip-validation

What do you thing bout it?

[rodriguez-matias]

LGTM 👍

[juanmatias]

@rodriguez-matias

The bucket is created under the Terraform Backend Layer creation, so, I think when creating the identities layer the bucket already exists, thus its config.tf file has these lines uncommented:

  backend "s3" {
    key = "management/identities/terraform.tfstate"
  }

If this is true then we don't need to add the flag when creating identities as we did for backend creation. Please, @angelofenoglio, confirm this.

Hi @juanmatias ! Im testing the Leverage landing zone and I found a similar issue in the step "Deploy Management/Identity layer". https://leverage.binbash.com.ar/first-steps/management-account/#identities-layer

Maybe we could also inlude the same solution here for this step management/global/base-identities/ $ leverage terraform init --skip-validation

What do you thing bout it?

[angelofenoglio]

Yes, as @juanmatias pointed out, the --skip-validation is only needed when deploying the terraform backend layer for the first time, most other layers, except under special conditions, do not require this. So for the identities layer it is not a requirement.

[rodriguez-matias]

@juanmatias , @angelofenoglio ✋ . Yes you both are rigth.
Sorry for not being more clear before.

---

The issue under the Identity layer its similar but not the same:

The error that I see here appears when I run terrafom init.
Seems related with some validation of the aws credentials profile name

the only aws profile that I have so far at this step its the following:

❯ pwd
./.aws/ld
❯ cat credentials
[ld-bootstrap]
aws_access_key_id = XXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXX

This validation error its solved running $ leverage terraform init --skip-validation

[juanmatias]

@rodriguez-matias @angelofenoglio
AFAIK this is related to the profiles not having the name format required by the standards (i.e. not starting with ld-management).

Now, the question here is: must we state in the documentation the usage of this flag by default? or instead, should we add a note notifying that if you use non-standardized names you can skip the validation using the flag?

[angelofenoglio]

Oh, now I get what you mean @rodriguez-matias .
In this case the issue comes from the use of a bootstrap profile during the first part of the first steps guide, but is part of a different issue, maybe we should simply drop the bootstrap name for that profile and use the final version right from the beginning.
This would require some modification in the template and in the cli, but I think it would lead to a more consistent design overall. Should we create an issue and discuss it further there?