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
Harmonize extract with API logic #3473
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.
Still need to review the tests, but here's the first installment.
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 that there are a couple of tests with broken mocking. Other than that, it's mostly nits and small stuff (and one suggestion).
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. There's a nit or two, and I've got some coding suggestions (one of which might not actually be an improvement... 😊), and there are some unit test gaps/anomalies, but nothing that I feel like block the merge. So, see what you think.
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 enough...although there are two open items from my last pass and two more from this one. 🙂
PBENCH-1194 Rework Tarball inventory access to avoid the nascent cache map so that we can rely on this inside the Pbench Server process where tarballs haven't been unpacked. This also fixes some incompatibilities in the Quisby APIs which relied on the older extract semantics. In order to avoid stale streams on the `inventory` API I encapsulated the `extractfile` stream into an object that can behave as a stream but will close both the stream and tarball when done: this is deferred until Flask tears down the Response object. Finally, I've added functional tests validating the `contents`, `inventory`, `visualize`, and `compare` APIs so we'll catch any further infrastructure "drift" that might affect them.
This is in a separate commit; because I keep putting this off in favor of minimizing review complication, but I really want to do it because the test grew beyond "put" way back once I realized we couldn't set real dependencies between test files...
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 enough , as long as you're at peace with the open items above.
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 thought I'd posted both of these responses long ago: I wonder how that happened? In any case, I don't consider either of these to be "open issues" regardless of any minor alternative preferences you might entertain. 😆
PBENCH-1204 This stems from a request from the UI to help optimize a partial refresh after using the relay upload dialog, by providing identification of the new dataset. Although a client using the traditional `PUT /upload` already knows the name and MD5, the returned information may be helpful. This is a DRAFT partly because I added a validation of the new information to the functional test, which I've renamed in distributed-system-analysis#3473 ... I'll do that merge here after it's gone in. It's also DRAFT because while I like the idea of including URIs (and in particular this addresses a certain request regarding accessibility of the tarball), I'm not really sure which URIs to include or in what form. I'm certain that one or two people might possibly have opinions on this subject!
PBENCH-1204 This stems from a request from the UI to help optimize a partial refresh after using the relay upload dialog, by providing identification of the new dataset. Although a client using the traditional `PUT /upload` already knows the name and MD5, the returned information may be helpful. This is a DRAFT partly because I added a validation of the new information to the functional test, which I've renamed in distributed-system-analysis#3473 ... I'll do that merge here after it's gone in. It's also DRAFT because while I like the idea of including URIs (and in particular this addresses a certain request regarding accessibility of the tarball), I'm not really sure which URIs to include or in what form. I'm certain that one or two people might possibly have opinions on this subject!
PBENCH-1194
Rework Tarball inventory access to avoid the nascent cache map so that we can rely on this inside the Pbench Server process where tarballs haven't been unpacked.
This also fixes some incompatibilities in the Quisby APIs which relied on the older extract semantics.
In order to avoid stale streams on the
inventory
API I encapsulated theextractfile
stream into an object that can behave as a stream but will close both the stream and tarball when done: this is deferred until Flask tears down the Response object.Finally, I've added functional tests validating the
contents
,inventory
,visualize
, andcompare
APIs so we'll catch any further infrastructure "drift" that might affect them.NOTE: I renamed the
test_put.py
functional test file totest_datasets.py
. I've put this off many times to avoid over-complicating reviews, so this time I just did it in a separate commit. All the real changes are in the first commit, and (just) the rename is in the second commit.