Missing build-account-id option on init

[marjoleinds]

Subject of the issue

Recently, we had to re-init our orgformation as the state-file got out of sync. However, there is no option to define the build-account-id on the org-formation init which we need for our setup. Moreover, we cannot define the role it needs to assume in the management account, which we would normally have defined in the organization.yml as the DefaultBuildAccessRoleName. Is there a reason why this is not possible on the init? Can this be added? Now it requires quite some manual work.

[OlafConijn]

thanks for posting this!

so you have a problem with your state file and you would like to reinit: create a new organiation.yml file + state file to fix this.
that makes sense.

both the init and init-pipeline command are intended to do this. both are also intended to be ran from within the "management account".

Both commands should allow you to pass in the name of the role it should try and assume in member accounts using the --cross-account-role-name option. As the command should run within the management account, this role would be used to go "from management account" to "member account". the option defaults to OrganizationAccountAccessRole which is the name of the role that AWS Organizations used as a default.

the init-pipeline supports setting a --build-account-id and will set up some additional infrastructure (in the build account) using CodeCommit and CodeBuild. If you run init instead there is no additional infrastructure that will get set up and there is no need to know which account will be used to build.

could you expand on the manual work you refer to?
if part of the problem that you do not have access to the management account?

[marjoleinds]

Thank you for your quick response. Currently, the cicd to perform updates connects with the non-management account and assumes the role defined as the "DefaultBuildAccessRoleName" in the organization.yaml in the management account id defined in the .org-formationrc. As a result, the state.json and change-sets are stored in an s3 bucket in the non-management account.

With the init, I need to do it directly on the management account. The two main downsides of that are:

1. The new state file is stored in the management account. We need to then move it to the non-management account as the change-set commands use the s3 bucket in the non-management account.
2. We cannot do some 'automated' way to run the init, as it cannot do the "hop to the management account from a non-management account". Therefore, we need to perform stuff locally to re-init to be able to connect to the management account directly.

I hope this makes it more clear? Maybe good to note I wasn't there when things got initially set up, so the above method is just me understand how things work now.

[OlafConijn]

first, i think the changeset thing is a bug/regression as we changed some iam internals recently. i am happy to look into that separately.

back to this issue: the state file will be stored in whichever bucket is specified when running the init (using --state-bucket-name). you would need to ensure that the role you are using is allowed to write to the bucket, but there is no constraint i know off where the bucket needs to be located in the management account.

just to clarify, how often do you expect to run init?
the init command is there as a way to get started setting up org-formation. i understand you want to run it once more as you had an issue with your state file, but a workflow in which you run init periodically/automated.