-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
[APIv2] events?filters return 500 #6899
Comments
Thanks for opening the issue! There's definitely a bug causing the panic but
Does the call work with Docker? |
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Opened #6902 which will fix the panic. |
Yes, it work fine, and traefik code is here https://github.com/containous/traefik/blob/master/pkg/provider/docker/docker.go#L271-L299 |
Thanks, I can reproduce locally when running the docker client against the podman.sock
|
Fun... the Docker API states that filters are a // Args stores a mapping of keys to a set of multiple values.
type Args struct {
fields map[string]map[string]bool
} @baude, I guess we need to change the wiring on our side to be compatible. WDYT? |
This explains the unmarshal error on our side:
|
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
@vrothberg Are you sure the filter typing didn't change between v1.24 and v1.40? |
I can have a look at older implementations but the docs of v1.24 and v1.40 didn't change |
but arent you saying the docs are actually wrong? |
The docs in v1.40 are wrong. I will look at v1.24 code to check if it has always behaved like that or if the implementation has changed over time. |
Can we verify this with another filter? the |
It's independent of the filter as the types are different (see #6899 (comment)). We follow the documentation with using a |
I just checked. v1.24 (Docker 1.12.) was also using a |
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Sure. Ensuring compatibility with the actual implementation is more important than compatibility with their docs. |
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Another race was the handler closing event channel, which could lead to two kinds of panics: double close, send to close channel. The backend takes care of that. However, make sure that the backend stops working in case the context has been cancelled. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Another race was the handler closing event channel, which could lead to two kinds of panics: double close, send to close channel. The backend takes care of that. However, make sure that the backend stops working in case the context has been cancelled. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Another race was the handler closing event channel, which could lead to two kinds of panics: double close, send to close channel. The backend takes care of that. However, make sure that the backend stops working in case the context has been cancelled. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Another race was the handler closing event channel, which could lead to two kinds of panics: double close, send to close channel. The backend takes care of that. However, make sure that the backend stops working in case the context has been cancelled. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Another race was the handler closing event channel, which could lead to two kinds of panics: double close, send to close channel. The backend takes care of that. However, make sure that the backend stops working in case the context has been cancelled. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The versions Docker that the compat endpoints currently support are using another type for the `filters` parameter than later versions of Docker, which the libpod/events endpoint is also using. To prevent existing deplopyments from breaking while still achieving backward compat, we now support both types for the filters parameter. Tested manually. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The versions Docker that the compat endpoints currently support are using another type for the `filters` parameter than later versions of Docker, which the libpod/events endpoint is also using. To prevent existing deplopyments from breaking while still achieving backward compat, we now support both types for the filters parameter. Tested manually. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
Fix a potential panic in the events endpoint when parsing the filters parameter. Values of the filters map might be empty, so we need to account for that instead of uncondtitionally accessing the first item. Also apply a similar for race conditions as done in commit f4a2d25: Fix a race that could cause read errors to be masked. Masking such errors is likely to report red herrings since users don't see that reading failed for some reasons but that a given event could not be found. Another race was the handler closing event channel, which could lead to two kinds of panics: double close, send to close channel. The backend takes care of that. However, make sure that the backend stops working in case the context has been cancelled. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
The versions Docker that the compat endpoints currently support are using another type for the `filters` parameter than later versions of Docker, which the libpod/events endpoint is also using. To prevent existing deplopyments from breaking while still achieving backward compat, we now support both types for the filters parameter. Tested manually. Fixes: containers#6899 Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
/kind bug
Description
treafik v2.2.1 will call on
/v1.24/events?filters=%7B%22type%22%3A%7B%22container%22%3Atrue%7D%7D
but return 500Steps to reproduce the issue:
podman system service -t 0 tcp:0.0.0.0:9999
start treafik with
endpoint = "tcp://127.0.0.1:9999"
configDescribe the results you received:
Describe the results you expected:
Additional information you deem important (e.g. issue happens only occasionally):
Output of
podman version
:Output of
podman info --debug
:Package info (e.g. output of
rpm -q podman
orapt list podman
):Additional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered: