feat: Allow to set registry server rest/grpc mode in operator#5364
Conversation
tchughesiv
left a comment
There was a problem hiding this comment.
when rest is enabled for registry, does the default port change?
33d6450 to
1108633
Compare
nope, same default port is used, unless changed explicitly by user. |
There was a problem hiding this comment.
@ntkathole please add unit tests to check that the rest option is being properly handled in the resulting Deployment object... and any other tests related to this PR that you think would be valuable. Also, please update the description to match any design changes that have occurred.
There was a problem hiding this comment.
Based on the failing e2e test around remote registry use, it's clear that using rest api mode will break registry's ability to be used as a "remote" provider type. this adds additional complexity that will need to be handled/checked ... likely in this method -
feast/infra/feast-operator/internal/controller/services/services.go
Lines 749 to 768 in 648c53d
If restAPI is true in the remote registry CR being used, we'd want to notify the user in the Status that remote provider registry capabilities cannot be used.
It would probably be good idea to check this in with a unit test as well. Maybe ensure whatever status message you set is being handled correctly.
There are existing remote registry tests in infra/feast-operator/internal/controller/featurestore_controller_test.go for reference. Might be a good place to add more.
ea9f800 to
75dcc2d
Compare
d42d9e5 to
4953754
Compare
tchughesiv
left a comment
There was a problem hiding this comment.
looking good, but we still need checks added as mentioned in this prior review comment -
#5364 (review)
Can you provide an example here, I didn't get how user can set restAPI true in the remote registry ? I think we have only added restAPI flag option for local registry server configs. |
|
A user can reference a registry in another We already have tests in place (both e2e & unit) around this feature. Given the restAPI breaks this functionality, you'll need to add an additional check in - feast/infra/feast-operator/internal/controller/services/services.go Lines 749 to 768 in 648c53d and unit test(s) verifying the new check.. e.g. - feast/infra/feast-operator/internal/controller/featurestore_controller_test.go Lines 992 to 1010 in 6c92447 |
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
This is handled in b991093 Thank you. |
|
Looking good, a few comments. |
Co-authored-by: Tommy Hughes IV <tchughesiv@gmail.com> Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
tchughesiv
left a comment
There was a problem hiding this comment.
very close now, just a couple nits
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
There was a problem hiding this comment.
this whole block needs to change -
feast/infra/feast-operator/internal/controller/services/services.go
Lines 447 to 465 in f231f0d
the issue is that you're breaking the setting of ports for other service types (online, offline, etc)...
something like this should do the trick -
if feastType == RegistryFeastType {
if feast.isRegistryGrpcEnabled() {
container.Ports = append(container.Ports, corev1.ContainerPort{
Name: name,
ContainerPort: getTargetPort(feastType, tls),
Protocol: corev1.ProtocolTCP,
})
}
if feast.isRegistryRestEnabled() {
container.Ports = append(container.Ports, corev1.ContainerPort{
Name: name + "-rest",
ContainerPort: getTargetRestPort(feastType, tls),
Protocol: corev1.ProtocolTCP,
})
}
} else {
container.Ports = append(container.Ports, corev1.ContainerPort{
Name: name,
ContainerPort: getTargetPort(feastType, tls),
Protocol: corev1.ProtocolTCP,
})
}the above would be done in addition to the other suggestions i've made around the isRegistryRestEnabled & isRegistryGrpcEnabled method changes
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
tchughesiv
left a comment
There was a problem hiding this comment.
looking good! one more change requested.
we also need unit tests for changes made around the rest & grpc container ports, services, probeHandlers, etc.
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
Signed-off-by: ntkathole <nikhilkathole2683@gmail.com>
What this PR does / why we need it:
This PR adds capability in feast-operator to allow user to deploy registry serving in REST or gRPC or both mode.
New configuration fields:
GRPC: Toggle gRPC server (--grpc/--no-grpc)RestAPI: Toggle REST API server (--rest-api)When REST API is enabled:
Service hostnames:
Maintains backward compatibility with existing gRPC deployments.
Setting
restAPI: truewill deploy registry with :feast serve_registry --rest-apiAdditionally, also fixed the issue in f231f0d with rest port not used when grpc is disabled and only rest-api is enabled. Earlier it was using default grpc port instead of default rest port.