Re. uploadChunkSize, it may be better for tower/nf to use a dynamically set chunksize by default. Basespace cli does similar I believe.
launch:
computeEnvId: "4woukvRfAz0cGCvZPtncho"
configProfiles: null
configText: null
dateCreated: "2021-08-31T15:57:24.747Z"
entryName: null
id: null
mainScript: null
paramsText: null
pipeline: "https://github.com/pditommaso/hello"
postRunScript: null
preRunScript: null
pullLatest: null
revision: null
schemaName: null
stubRun: null
workDir: "/home/ubuntu/nf-work"
id
is the lauch associated with that pipeline
if you want to launch a pre-configured pipeline, that
id
is the lauch associated with that pipeline
I think I'm missing something incredibly obvious, but I'm not seeing an ID anywhere for the pipeline. I see them for the workspaces, compute environments, etc. But not for the pipelines.
has anybody else come across a recent AWS ECS/Batch failure with NF Tower?
I think that itās related to this email to my org from 23 Aug 2021:
Hello,
Your action is required to avoid potential service interruption once Amazon ECS API request validation improvements take effect on September 24, 2021. We have identified the following API requests to Amazon ECS from your account that could be impacted by these changes:
DescribeContainerInstances
With these improvements, Amazon ECS APIs will validate that the Service and Cluster name parameters in the API match the Cluster and Service name in the ARN.
a recent launch into our Tower Forge infrastructure on AWS yielded this notice from AWS:
Hello,
On Wed, 1 Sep 2021 08:57:30 GMT, all EC2 instances in your Batch compute environment āarn:aws:batch:us-west-2:478885234993:compute-environment/TowerForge-2y3V6L8gnk6kM09yoB0vmS-headā were scaled down. The compute environment is now in an INVALID state due to a misconfiguration preventing the EC2 instances from joining the underlying ECS Cluster. While in this state, the compute environment will not scale up or run any jobs. Batch will continue to monitor your compute environments and will move any compute environment whose instances do not join the cluster to INVALID.
To fix this issue, please review and update/recreate the compute environment configuration. Common compute environment misconfigurations which can prevent instances from joining the cluster include: a VPC/Subnet configuration preventing communication to ECS, incorrect Instance Profile policy preventing authorization to ECS, or a bad custom Amazon Machine Image or LaunchTemplate configuration affecting the ECS agent.
I tried looking in the Nextflow documentation nor searching here, but I didn't see anything along these lines: is there some hidden/secret flag or something that allows you turn on/off sending run 'tracking' to an organisation (vs. your own personal account?)
In other words: generally I want to monitor my runs in a workspace shared with other people in my department, but sometimes if I'm running a 'sensitive' project, I want to keep a given run so that I can monitor in my personal workspace. Is there such a functioanlity to switch this in on and off per run?