Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-21916

SQuaSH upload of Gen 3 Measurements

    XMLWordPrintable

    Details

      Description

      The existing upload script (dispatch_verify.py) assumes that metric values have been persisted in Job objects. Once we can store metric values in Gen 3 repositories, we need to be able to read those as part of the upload process.

      Story point value assumes that using Gen 3 Butler inside something that's not a PipelineTask is difficult.

        Attachments

          Issue Links

            Activity

            Hide
            krughoff Simon Krughoff added a comment -

            Looks great. I have not tested it explicitly, but since the interfaces are all preserved in the mertric_pipeline_tasks repository, I don't see any reason why these changes would cause problems

            Show
            krughoff Simon Krughoff added a comment - Looks great. I have not tested it explicitly, but since the interfaces are all preserved in the mertric_pipeline_tasks repository, I don't see any reason why these changes would cause problems
            Hide
            krzys Krzysztof Findeisen added a comment - - edited
            Show
            krzys Krzysztof Findeisen added a comment - - edited PRs are verify#77 and metric-pipeline-tasks#66 .
            Hide
            krzys Krzysztof Findeisen added a comment -

            Thanks for the tip, but given that rebasing the double-branches is excruciatingly painful, I'd like to minimize the number of changes I need to account for when I do so. I'll open PRs as soon as Jenkins finishes.

            Show
            krzys Krzysztof Findeisen added a comment - Thanks for the tip, but given that rebasing the double-branches is excruciatingly painful, I'd like to minimize the number of changes I need to account for when I do so. I'll open PRs as soon as Jenkins finishes.
            Hide
            krughoff Simon Krughoff added a comment -

            Sure, forking seems reasonable. FWIW, it's going to move to the lsst org in the next week or so, if you'd prefer to just wait.

            Show
            krughoff Simon Krughoff added a comment - Sure, forking seems reasonable. FWIW, it's going to move to the lsst org in the next week or so, if you'd prefer to just wait.
            Hide
            krzys Krzysztof Findeisen added a comment - - edited

            Simon Krughoff, I apparently don't have permissions to push ticket branches to lsst-dmsst/metric-pipeline-tasks. What's the SST procedure for dealing with this? Should I fork?

            For reference, I'm trying to follow https://developer.lsst.io/stack/transferring-code.html.

            Show
            krzys Krzysztof Findeisen added a comment - - edited Simon Krughoff , I apparently don't have permissions to push ticket branches to lsst-dmsst/metric-pipeline-tasks . What's the SST procedure for dealing with this? Should I fork? For reference, I'm trying to follow https://developer.lsst.io/stack/transferring-code.html .

              People

              Assignee:
              krzys Krzysztof Findeisen
              Reporter:
              krzys Krzysztof Findeisen
              Reviewers:
              Simon Krughoff
              Watchers:
              Angelo Fausti, Eric Bellm, Ian Sullivan, Jim Bosch, Krzysztof Findeisen, Simon Krughoff
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: