Can someone re-trigger the CI? Looks like the upload to codecov broke in the run.

/retest

thanks for picking this feature up @tanujd11 ! would be great if this land in v0.6
quick q - isn't this feature blocked on #1494 which is adding EndpointSlice support ?

Codecov Report

Merging #1705 (865aa0e) into main (3fbaa78) will decrease coverage by 0.18%.
The diff coverage is 63.07%.

@@            Coverage Diff             @@
##             main    #1705      +/-   ##
==========================================
- Coverage   65.22%   65.04%   -0.18%     
==========================================
  Files          86       86              
  Lines       12318    12452     +134     
==========================================
+ Hits         8034     8099      +65     
- Misses       3772     3832      +60     
- Partials      512      521       +9     

@arkodg , I think this can go in with using ClusterSetIP type which will have VIPs in multi cluster service import. EndpointSlice can be used once that PR gets in. It will be similar to service backend.

Rethinking, you're right @tanujd11, this PR can go in by itself.
Will review this soon once we start working on v0.6 features.

did a first pass, it looks good ! added some minor comments

ptal @envoyproxy/gateway-maintainers, a decision also needs be made here on whether we want the ServiceImport API to be opt in or not

@arkodg, if we are removing the serviceImport CRD from EG chart, then it automatically becomes the a Opt-in feature where user needs to install the CRD to use this feature. I can add a validation to check if the CRD exist before someone uses serviceImport as part of the backend. for example if the user has mentioned serviceImport as backendRef and the CRD does not exist, we can reject the config with status backendRef kind does not exist

/retest

@arkodg, if we are removing the serviceImport CRD from EG chart, then it automatically becomes the a Opt-in feature where user needs to install the CRD to use this feature. I can add a validation to check if the CRD exist before someone uses serviceImport as part of the backend. for example if the user has mentioned serviceImport as backendRef and the CRD does not exist, we can reject the config with status backendRef kind does not exist

great idea, +1 to this, but from an implementation perspective, won't the provider layer error out if it tries to Watch the ServiceImport resource w/o have a CRD installed ?

great idea, +1 to this, but from an implementation perspective, won't the provider layer error out if it tries to Watch the ServiceImport resource w/o have a CRD installed ?

You are right, the current one is throwing error. Should we implement a way to check the presence of CRD for watching also. Or is there any other way in your mind to tackle this

@tanujd11 can you share the error you are seeing ?

one way to solve the opt in problem is add a knob in EnvoyGateway.ExtensionApis

LGTM after conflicts are resolved and CI passed.

@arkodg , can you take a relook at this work? I have added the knob at the place suggested by you. I will work on the doc in a subsequent PR

had a chat with @tanujd11 who is trying to implement the functionality w/o having to add an explicit API knob

hey @tanujd11 just took a peek at your PR, the approach of using the o/p. of discoveryClient.ServerResources() to check if the service import API exists in the API server is a great way to decide on whether to watch the resource or not.

seeing some test yaml fail, recommend running make testdata to fix it

can you add a user face doc in following PR.