Skip to content

Move Logger/LogCopier out of container#26759

Closed
cpuguy83 wants to merge 1 commit intomoby:masterfrom
cpuguy83:move_logging
Closed

Move Logger/LogCopier out of container#26759
cpuguy83 wants to merge 1 commit intomoby:masterfrom
cpuguy83:move_logging

Conversation

@cpuguy83
Copy link
Copy Markdown
Member

Let's these objects be managed based on container state notifications
rather than directly caching them on the container object.

Adds an object on daemon for pub/sub of various events that can happen
in the daemon, e.g. container is stopped (currelty the only event being
consumed).
This is different from the public facing events API.

This is the first step to remove some of the unnecessary runtime state
from the container object.

Comment thread daemon/logs.go Outdated
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.

This may not be absolutely needed... it really comes down to the logs API endpoint needing to attach to a logger object, which can either be created as needed or use a cached logger.

If we just create loggers for each reader rather than using a cached logger then we will also have to watch for stop notifications while reading logs.

Decided to keep things as they were and keep a cache of loggers rather than creating a new one for each reader.

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'd propose to create new loggers in this object. I found all getLogger + Add stuff pretty hard to follow.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

ping @cpuguy83 😇

Comment thread daemon/logs.go Outdated
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

why a new watch method if we already have c.WaitWithContext()

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.

Oh, I have not seen this.
Ultimately though, I want to get rid of state.waitChan.

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 updated to use this function for now.

Let's these objects be managed based on container state notifications
rather than directly caching them on the container object.

Adds an object on daemon for pub/sub of various events that can happen
in the daemon, e.g. container is stopped (currelty the only event being
consumed).
This is different from the public facing events API.

This is the first step to remove some of the unccessary runtime state
from the contianer object.

Signed-off-by: Brian Goff <[email protected]>
@cpuguy83
Copy link
Copy Markdown
Member Author

ping

@LK4D4
Copy link
Copy Markdown
Contributor

LK4D4 commented Nov 3, 2016

@cpuguy83 can you rebase pls?

@cpuguy83
Copy link
Copy Markdown
Member Author

Replaced by #28483

@cpuguy83 cpuguy83 closed this Nov 16, 2016
@cpuguy83 cpuguy83 deleted the move_logging branch September 20, 2017 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants