-
Notifications
You must be signed in to change notification settings - Fork 0
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
[GH-1629] TerraExecutor gets method configuration version from Firecloud #585
[GH-1629] TerraExecutor gets method configuration version from Firecloud #585
Conversation
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.
But "throw or warn" seems an odd combination.
Why choose one over the other?
Why throw from terra-executor-validate-request-or-throw
but not from update-method-configuration!
?
Good question. I left this PR a draft for this reason. Stay tuned, but I expect to remove this check entirely from the request validation (no more throwing). One of the more annoying parts of staged workload creation is asking Firecloud for the method configuration's current version, then copying that into the request. We can remove that requirement and save the method configuration's version ourself during workload creation. There is value in the life of a workload of knowing when the version misaligns with what we expect in the absence of a Terra method config audit trail, and that is worth a warning. |
(defn ^:private warn-on-method-config-version-mismatch | ||
"Log warning if `methodConfigVersion` does not match `expected`." | ||
[{:keys [methodConfigVersion] :as methodconfig} expected] | ||
(when-not (= expected methodConfigVersion) |
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.
=
instead of ==
because methodConfigVersion
is nullable now, if skipping validation of the TerraExecutor
request on workload creation.
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.
Because of skipValidation
?
(-How would one type that?-)
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.
Yes, if the request has skipValidation
set then methodConfigVersion
is initially unset in the executor.
@@ -75,39 +72,6 @@ Prerequisites: | |||
- The method configuration must exist within `workspace` prior to | |||
workload creation. | |||
|
|||
#### `methodConfigurationVersion` |
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.
Fun to remove this.
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.
Nice. Thanks.
(defn ^:private warn-on-method-config-version-mismatch | ||
"Log warning if `methodConfigVersion` does not match `expected`." | ||
[{:keys [methodConfigVersion] :as methodconfig} expected] | ||
(when-not (= expected methodConfigVersion) |
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.
Because of skipValidation
?
(-How would one type that?-)
(is executor) | ||
(is (== testing-method-configuration-version | ||
(:methodConfigurationVersion executor))))] | ||
(testing "request without method configuration version" |
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.
Deliberately excluding nil
above?
Rerun of system tests with latest changes passes:
|
GH-1629 TerraExecutor gets method configuration version from Firecloud (#585) GH-1553 GH-1604 Add error handling to Slack service (#584) GH-1628 Look at the first 7 workloads returned in test-workflows-by-filters. (#583) GH-1617 Consistent workload representation for logs (#579) GH-1624 Rename covid -> staged in code, docs (#580)
GH-1629 TerraExecutor gets method configuration version from Firecloud (#585) GH-1553 GH-1604 Add error handling to Slack service (#584) GH-1628 Look at the first 7 workloads returned in test-workflows-by-filters. (#583) GH-1617 Consistent workload representation for logs (#579) GH-1624 Rename covid -> staged in code, docs (#580)
GH-1629 TerraExecutor gets method configuration version from Firecloud (#585) GH-1553 GH-1604 Add error handling to Slack service (#584) GH-1628 Look at the first 7 workloads returned in test-workflows-by-filters. (#583) GH-1617 Consistent workload representation for logs (#579) GH-1624 Rename covid -> staged in code, docs (#580)
Purpose
Previously, when creating a staged workload's
TerraExecutor
the caller first needed to query Firecloud API directly for their method configuration's present version. The intention was to make up for a lack of audit trail for method configuration changes, to make debugging easier in the case that workflows started failing after a change.User feedback indicated that this Firecloud fetch was one of the more annoying start-up costs of launching a staged workload, without much benefit. I agree!
Now, we save the method configuration's version from Firecloud on workload creation rather than making the caller do the fetch themselves. When triggering Terra submissions, if the method configuration has an unexpected version we log a warning (previously an error) but proceed with processing.
Changes
TerraExecutor
gets its initial method configuration version from Firecloud, not the user's request.ERROR -> WARNING
.methodConfigurationVersion
references from public-facing docs.Review Instructions
wfl.executor/terra-executor-validate-request-or-throw
.wfl.integration.executor-test/test-validate-terra-executor-with-valid-executor-request
.docs/md/staged-executor.md
and smile.wfl.system.v1-endpoint-test/test-staged-workload
, load the resulting workload, and see that the executor has its method configuration version set.System Tests:
1 known unrelated failure (Slack, ticket):