main.go is making incorrect assumptions

[franck-boullier]

Incorrect AWS profile:

In the file main.go
The code reads:

apienroll/main.go

Line 48 in 6cfcb24

cfg, err := external.LoadDefaultAWSConfig(external.WithSharedConfigProfile("uneet-dev"))

This IS WRONG: we should NOT use uneet-dev here but the correct value based on

• Installation ID (AWS parameter INSTALLATION_ID)
• Stage (AWS parameter STAGE)

The correct value for uneet-dev for a given environment is also declared in Travis Setting.
It is then passed on as the variable TRAVIS_PROFILE.

[kaihendry]

"uneet-dev" is just a local default. AWS config has numerous fallbacks and once deployed in the account it will just use what AWS credentials it finds under the role.

We can't make it query the parameter store since it doesn't know which Parameter store to query.

We can assume ${INSTALLATION_ID}-${STAGE} is setup in the local environment, but that's a big ask too, I prefer to keep it simple and hard code a sensible default.

[franck-boullier]

I prefer to keep it simple and hard code a sensible default.

I agree with that statement

What I disagree with is the assumption that uneet-dev is "a sensible default" <-- it is not as the user can be working on

• a different installation (Unee-T INS instead of Unee-T)
• a different environment (DEMO or PROD instead of DEV)

uneet-dev is NOT a sensible default.
Maybe we can use your-aws-profile-for-this-envronment-of-this-unee-t-installation instead of uneet-dev?

[kaihendry]

A different installation? Why did you fork everything then? https://github.com/Unee-T-INS/apienroll/blob/master/main.go#L48

When you want another environment like uneet-demo or uneet-prod, the idea is you deploy into the cloud with that AWS_PROFILE set and you run the code in that environment. But when you work locally, you work from the dev.

your-aws-profile-for-this-envronment-of-this-unee-t-installation is not going to be in your ~/.aws/config. The idea is a sensible development default would.

[franck-boullier]

Why did you fork everything then?

Because there was a shit ton of hardcoded values that made it impossible to deploy the Unee-T INS codebase <--- we had edit each of these hardcoded values and I'm now trying to replace all these with variables so we can use the same repo for any Unee-T installation.

[franck-boullier]

When you want another environment like uneet-demo or uneet-prod,

Environment (DEV, DEMO, PROD) is NOT the same as Installation (Unee-T, Unee-T INS, etc...).
Each installation ( Unee-T, Unee-T INS, Unee-T XYZ, etc...) will eventually have 3 different environments (DEV, PROD, DEMO).

[franck-boullier]

your-aws-profile-for-this-envronment-of-this-unee-t-installation is not going to be in your ~/.aws/config. The idea is a sensible development default would.

what about uneet-local-dev <--- adding "local" makes it obvious that this is NOT the same as uneet-dev (which is what we use when we deploy in AWS with Travis).

[kaihendry]

Because there is no such AWS_PROFILE (and corresponding account) as uneet-local-dev ?

[franck-boullier]

Because there is no such AWS_PROFILE as uneet-local-dev ?

I'm confused... This is the user's prerogative to setup his/her AWS profile on his local machine as he/she sees fit so why will this be an issue???

[kaihendry]

There is ${INSTALLATION_ID}-dev that should be in place already. Why can't that be used for local development? I am not sure what you are expecting a developer to do. Create another account just for local development?

When I say local development, you generally (since these things are lambdas) are interfacing with AWS API endpoints.

[franck-boullier]

There is ${INSTALLATION_ID}-dev that should be in place already. Why can't that be used for local development?

I see no issue with using ${INSTALLATION_ID}-dev for local development.