Skip to content

Conversation

ebellm
Copy link
Contributor

@ebellm ebellm commented Mar 21, 2022

No description provided.

@ebellm ebellm requested a review from kfindeisen March 21, 2022 23:52
@ebellm ebellm force-pushed the tickets/DM-34017 branch from 3372548 to d219100 Compare March 23, 2022 00:02
Copy link
Member

@kfindeisen kfindeisen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, though the current collection handling will cause problems in integration. I also agree with both of K-T's points.

result = pipeline.run(register_dataset_types=False)
# If this is a fresh (local) repo, then types like calexp,
# *Diff_diaSrcTable, etc. have not been registered.
result = pipeline.run(register_dataset_types=True)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we do that type registration in prep_butler, possibly as part of _prep_collections?

Copy link
Member

@kfindeisen kfindeisen Mar 24, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That would require a list of every connection used by every task in the pipeline (or a traversal of the pipeline itself, which is what I assume the executor does).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't the QuantumGraph know that, though?

def __init__(self, central_butler: Butler, image_bucket: str, instrument: str,
butler: Butler,
prefix: str = "gs://"):
prefix: str = "s3://"):
Copy link
Member

@kfindeisen kfindeisen Mar 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is no longer necessary after the last weekly, and I've removed S3 support from the Cloud service [restored]. (Sorry for not realizing this branch was using it!)

* remove PIPELINE_MAP
* Move code out of init and _prep_butler into _prep_pipeline
@parejkoj
Copy link
Contributor

@kfindeisen : please have another (final?) look. I'll try to combine commits somewhat post-review

Copy link
Member

@kfindeisen kfindeisen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, but please make sure the tests pass (the flake8 error should have appeared locally), and please avoid special-casing the unit tests. There's not much point to having them if they're free to make different assumptions from the prototype environment.


# Refresh butler after configuring it, to ensure all required
# dimensions are available.
# collections are available.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one really should be "dimensions"; my earlier correction applied only to the comment in _prep_collections.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it stands, init_butler has nothing to do, since we have to put off all the work for prep_butler right now. We can leave it around while we wait for middleware fixes, etc. that will let us do more things here, but I've added a note to the method docs about whether it's worth keeping the method.

Copy link
Contributor

@parejkoj parejkoj Mar 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My above comment is now out of date, since Jim gave us a fix for the instrument.register problem, so _init_butler now has things to do.

Comment on lines 234 to 238
mock_executor.from_pipeline.assert_called_once_with(
self.interface.pipeline,
where=f"detector={self.next_visit.detector} and exposure in (1)",
butler=self.interface.butler
)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a useful test (with maybe some more use of mock.ANY), since the restriction to a specific pipeline and data ID is a key part of this method's purpose. It seems a shame to remove it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm actually building the pipeline now, though: that's how I discovered some of the bugs (like DM-34202). The only thing being mocked is run.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, but does that tell you that you built the right executor, or just any executor? The where clause seems like it would be hard to test by any means other than direct introspection.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the work we did today, I believe we're now doing a good job testing that where.

Thanks to Jim Bosch for the `elements=[]` fix for this, allowing us to
register the instrument on init.
However, the skymap has a similar problem that is harder to work around.
fixup local appipe
We need valid metadata for defineVisits.
@parejkoj
Copy link
Contributor

On the team-coding call, we all agreed on not trying to clean up the git history on this across the Eric->John handoff. I cleaned up my own commits as best I could.

@parejkoj parejkoj merged commit bc7a2d8 into main Mar 30, 2022
@parejkoj parejkoj deleted the tickets/DM-34017 branch March 30, 2022 22:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants