You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a potential race condition on host startup. ufw-docker-automated needs to connect to docker socket to stream event data, thus it'll always start behind docker service. There could be a little window ufw-docker-automated might miss some containers on startup because of this.
Currently on startup, ufw-docker-automated will only look through ghost rules but doesn't perform any catch-up action to fix such issues. To fix this issue, program could get the running container list on startup then check if they needed follow up ufw-docker rules.
The text was updated successfully, but these errors were encountered:
This is fixed. However, I'm not sure if it's optimal fix. Current implementation is program will get the list of the running containers on startup, then filter through UFW_MANAGED=TRUE label. Then simply creating all of the ufw rules for them without checking if it's existing or not, since ufw program handles duplication correctly. This duplication check is mentioned in #38
There is a potential race condition on host startup. ufw-docker-automated needs to connect to docker socket to stream event data, thus it'll always start behind docker service. There could be a little window ufw-docker-automated might miss some containers on startup because of this.
Currently on startup, ufw-docker-automated will only look through ghost rules but doesn't perform any catch-up action to fix such issues. To fix this issue, program could get the running container list on startup then check if they needed follow up ufw-docker rules.
The text was updated successfully, but these errors were encountered: