-
Notifications
You must be signed in to change notification settings - Fork 24
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
Conversation
- path: /opt/nextflow/tower.yml | ||
content: | | ||
{{ sceptre_user_data.TowerConfigFileContents|indent(14) }} | ||
permissions: '0755' |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
- arn:aws:iam::035458030717:role/aws-reserved/sso.amazonaws.com/AWSReservedSSO_Administrator_580e9f32ac55c4e7 | |
- {{stack_group_config.sso_admin_role.arn}} |
There was a problem hiding this comment.
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
OwnershipControls: | ||
Rules: | ||
- ObjectOwnership: BucketOwnerPreferred |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh good point
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
@@ -0,0 +1,15 @@ | |||
# {% set stack_name = "nextflow-tower-config-bucket" %} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
AvailabilityZoneName: us-east-1a | ||
BackupPolicy: | ||
Status: DISABLED | ||
Encrypted: false |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
…they already have this access
…to a j2 to avoid commenting jinja statement
ea2bbef
to
0fe6432
Compare
@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 |
WORKFLOWS-38