Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cloud formation stack for setup #2

Open
bethac07 opened this issue Jul 5, 2022 · 2 comments
Open

Cloud formation stack for setup #2

bethac07 opened this issue Jul 5, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@bethac07
Copy link
Contributor

bethac07 commented Jul 5, 2022

Parts of this that I don't think we can/want to automate

  • VPC (already made in default account)
  • subnet (see above)
  • ssh key (the person should do that separately)

Parts of this we may want to automate

  • Role creation for both roles
  • Dead letter queue creation
  • Bucket creation maybe?
    • This would be nice because we could set one up with the right permissions for logging, could pre-set up nice bucket defaults like versioning on, old versions being deleted, intelligent tiering being set up, but I'm not sure if we should enforce this
@bethac07 bethac07 added the enhancement New feature or request label Jul 5, 2022
@ErinWeisbart
Copy link
Member

We talked more about what part of setup does/doesn't make sense to automate. Some recent thoughts against using CDK:

  • Requiring the CDK is a lot more onerous on the user - for example, it requires installing Node and the CDK install tool. Our current setup requires only 1) installing python and one dependency (boto3) and 2) looking things up/doing things in the web console.

  • CDK is optimized for creating and destroying an entire suite of infrastructure at once. Particularly when data storage in S3 is involved, this can be dangerous - we absolutely don’t want a user to think they are “cleaning up” by removing their CDK-created infrastructure after a run and accidentally delete their whole S3 bucket and therefore lose all their data. Additionally, CDK can be challenging to configure if a user already has some of the existing infrastructure (e.g. already uses S3) and wants to use Distributed-Something to read and write from that S3 bucket without creating a new bucket.

This was referenced Mar 14, 2023
@ErinWeisbart
Copy link
Member

I agree that we do not want to automate:
VPC, subnet or ssh key

Role creation is in #28
Dead letter queue creation was addressed in #14

I think bucket creation should be moved to its own issue and we should consider adding it as an optional flag to setup_AWS.py because on the one hand it is nice to provide a bucket setup with all of the configurations nicely in place, but on the other hand it's quite likely that a user has a bucket already in place with configurations they have optimized for other use cases. None of the "nice setup" bucket options actually affect DS, so we certainly don't want to make them required.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants