[spike] remote filters

[vrothberg]

As described in #18345 (comment), Podman clients and Docker clients behave slightly different when it comes to passing filters over the REST API.

I did not fully investigate it but my currently feeling is that Podman clients do it wrong.

Image filters, for instance, can use a key=value or key syntax. Docker clients split the filter map as "{"label":["version=1.0"]} while Podman clients split the filter map as "{"label":["version","1.0"]}. For the latter, I don't think we can distinguish a key=value from a key if more than one filter of the same type (e.g., label) are specified.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

@edsantiago @Luap99 are working on this correct?

[edsantiago]

Not to my knowledge.

[Luap99]

No

[rhatdan]

Oops, my tired eyes read this as the problem with filtering .HasPrefix, verus ContainsString for ID matching.

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[rhatdan]

This has been approved correct?

[vrothberg]

This has been approved correct?

I don't think anybody has worked on it yet. At the moment, it remains unclear what needs to be done and how much of a problem it is.

[rhatdan]

s/approved/improved/g
I thought we only match on the prefix now, not anywhere in the id?

[vrothberg]

Image filters, for instance, can use a key=value or key syntax. Docker clients split the filter map as "{"label":["version=1.0"]} while Podman clients split the filter map as "{"label":["version","1.0"]}. For the latter, I don't think we can distinguish a key=value from a key if more than one filter of the same type (e.g., label) are specified.

I think this problem persists. At least I am unaware of a fix.

[umohnani8]

Looked into this a bit and when more than one filter is passed, docker does an AND operation where if the image matches all the given filters, only then will it be in the final result. While podman seems to do an OR operation where if any image matches any of the filters given, it will be in the final result. This is the case for both local and remote.

We did a similar fix for volumes here #19219, I think images should follow suit and match the behavior. @rhatdan @vrothberg WDYT?

[vrothberg]

@umohnani8 I think that's orthogonal to the issue here.

Image filters, for instance, can use a key=value or key syntax. Docker clients split the filter map as "{"label":["version=1.0"]} while Podman clients split the filter map as "{"label":["version","1.0"]}. For the latter, I don't think we can distinguish a key=value from a key if more than one filter of the same type (e.g., label) are specified.

Filters can be in the format of key=value or key. But Podman's REST API doesn't seem to be able to distinguish that correctly.

[umohnani8]

@vrothberg can you please give me an example? I have tried both the remote and local cases and I see the AND vs OR issue for the filters given for the local case. The remote case has another problem where if you pass it two --filter flags it only filters on the last filter passed.
So for example, podman images --filter label=foo=bar --filter label=test=bar will only return images that match the test=bar case.

When I just do podman images --filter label=foo, I get all the images that have the key foo even if they have a value assigned to it and when I do podman images --filter label=foo=bar, I only get the images that have foo=bar set as a label. Same results with podman --remote.
Looking at the podman filter parsing code here https://github.com/containers/podman/blob/main/vendor/github.com/containers/common/pkg/filters/filters.go#L81, it creates a final filter array of the format "["foo=bar", test=bar]. I am not able to trigger the issue defined here.

[vrothberg]

For the AND vs OR, I´d prefer breaking that out into a separate issue.

For the filter issue, look at the linked issue and the old PR:
https://github.com/containers/podman/pull/18345/files

This should highlight the differences. The way Podman works does not allow for discriminating label=foo=bar from label=foo+label=bar. So this needs fixing but it's a breaking change (in some way). Hence the 5.0 label.