Skip to content

daemon: ImageService.LogImageEvent: pass through context#49014

Merged
thaJeztah merged 1 commit intomoby:masterfrom
thaJeztah:eventlog_context
Jan 8, 2025
Merged

daemon: ImageService.LogImageEvent: pass through context#49014
thaJeztah merged 1 commit intomoby:masterfrom
thaJeztah:eventlog_context

Conversation

@thaJeztah
Copy link
Copy Markdown
Member

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

@thaJeztah thaJeztah added status/2-code-review kind/refactor PR's that refactor, or clean-up code labels Dec 2, 2024
@thaJeztah thaJeztah added this to the 28.0.0 milestone Dec 2, 2024
func (i *ImageService) LogImageEvent(ctx context.Context, imageID, refName string, action events.Action) {
attributes := map[string]string{}

img, err := i.GetImage(ctx, imageID, backend.GetImageOpts{})
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Wonder if this needs some WithoutCancel as it's called on defer in various cases

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think it depends on the case. The only usage in defer I see now is: https://github.com/moby/moby/pull/49014/files#diff-911a739572dfba17ed589736bce4dc155519a814c86a4c8d72a6ae556feab63bR67

Which definitely would need a WithoutCancel, but I think it should be done on the caller side.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yeah, makes sense; I first peeked at the code below this line, and it should handle cancelled contexts gracefully (in which case it just skips image-labels in the event), so probably still would be ok.

Looking at that one case where we use defer, it looks like it doesn't have to be a defer, so perhaps I'll just move it to the end, and add a WithoutCancel().

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

OTOH, given our current usages, it would make sense to make LogImageEvent non-cancelable by default.
Mostly my thinking is: if we're calling this function, then something already happened, so we could be missing an event while the actual effect will not be rolled back.

UNLESS, the calling function would actually be able to roll-back the effects that the event advertises.
However, I don't think it would make much sense to roll back in case the operation gets cancelled just at the time of logging the event.. As it only really happens after everything has already been done.

So, given the above, I think it's also fine to just slap a ctx = context.WithoutCancel(ctx) at the top of LogImageEvent

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Yeah, perhaps that makes sense. My slight concern was if the GetImage( would take a long time; would that be problematic? (just for the extra metadata) But we already do so before this PR, so I guess this would not make a difference here.

@thaJeztah
Copy link
Copy Markdown
Member Author

LOL; probably works better if I stage all changes 🙈 😂

Comment thread daemon/containerd/image_tag.go Outdated
Comment on lines +83 to +91
if !creatingDangling {
ctx := context.WithoutCancel(ctx)
defer i.LogImageEvent(string(newImg.Target.Digest), imageFamiliarName(newImg), events.ActionTag)

if err := i.images.Delete(ctx, danglingName); err != nil {
if !cerrdefs.IsNotFound(err) {
logger.WithError(err).Warn("unexpected error when deleting dangling image")
}
}
}

i.LogImageEvent(ctx, string(newImg.Target.Digest), imageFamiliarName(newImg), events.ActionTag)
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Double check if this change is still correct now that the if !creatingDangling { condition was added

Copy link
Copy Markdown
Contributor

@vvoland vvoland Jan 8, 2025

Choose a reason for hiding this comment

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

No, it should only be logged if !creatingDangling. Otherwise a tag event will be emitted when a dangling image is created (in this case, only create should be emitted).

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Ah, thx! I'll update. I confused myself for a bit when looking at the diff again after rebasing.

Comment on lines +11 to +12
func (i *ImageService) LogImageEvent(ctx context.Context, imageID, refName string, action events.Action) {
ctx = context.WithoutCancel(ctx)
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

I moved the WithoutCancel into these functions (as we were discussing above)

Comment on lines +12 to +13
func (i *ImageService) LogImageEvent(ctx context.Context, imageID, refName string, action events.Action) {
ctx = context.WithoutCancel(ctx)
Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

Same here

@thaJeztah thaJeztah merged commit 50212d2 into moby:master Jan 8, 2025
@thaJeztah thaJeztah deleted the eventlog_context branch January 8, 2025 16:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/refactor PR's that refactor, or clean-up code status/2-code-review

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants