booster icon indicating copy to clipboard operation
booster copied to clipboard

Add randomized suffix to the user's project name

Open NickSeagull opened this issue 3 years ago • 8 comments

This is to avoid S3 errors due to name duplication related to buckets. Also would solve #593 .

Actually, we've faced this in the integration tests, and we did exactly this, but didn't integrate it into core.

NickSeagull avatar Oct 11 '21 11:10 NickSeagull

Hi @NickSeagull , can I take a stab at this?

deepak-sreekumar avatar Oct 20 '21 20:10 deepak-sreekumar

Hi! I was taking a look at this and I have some comments:

we've faced this in the integration tests, and we did exactly this, but didn't integrate it into core.

I think the solution used is:

  1. The application name is my-store and a suffix from a variable name.
  2. The suffix is the first 8 characters of the SHA1 result of git rev-parse HEAD.

This solution works for tests since nothing should change between deploy and nuke/redeploy. But I think we can't rely on this for actual uses of deploy/nuke: if the suffix change (and it will if there is a new commit), we won't be able to find the existing bucket, so it'll be lost and forgotten.

From git, I think the most reliable ID could be the repository path (git remote -v), but it could change (not very common, but it could be a problem if it happens). Another option could be looking at something from AWS (since this is an AWS-related issue). I have very little knowledge here, so I'm not sure if this is even doable, and I guess even this could change.

Borja-Garcia avatar Mar 21 '23 13:03 Borja-Garcia

Maybe a solution could be to tell the user in a message about the issue and instruct them to rename their app to an autogenerated name, with the date of creation for example? For example for an app called my-blog :

Uh oh! AWS doesn't allow naming two buckets in the same way FOR THE ENTIRE WORLD (Can you imagine?)
and apparently, there's someone who named their bucket in the same way as the ones
that Booster generates for your project:

- my-blog-toolkit

Don't fret! The solution is easy, just rename your application in the Booster config file.

If you don't know which name to use, what about:

- my-blog-230324

NickSeagull avatar Mar 24 '23 12:03 NickSeagull

Thanks, @NickSeagull ! I'm not sure how clean it could be to add a random suffix to the user's app name. It shouldn't be an issue if we only use the name internally (like here, to generate names). But if it's somehow public (APIs, documentation,...) I prefer to avoid this solution.

An alternative could be to set a suffix property (similar to appName, repository) since it won't dirty the name. What I don't like about this option is leaving some trash if the provider is changed from AWS to another, but I guess changing the name is similar 😅

Borja-Garcia avatar Mar 24 '23 17:03 Borja-Garcia

The name is only used internally for stack management, API is a uuid-like name generated by AWS or Azure, and no documentation is generated. So it's something completely internal :)

NickSeagull avatar Mar 27 '23 15:03 NickSeagull

So if the name is only used internally, my vote is for following an approach similar to the one Nick proposed above. Catch the error and inform the user with a message where we explain what happened and the way to fix it, either by the user introducing a new appName or accepting the one Booster proposes. But it would be great if the code itself updates the config file with the new appName, is that possible? Something like:

Uh oh! AWS doesn't allow naming two buckets in the same way FOR THE ENTIRE WORLD (Can you imagine?)
and apparently, there's someone who named their bucket in the same way as the ones
that Booster generates for your project:

- my-blog-toolkit  -> this comes from {appName} + "-toolkit"

Don't fret! The solution is easy, just provide a new appName or confirm the one proposed ([my-blog-20230331104604234]): 

The proposed one would be with the current timestamp appended, or the user can introduce a new one. Don't know how feasible is to wait here for an user input and whether we can update the config file automatically.

glammers1 avatar Mar 31 '23 09:03 glammers1

Let's do what you say @glammers1 , but make the suffix something shorter like 230331 instead, as AWS is super picky about name length.

NickSeagull avatar Mar 31 '23 10:03 NickSeagull

@NickSeagull the max length for S3 bucket's name is 63 characters. Right now, -toolkit is using 8 (55 are remaining). If we take 13 for the timestamp we still have 42 for the name.

Regardless of the suffix we add, do we have any length control for the name?

Borja-Garcia avatar Mar 31 '23 13:03 Borja-Garcia