Add Amazon S3Files support for Gen3Workflow - #170
Conversation
|
The style in this PR agrees with This formatting comment was generated automatically by a script in uc-cdis/wool. |
Coverage Report for CI Build 30515455027Coverage increased (+1.6%) to 84.375%Details
Uncovered ChangesNo uncovered changes found. Coverage Regressions54 previously-covered lines in 4 files lost coverage.
Coverage Stats
💛 - Coveralls |
Integration Tests on Kind
|
Integration TestsTest summary after running integration tests
Test summary after rerunning failed integration tests
Please find the detailed integration test report here Please find the detailed integration test report after rerunning failed tests here Please find the Github Action logs here |
Integration Tests on Kind
|
Integration Tests on Kind
|
Integration TestsTest summary after running integration tests
Test summary after rerunning failed integration tests
Please find the detailed integration test report here Please find the detailed integration test report after rerunning failed tests here Please find the Github Action logs here |
Integration TestsFailed to Prepare CI environment Please find the Github Action logs here |
| s3_client.put_bucket_lifecycle_configuration( | ||
| clients.s3_client.put_bucket_lifecycle_configuration( | ||
| Bucket=user_bucket_name, | ||
| LifecycleConfiguration={ |
There was a problem hiding this comment.
might be worth looking into NoncurrentVersionTransition/NoncurrentVersionExpiration to remove versions earlier than the default LifecycleConfiguration expiration
There was a problem hiding this comment.
Thank you, it was nice to know this param exists. I've arbitrarily set it to 3 days. I don't think we really need to preserve older versions of objects any longer. It can be a simple hardcoded constant value of 3. Let me know if you think it would be better if it is a configured value? Or maybe a fraction of configured expiration days -- like (1/3 * expiration_days)
There was a problem hiding this comment.
Hardcoded is fine, it's not very important. I might even have set it to 0 or 1 haha
| # TODO: Determine if these need to be configurable. | ||
| eks_sg_names = [ | ||
| f"{config["EKS_CLUSTER_NAME"]}_EKS_workers_sg", | ||
| f"{config["EKS_CLUSTER_NAME"]}_EKS_nodepool_jupyter_sg", | ||
| ] |
There was a problem hiding this comment.
this does seem too hardcoded, specifically the reference to jupyter - where do these come from?
There was a problem hiding this comment.
These SG names are derived from Terraform — see here cloud.tf#L195 and here cloud.tf#L469.
I'm still torn on whether this security group logic should live in gen3-workflow or in gen3-terraform — would appreciate your thoughts.
- These security groups only need to be created once per EKS cluster, and today they're created the first time a user in that cluster triggers a create-filesystem call. That one-time, idempotent nature makes moving this to an IaC tool (gen3-terraform) feel like the right home.
- That said, this logic is only relevant to gen3-workflow, and it doesn't feel right to bake application-specific logic into a generic tool.
Coming to the SG names, they depend on which SGs get assigned to nodes, that are used for the tasks based on the ENABLE_OPTIMIZED_NODE_SCHEDULING config flag.
There was a problem hiding this comment.
Sorry for the maybe naive questions:
Does terraform support conditional setup? Only set this up if gen3-workflow is enabled, or if gen3-workflow.s3files is enabled?
Do we need both config["EKS_CLUSTER_NAME"]}_EKS_workers_sg and {config["EKS_CLUSTER_NAME"]}_EKS_nodepool_jupyter_sg? Why would we need to use the jupyter security group?
If we need both I think leaving it here is ok too but it'd be nice to get these values programmatically if that's possible 🤔
There was a problem hiding this comment.
Not naive at all.
Does terraform support conditional setup? Only set this up if gen3-workflow is enabled, or if gen3-workflow.s3files is enabled?
I'm not very sure. I don't think terraform looks into helm values in any way while building, so I don't think it is feasible to use gen3-workflow.enabled
Do we need both config["EKS_CLUSTER_NAME"]}_EKS_workers_sg and {config["EKS_CLUSTER_NAME"]}_EKS_nodepool_jupyter_sg?
Yes, we needed both of these (for devplanetv2 -- at least).
These values were pulled using the following steps,
1. Manually get the nodes where the pods could be deployed -- we use role=workflow & role=gpu
2. Identify what security groups are assigned to these nodes karpenter-config-resources-workflow.yaml#L38-L44 & karpenter-config-resources-gpu.yaml#L29C2-L36C81
3.Manually narrow down the main security group that has all the inbound and outbound rules and add the names of those groups here.
Why would we need to use the jupyter security group?
Jupyter security group is assigned to the nodes which have role=workflow in devplanetv2 devplanetv2/cluster-values/cluster-values.yaml#L107-L114
it'd be nice to get these values programmatically if that's possible
Getting these values programmatically might be difficult. Contrarily, we could make a convention, saying nodes allocated with role=workflow to be assigned with certain security group naming format.
I think the best idea (for now!) would be to make these configurable, and add instructions in deployment documentation on how to fetch them.
I was a bit skeptical while building these, because I wasn't sure what values do these security groups get when we develop user specific nodes.
TBH, I was not ready to make these hardcoded, just wanted to get another dev's opinion on whether to keep these in gen3-workflow at all, before implementing them.
There was a problem hiding this comment.
Gotcha, using those nodes is temporary anyway, since the long-term plan is to create a nodepool per user for cost tracking. At that point the nodepools will likely be created by gen3-workflow and the security groups too, so we may be able to untangle this then. In the meantime configuring it manually sounds OK... Let's document it
Integration Tests on KindTest summary after running integration tests
Test summary after rerunning failed integration tests
|
| # TODO: Determine if these need to be configurable. | ||
| eks_sg_names = [ | ||
| f"{config["EKS_CLUSTER_NAME"]}_EKS_workers_sg", | ||
| f"{config["EKS_CLUSTER_NAME"]}_EKS_nodepool_jupyter_sg", | ||
| ] |
There was a problem hiding this comment.
Sorry for the maybe naive questions:
Does terraform support conditional setup? Only set this up if gen3-workflow is enabled, or if gen3-workflow.s3files is enabled?
Do we need both config["EKS_CLUSTER_NAME"]}_EKS_workers_sg and {config["EKS_CLUSTER_NAME"]}_EKS_nodepool_jupyter_sg? Why would we need to use the jupyter security group?
If we need both I think leaving it here is ok too but it'd be nice to get these values programmatically if that's possible 🤔
Integration TestsFailed to Prepare CI environment Please find the Github Action logs here |
Integration Tests on Kind
|
Integration TestsFailed to Prepare CI environment Please find the Github Action logs here |
Integration Tests on Kind
|
Integration TestsTest summary after running integration tests
Test summary after rerunning failed integration tests
Please find the detailed integration test report here Please find the detailed integration test report after rerunning failed tests here Please find the Github Action logs here |
Integration Tests on Kind
|
Integration TestsTest summary after running integration tests
Test summary after rerunning failed integration tests
Please find the detailed integration test report here Please find the detailed integration test report after rerunning failed tests here Please find the Github Action logs here |
| eks_sg_names = config.get("EKS_SECURITY_GROUP_NAMES") | ||
| if not eks_sg_names: | ||
| eks_sg_names = [f"{config["EKS_CLUSTER_NAME"]}_EKS_workers_sg"] |
There was a problem hiding this comment.
instead of setting a default here, we could add a validation step in the config validation: "if s3files is enabled, len(EKS_SECURITY_GROUP_NAMES) must be >= 1".
not a big deal. i'm just not sure the default will always make sense
There was a problem hiding this comment.
I like this idea. But I would like to get it done in a different PR.
Integration Tests on Kind
|
Link to JIRA ticket if there is one: MIDRC-1314
New Features
/storage/setupresponse.Breaking Changes
Bug Fixes
Improvements
Dependency updates
Deployment changes