You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Escaped project name does not work at least for AWS in a Nebari deploy. The rule appends 'a' to project_name when it starts with 'aws' but doesn't use it consistently. For example, the TF state bucket does not use escaped name (so bucket name is, e.g. aws-mybucket) but then subsequent stages are configured to look for the escaped project name (e.g. aaws-mybucket) and fails.
Cloud naming rules can vary and change for any given service, so in general it may be preferable to use the 'escaped_project_name' only for unchanging resources at the very beginning of a Nebari deploy - such as the TF state objects - and any subsequent name 'escaping' should be handled by the plugin creating the resource. The current architecture implies that we should be updating the escaped_project_name so that it is the lowest common denominator for allowed names for any resource in the given cloud at any time.
Additionally, because (1) S3 bucket names are globally unique and, (2) the TF state bucket is named [project_, only one Nebari project with a certain name and namespace can ever exist in a given AWS partition (commercial, GovCloud, etc.). Recommend appending a random hex to the bucket name. Note, this hex will need to be available outside of 01-terraform-state so that subsequent stages can reference it for configuring TF backend.
Expected behavior
Legal project names should deploy successfully
OS and architecture in which you are running Nebari
Ubuntu 22.04 amd64
How to Reproduce the problem?
There are lots of permutations, but here's one example. The bucket is created successfully as awstestproject-dev-terraform-state but subsequent stages look for aawstestproject-dev-terraform-state
Error during 02-infrastructure:
[terraform]: │ Error: Failed to get existing workspaces: S3 bucket does not exist.
[terraform]: │
[terraform]: │ The referenced S3 bucket must have been previously created. If the S3 bucket
[terraform]: │ was created within the last minute, please waitfor a minute or two and try
[terraform]: │ again.
[terraform]: │
[terraform]: │ Error: NoSuchBucket: The specified bucket does not exist
[terraform]: │ status code: 404, request id: T4VS2TJTHFFN83RC, host id: hBJcE4nVd4uo42IB9JmqwXtumk15jGMCUuwomB7MvHeRKaXlTNEQ5sIx2nHtmUMcNy3xcEzWBhI=
Versions and dependencies used.
No response
Compute environment
None
Integrations
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Describe the bug
Escaped project name does not work at least for AWS in a Nebari deploy. The rule appends 'a' to project_name when it starts with 'aws' but doesn't use it consistently. For example, the TF state bucket does not use escaped name (so bucket name is, e.g. aws-mybucket) but then subsequent stages are configured to look for the escaped project name (e.g. aaws-mybucket) and fails.
Cloud naming rules can vary and change for any given service, so in general it may be preferable to use the 'escaped_project_name' only for unchanging resources at the very beginning of a Nebari deploy - such as the TF state objects - and any subsequent name 'escaping' should be handled by the plugin creating the resource. The current architecture implies that we should be updating the escaped_project_name so that it is the lowest common denominator for allowed names for any resource in the given cloud at any time.
Additionally, because (1) S3 bucket names are globally unique and, (2) the TF state bucket is named [project_, only one Nebari project with a certain name and namespace can ever exist in a given AWS partition (commercial, GovCloud, etc.). Recommend appending a random hex to the bucket name. Note, this hex will need to be available outside of 01-terraform-state so that subsequent stages can reference it for configuring TF backend.
Expected behavior
Legal project names should deploy successfully
OS and architecture in which you are running Nebari
Ubuntu 22.04 amd64
How to Reproduce the problem?
There are lots of permutations, but here's one example. The bucket is created successfully as awstestproject-dev-terraform-state but subsequent stages look for aawstestproject-dev-terraform-state
nebari init aws -p awstestproject
nebari deploy -c nebari-config.yaml
Command output
Versions and dependencies used.
No response
Compute environment
None
Integrations
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: