-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
GRPC health endpoint is always succesfull on OCP and leads to "Type already defined" exception in dev mode #33219
Comments
About the first issue that you described:
And about the second issue |
@Sgitario the manual for grpc health probes[1] explicitly suggests K8s docs[2] say, that GRPC probes are enabled by default starting with 1.24 and my cluster uses 1.25. Unless OCP folks disabled the feature, this should be working fine. In addition, if I change service name (eg [1] https://github.com/grpc/grpc/blob/master/doc/health-checking.md |
Quarkus implements the health service automatically. |
@cescoffier how does it distinguish between GRPC and HTTP-based endpoints? Can we disable/overload the automatic implementation? If it it implemented automatically, then why there are options from the |
We only implement and expose the gRPC health service. I don't believe the probes use it directly. |
Could you explain this a bit? I have GRPC-based health service and I want OCP probes to use it. It looks like the new Quarkus feature[1] allows me to do exactly that. Is there some special considerations which I should be aware of? [1] #32113 |
@fedinskiy I could play around with your reproducer and gRPC probes. Let's go step by step: The first thing you need to address is the incompatibility package name:
Having the two packages are obviously wrong and I don't think we need to document this. The right one is The second thing is that the gRPC port (9000) is not exposed in the container and in the service. This is because you haven't implemented any bindable gRPC service (the package The third thing is that you're using the gRPC service instead of the Kubernetes services in the gRPC probes:
It should be:
The fourth thing is that as @cescoffier stated, the health service is being configured by default. If you want to provide your custom one, you need to disable:
After doing these four things, your deployment will still fail with:
This is because your
And then you can implement your custom logic. And this will work fine. Now, the possible improvements:
In this case, we would need to add a new property:
Or perhaps, use an
In any case, this should be reported by a separate ticket, so we could discuss the solutions further.
Note that I didn't use the Quarkus Smallrye health extension. The problem seems to be that the gRPC service is not registered in the gRPC storage. @cescoffier any ideas about how this should work / or if this is meant to work without the Quarkus Smallrye health extension? But again, I think this should also be reported by a separate ticket.
|
@Sgitario could you elaborate on
Changing the package name leads to
I also suggest to document the prohibition of |
These proto files are defined by gRPC, you cannot change them. |
The
Did you do the changes in step 4 above? These ones:
I'm ok with the warning, but why do you say that it directly contradicts the official guide?
I don't understand what you want to document/clarify here. |
@Sgitario yes, I changed files in the reproducer like that (see also updated reproducer): application.properties:
health.proto:
GrpcHealthService.java:
After deploy it leads to It looks like grpc health probes require definition of service to have package |
Quarkus does allow to use of this package name. The only thing is that it's not considered bindable (which I think it makes sense), and not being bindable only means that the port 9000 won't be exposed by the K8s service. If you add another gRPC service as I said in step two above, you'll see the gRPC port as a container port. |
@Sgitario there is another service already (see file If my interpreattion is correct, than OCP grpc probes require service to be named |
Plus, I'm adding a new guide about the usage of gRPC services in Kubernetes. Relates to quarkusio#33219 (comment)
FYI: I've provided a pull request to add a new property that automatically populates the correct values of the gRPC probes: #33437 |
Plus, I'm adding a new guide about the usage of gRPC services in Kubernetes. Relates to quarkusio#33219 (comment)
After adding the documentation and the new property to automatically populate the correct values, I think we can close now this pull request. |
Plus, I'm adding a new guide about the usage of gRPC services in Kubernetes. Relates to quarkusio#33219 (comment)
Describe the bug
I have an application, which is deployed on Openshift. After I added GRPC health endpoint[1] to the app, I noticed, that health probes are always successful, even when endpoint should be throwing exceptions. When the application is started in dev mode locally, it throws exception
java.lang.IllegalStateException: Type already defined: grpc.health.v1.HealthCheckRequest
and doesn't not serve any endpoints. OpenShift logs for the same app doesn't contain the error.[1] #32113
Expected behavior
Application should start in dev mode without exceptions. Health probes should fail on exceptions/error codes
Actual behavior
Startup/readiness/liveness probes on Openshift are successful. In dev mode, the application throws this exception:
How to Reproduce?
quarkus-openshift
andquarkus-grpc
dependencieshealth.proto
file tosrc/main/proto/
:mvn clean quarkus:dev
. This failsmvn clean install -Dquarkus.kubernetes.deploy=true
A repriducer can be found here: https://github.com/fedinskiy/reproducer/tree/grpc-probes
Output of
uname -a
orver
4.18.0-425.19.2.el8_7.x86_64
Output of
java -version
11.0.18, vendor: Red Hat, Inc
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.0.1.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63)
Additional information
The text was updated successfully, but these errors were encountered: