Parse grpc requests on the service socket

[nalind]

Parse and dispatch grpc requests on the service socket, allowing clients to cleanly determine that a given service is not implemented instead of timing out after attempting to upgrade their connection to HTTP/2, failing, and perhaps retrying.

Add a "no-op" service that we can call in a system test to exercise this.

Does this PR introduce a user-facing change?

None

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[nalind]

Added bloat_approved because we pull in google.golang.org/grpc/reflection, which we didn't before.

[Honny1]

LGTM, it seems that Swagger isn't happy.

[Luap99]

What is the use case for this? This is bloating podman for "nothing" AFAICT

bin/podman grew by 260056 bytes; max allowed is 51200.

Debloating podman is quite a difficult task so I am very vary to add bloat for stuff that adds no functionality whatsoever.

I don't see why we would need a grpc endpoint at all, is there no way to just close the gprc request directly without all these protobuf requirements?
I am not really familiar with grpc but if that just routes based of the Content-Type header could we not just close the requests with such headers? Or return the corresponding 400/404 return codes or whatever the equivalent in grpc is without pulling in protobuf?

[Luap99]

Where and how does one get this new test dependency.

I don't see how this can pass in the test env without this being present, i.e. tmt tests run of podman-tests rpm so this needs a dep on whatever package this would provide.

As tmt tests passed I took a look and they are broken badly, they seem to test the @main rpm not the PR build
@lsm5 PTAL!
https://artifacts.dev.testing-farm.io/fb24d06d-ef07-4211-87a1-42a42d79bb33
https://artifacts.dev.testing-farm.io/fb24d06d-ef07-4211-87a1-42a42d79bb33/work-remote-rootdx4znvlo/plans/system/remote-root/execute/data/guest/default-0/test/tmt/system/remote-root-1/output.txt

podman-6.0.0~dev-1.20251028195230397831.main.1810.386c8f3fe9.fc43.x86_64
podman-tests-6.0.0~dev-1.20251028195230397831.main.1810.386c8f3fe9.fc43.x86_64

I would really like to avoid new dependencies like that, it seem to be there as package for fedora but I doubt it will be packages on RHEL making gating tests there more difficult

[lsm5]

RE: fetching copr rpm for tests, #27488 .

[TomSweeneyRedHat]

Other than the bloat issue and the questions from @Luap99 LGTM
I'll let @mheon, @bbaude, and/or @Luap99 decide whether this addition is useful.

[nalind]

If we ever want to implement any GRPC APIs (including those that are expected by compose), this is part of how we'll most likely end up having to do it. The no-op service is mainly there so that we have something to test, I could take or leave that.
The tests build a copy of grpcurl for their use, as they do for ginkgo.

[Luap99]

If we ever want to implement any GRPC APIs (including those that are expected by compose), this is part of how we'll most likely end up having to do it. The no-op service is mainly there so that we have something to test, I could take or leave that.

Ack I guess for buildkit that will be inevitable. However for now I don't get what the dump noop service offers, coudln't we just wait until we actually implement a proper API endpoint?

The tests build a copy of grpcurl for their use, as they do for ginkgo.

system tests are run as part of gating with no access to the full source tree, they only run with the content from test/system everything else is not shipped in podman-tests rpm. Any I doubt we want to build and bundle our own grpcurl and ship that with podman-tests. These tests inb general must work without access to the Makefile.

Also building it every time makes the tests slower. Looking at one test log I see ~50s build time for just this one util so I really like to avoid that.

[mheon]

+600,000 lines makes me scream a little inside; shocking this only adds a quarter of a megabyte to binary size. I guess it's mostly test dependencies, but still...

[Luap99]

+600,000 lines makes me scream a little inside; shocking this only adds a quarter of a megabyte to binary size. I guess it's mostly test dependencies, but still...

Because that is test/tools/vendor, the main go module doesn't seem to import anything new. Though on the topic of new code do we have the CNCF license scanner running somewhere? I guess even if it is test code we need to be sure to only use CNCF approved licenses here.

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: nalind

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [nalind]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[mheon]

LGTM

[nalind]

@containers/podman-maintainers PTAL, I think this is ready.

[Honny1]

LGTM

[mheon]

/lgtm