-
Notifications
You must be signed in to change notification settings - Fork 18
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
[Backend] Improve lifecycle management of the artifact storage migration #1146
Conversation
f4de02c
to
ef87ff7
Compare
ef87ff7
to
770ed7d
Compare
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.
Great work! Left a few comments
@@ -12,6 +12,11 @@ const ( | |||
IntegrationConfigHeader = "integration-config" | |||
IntegrationIDsHeader = "integration-ids" | |||
|
|||
// Storage Migration Headers |
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.
based on some other APIs like https://airflow.apache.org/docs/apache-airflow/stable/stable-rest-api-ref.html#operation/get_dags , I'd suggest using request body to send / capture a json-serialized query parameters
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 don't think any of these are json'd though?
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.
actually you are right, but it looks like they are query parameters (/storage-migrations?limit=5
) tough?
cc @jpurusho65 as you may have better experience on API pattern
@@ -0,0 +1,3 @@ | |||
package tests | |||
|
|||
// TODO |
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.
Just confirming this is an immediate TODO in follow-up PR?
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 will do this as part of this PR.
|
||
// Apply the filters in the following order: status, completedSince, then limit. | ||
if status != nil { | ||
migrations = filterStorageMigrationsByStatus(migrations, *status) |
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.
how hard is it to push these filtering / limit to query layer? I don't have particular concerns on this use case, but if it's something easily built, we can avoid potential pitfalls in future
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.
It's not too hard but it is a little tricky and I felt like there probably aren't enough storage migrations for listing them all to matter.
} | ||
|
||
// Only need to do this if we're committing a transaction. | ||
if txn, ok := db.(database.Transaction); ok { |
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.
What does this block do? It feels like an antipattern to me - all transaction owner (whoever calls txn := db.BeginTx()) should be responsible for calling Commit()
and TxnRollBack()
. I'm confused why we need to access some transaction this helper didn't create itself.
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.
It's a little confusing, I agree. Refactored it so that the transaction definition happens at the top of the function.
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.
Left initial comments, still working through the rest of the PR.
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.
Thanks for addressing comments, nothing major from my end!
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.
Left a couple minor comments, otherwise LGTM
*aq_context.AqContext | ||
|
||
// See the route description above for what each of these filters mean. | ||
status *string |
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.
Why does this need to be a pointer, same with completedSince
?
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.
Those are optional fields that will be left as nil if the request doesn't want to apply those filters. I'll document it here better.
Pre-merge tests already ran, so skipping them when merging in UI changes. |
Lead reviewers: @saurav-c and @likawind.
Describe your changes and why you are making these changes
This is a WIP process PR, but the critical backend parts have been changed and tested. I would like some preliminary feedback on 1) the data model and 2) the updated logic in connect_integration.go to make sure there are no surprises when the rest of the work is fleshed out.
Testing:
I also updated
configure_storage.go
later following the same pattern. Once the latter is updated we'll be able to migrate from S3 back to local.There will be a follow-up for the UI changes, as well as any additional backend routes we need to support those UI changes.
Known issues that I will address (or make tasks for):
storage_migration
table so that only one migration can be ongoing at a time. (Task created)Related issue number (if any)
ENG-2604
Loom demo (if any)
https://www.loom.com/share/e04f228644f24c2eb0b0b583503c8abd
Checklist before requesting a review
python3 scripts/run_linters.py -h
for usage).run_integration_test
: Runs integration testsskip_integration_test
: Skips integration tests (Should be used when changes are ONLY documentation/UI)