Currently the libcompose project object can notify when particular events occur via the AddListener function. This is great when you are trying to get events from libcompose actions, however, this doesn't appear to be tied into the docker events api (https://docs.docker.com/engine/api/v1.37/#operation/SystemEvents). This means that it is possible for a container to restart outside of libcompose's control (say with a typical docker restart ... cmd) and there would be no libcompose event.
Such cases where this matters would be when using the project.Log() method to follow logs in realtime, but then a container is restarted.... currently the existing reader is closed and a new one is not reopened once the container is restarted. This results in the Log() method silently loosing all future logs.
Though it is possible to get this functionality outside of libcompose by monitoring events from the docker events api and correlating container events with ids pulled from the libcompose... but this would not be ideal.
Currently the libcompose project object can notify when particular events occur via the
AddListenerfunction. This is great when you are trying to get events from libcompose actions, however, this doesn't appear to be tied into the docker events api (https://docs.docker.com/engine/api/v1.37/#operation/SystemEvents). This means that it is possible for a container to restart outside of libcompose's control (say with a typicaldocker restart ...cmd) and there would be no libcompose event.Such cases where this matters would be when using the
project.Log()method to follow logs in realtime, but then a container is restarted.... currently the existing reader is closed and a new one is not reopened once the container is restarted. This results in theLog()method silently loosing all future logs.Though it is possible to get this functionality outside of libcompose by monitoring events from the docker events api and correlating container events with ids pulled from the libcompose... but this would not be ideal.