Skip to content

Merge annotations#7102

Merged
jrbourbeau merged 4 commits intodask:masterfrom
ian-r-rose:merge-annotations
Jan 27, 2021
Merged

Merge annotations#7102
jrbourbeau merged 4 commits intodask:masterfrom
ian-r-rose:merge-annotations

Conversation

@ian-r-rose
Copy link
Collaborator

@ian-r-rose ian-r-rose commented Jan 22, 2021

  • Tests added / passed
  • Passes black dask / flake8 dask

This is partner to dask/distributed#4406. The motivation there is to unify the implementation of control flow like workers/retries/priority around the newer annotations system. In that PR, we found that the final step of unpacking annotations on the scheduler needed to be a non-shallow merge so that constructing a final annotations structure would allow for different layers to have different annotations. For example, two layers could have retries: { 'a' : 2 } and retries: { 'b': 3 }. With a shallow merge the latter retries would overwrite the former, when in fact we want a result of retries: { 'a': 2, 'b': 3 }.

This implements that deeper-merge for annotations in __dask_distributed_unpack__(). It also moves the default unpacking function from distributed to this package, in order to be more consistent with where other layers have implemented that behavior.

cc @sjperkins @madsbk

@sjperkins
Copy link
Member

This is a good catch @ian-r-rose. LGTM

Copy link
Member

@jrbourbeau jrbourbeau left a comment

Choose a reason for hiding this comment

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

Thanks @ian-r-rose! Just a couple of small comments, otherwise the changes here LGTM

Comment on lines +357 to +358
expanded = cls.expand_annotations(state["annotations"], raw.keys())
cls.merge_annotations(annotations, expanded)
Copy link
Member

Choose a reason for hiding this comment

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

It's not a blocker for merging but with the changes here and in dask/distributed#4406 it looks like we never call expand_annotations without a subsequent call to merge_annotations. Should we combine them into a single method to avoid accidentally calling one without the other?

Copy link
Collaborator Author

@ian-r-rose ian-r-rose Jan 27, 2021

Choose a reason for hiding this comment

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

Yeah, my thought had been to avoid the breaking API change (as noted here), but perhaps the danger of splitting the two functions up is the greater concern.

Copy link
Member

Choose a reason for hiding this comment

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

I agree especially as this will be less of a problem once the API changes mentioned here are implemented: dask/distributed#4406 (comment). Annotations would be expanded (and merged) in Layer.dask_unpack_annotations and derived classes would defer to this implementation in the majority of cases.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Okay, I've combined them into a single method

Copy link
Member

@jrbourbeau jrbourbeau left a comment

Choose a reason for hiding this comment

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

Thanks @ian-r-rose for the fix and @sjperkins for reviewing!

@jrbourbeau jrbourbeau merged commit 9bb586a into dask:master Jan 27, 2021
@ian-r-rose
Copy link
Collaborator Author

Thanks for the reviews @jrbourbeau and @sjperkins!

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.

3 participants