Move Logger/LogCopier out of container#26759
Conversation
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I'd propose to create new loggers in this object. I found all getLogger + Add stuff pretty hard to follow.
There was a problem hiding this comment.
why a new watch method if we already have c.WaitWithContext()
There was a problem hiding this comment.
Oh, I have not seen this.
Ultimately though, I want to get rid of state.waitChan.
There was a problem hiding this comment.
I updated to use this function for now.
246dd63 to
c353ef3
Compare
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]>
c353ef3 to
e6594ff
Compare
|
ping |
|
@cpuguy83 can you rebase pls? |
|
Replaced by #28483 |
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.