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

System to mount Nextflow Tower configuration #51

Merged
merged 12 commits into from
Sep 1, 2021
Merged

Conversation

tthyer
Copy link
Contributor

@tthyer tthyer commented Aug 27, 2021

  • Add an S3 bucket that will be populated with configuration file(s)
  • Add an EFS file system that will be mounted into Tower docker containers to obtain configuration
  • Add DataSync task that will sync the S3 bucket file(s) to the EFS file system

WORKFLOWS-38

- path: /opt/nextflow/tower.yml
content: |
{{ sceptre_user_data.TowerConfigFileContents|indent(14) }}
permissions: '0755'
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is removed. A real file to manage it now exists in the repo. The real file is uploaded to an S3 bucket, which is then synced to the EFS volume with a DataSync task.

@@ -175,7 +175,7 @@ Resources:
ServiceScalingTarget:
Type: AWS::ApplicationAutoScaling::ScalableTarget
Properties:
MaxCapacity: 1
MaxCapacity: 2
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an attempt to get the ASG to grow when we roll out a new TaskDefinition and need to replace the old, but it doesn't resize. I've read that ASG autosizing gets turned off when a stack is deploying but can't recall where. There is a separate issue to address that problem.

auth:
github:
allow-list:
- tess.thyer@sagebionetworks.org
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

follow-up PR will add valid github email addresses

@tthyer tthyer marked this pull request as ready for review August 27, 2021 21:18
@tthyer tthyer requested a review from a team as a code owner August 27, 2021 21:18
@tthyer tthyer requested a review from a team August 27, 2021 21:19
Copy link
Contributor

@BrunoGrandePhD BrunoGrandePhD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! 🚀

BucketName: {{ stack_name }}
AdminArns:
- !stack_output_external workflows-nextflow-ci-service-account::ServiceRoleArn
- arn:aws:iam::035458030717:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Administrator_580e9f32ac55c4e7
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Assuming that you approve and merge #50, you can use this instead.

Suggested change
- arn:aws:iam::035458030717:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Administrator_580e9f32ac55c4e7
- {{stack_group_config.sso_admin_role.arn}}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it happens, AdminArns were removed, but will definitely be using that stack_group_config field elsewhere

Comment on lines +25 to +27
OwnershipControls:
Rules:
- ObjectOwnership: BucketOwnerPreferred
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit (i.e. optional): Technically not needed here because cross-account write-access isn't enabled in the bucket policy, but it doesn't hurt to have this here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh good point

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

presumably this is now relevant

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since there is cross-account access happening, that is

config/develop/nextflow-efs-file-system.yaml Outdated Show resolved Hide resolved
@@ -0,0 +1,15 @@
# {% set stack_name = "nextflow-tower-config-bucket" %}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think you need to uncomment?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You don't! Cool huh?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess that's because # isn't a comment in jinja however it looks like a comment because it's a .yaml file. anyways might be nice to uncomment for readability but your call.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zaro0508 Sadly, in order for this to stay a yaml file I would have to disable yamllint for the whole file. I thought that using the comment trick was a convenient workaround. Instead I have converted this into a j2 file. I don't really like that solution either because now I'm not getting the benefit of linting either. What do you normally do so that you get linted but can add jinja statements?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh, now that i know the intention behind the comment then i guess the comment is better than converting file to j2 to bypass the linter. The other option you can do is to keep as j2 but also enable a jinja linter, here's how to do it with github actions https://github.com/Sage-Bionetworks-IT/organizations-infra/blob/master/.github/workflows/aws-deploy.yaml#L19

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zaro0508 In that case I'll go back to my comment. I would actually like having a jinja linter in place but it should go into pre-commit, not in the github action.

config/develop/nextflow-tower-config-bucket.yaml Outdated Show resolved Hide resolved
AvailabilityZoneName: us-east-1a
BackupPolicy:
Status: DISABLED
Encrypted: false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wondering why not enable encryption? i think we need to encrypt all storage to be PHI compliant?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not gonna do anything about this one?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zaro0508 Do you think I need to encrypt a bucket that only contains config files for Tower, i.e. not PHI?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess not but @ahayden might think otherwise. anyways it would be pretty easy just to set encryption using the default key correct? i think we only require AES encryption on s3 buckets so i'm guessing default key here is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@zaro0508 Ok, will do this in a follow-up PR later today

templates/nextflow-ecs-task-definition.yaml Outdated Show resolved Hide resolved
templates/nextflow-tower-config-bucket.yaml Outdated Show resolved Hide resolved
@tthyer
Copy link
Contributor Author

tthyer commented Sep 1, 2021

@zaro0508 I have to deploy these changes in order to unblock other work, but if you have more comments I can address them in a follow-up PR

@tthyer tthyer merged commit 985b08b into main Sep 1, 2021
@tthyer tthyer deleted the WORKFLOWS-38/efs branch September 1, 2021 15:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants