Skip to content

Cloud formation stack for setup #2

Open

Description

@bethac07

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

Activity

  1. ErinWeisbart commented on Jan 20, 2023

    @ErinWeisbart
    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.

  2. ErinWeisbart commented on Mar 15, 2023

    @ErinWeisbart
    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions