Skip to content
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

Logs: Ensure we close goroutine on cancel #13119

Merged
merged 1 commit into from
Sep 22, 2021

Conversation

SimonRichardson
Copy link
Member

@SimonRichardson SimonRichardson commented Jun 29, 2021

The following cleans up the StreamDebugLogs goroutine if
the callee wants to cancel the streaming of the logs.

I noticed the TODO whilst threading through a new debug-log parameter.

QA steps

Test pass.

Bug reference

https://bugs.launchpad.net/juju/+bug/1644084

Copy link
Member

@jameinel jameinel left a comment

Choose a reason for hiding this comment

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

I do wish that there was a reasonable way to test this, but there probably isn't.
But we certainly need to update the now out of date comment from Christian.

api/common/logs.go Outdated Show resolved Hide resolved
ctx, cancel := context.WithCancel(context.TODO())
defer cancel()

logSource, err := w.config.Facade.StreamModelLog(ctx, latestLogTime)
Copy link
Member

Choose a reason for hiding this comment

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

So the net sum of all these changes is just this, right? That if the model migration worker exits before finishing streaming, it will kill the associated goroutine.
Is there a reason to do this around contexts rather than Tombs (which predated context, which is why it is everywhere). I don't have a problem with context, just wondering if we would already have tomb objects around that we weren't properly utilizing.

Copy link
Member Author

Choose a reason for hiding this comment

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

I find they serve slightly different purposes. I tend to think that context.Context gives a better API for passing them, where tombs feel like they're internal implementations.

@SimonRichardson SimonRichardson force-pushed the pass-context branch 2 times, most recently from 9c31602 to b771eec Compare September 21, 2021 16:02
@SimonRichardson SimonRichardson marked this pull request as ready for review September 21, 2021 16:02
@hpidcock hpidcock added the 2.9 label Sep 22, 2021
Copy link
Member

@manadart manadart 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 let's change the description to remove "WIP" status before landing.

The following is a WIP to clean up the StreamDebugLogs goroutine if
the callee wants to cancel the streaming of the logs.

I noticed the TODO whilst threading through a new debug-log parameter.
@SimonRichardson
Copy link
Member Author

$$merge$$

@jujubot jujubot merged commit 91ddd3c into juju:2.9 Sep 22, 2021
jujubot added a commit that referenced this pull request Sep 28, 2021
#13361

Merge from 2.9 to bring forward:
- #13360 from wallyworld/simplestreams-compression
- #13359 from manadart/2.9-lxd-container-images
- #13352 from tlm/aws-instance-profile
- #13358 from jujubot/increment-to-2.9.16
- #13354 from wallyworld/refresh-consume-proxy
- #13353 from wallyworld/cmr-consume-fixes
- #13346 from SimonRichardson/raft-api-client
- #13349 from wallyworld/remove-orphaned-cmrapps
- #13348 from benhoyt/fix-secretrotate-tests
- #13119 from SimonRichardson/pass-context
- #13342 from SimonRichardson/raft-facade
- #13341 from ycliuhw/feature/quay.io

Conflicts (easy resolution):
- apiserver/common/crossmodel/interface.go
- apiserver/errors/errors.go
- apiserver/params/apierror.go
- apiserver/testserver/server.go
- scripts/win-installer/setup.iss
- snap/snapcraft.yaml
- version/version.go
@SimonRichardson SimonRichardson deleted the pass-context branch June 22, 2023 15:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
5 participants