Expose collector via Ingress in Kubernetes Cluster

[pranoyk]

This PR will fix the issue #1048

Solution :

• add an Ingress field to the collector .Spec.Collector.Ingress
• add an Ingress field to the query .Spec.Query.Ingress
• keep .Spec.Ingress for backward compatibility as a deprecated feature.

[openshift-ci]

Hi @pranoyk. Thanks for your PR.

I'm waiting for a jaegertracing member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[pranoyk]

@jpkrohling @iblancasa Can you confirm the above mentioned points in the solution is what we have finalized as per what is mentioned here.
If it's a yes I will go ahead with further implementation

[iblancasa]

Yes, I think that approach is OK.

cc @rubenvp8510

[pranoyk]

@iblancasa I have a query. While implementing this should the assumption be that the ingress object in the query and the ingress object in the collector should be the same? If it's going to be the same should we allow the user in case they have added an ingress object in let's say only query and copy it to the collector as well in the background and vice versa?

[iblancasa]

@iblancasa I have a query. While implementing this should the assumption be that the ingress object in the query and the ingress object in the collector should be the same? If it's going to be the same should we allow the user in case they have added an ingress object in let's say only query and copy it to the collector as well in the background and vice versa?

I think:

• If you specify: .spec.ingress: an Ingress object should be created for the query and the .spec.query.ingress field should contain the same values
• If you specify: .spec.query.ingress: an Ingress object should be created for the query and the .spec.ingress field should contain the same values
• If you specify the .spec.collector.ingress: an Ingress object should be created for the collector.

The Ingress from the collector should be different from the one from the query, IMO.

[pranoyk]

• If you specify: .spec.query.ingress: an Ingress object should be created for the query and the .spec.ingress field should contain the same values

Do we need this? I thought we want to deprecate .spec.ingress from the discussion on the issue.

[iblancasa]

• If you specify: .spec.query.ingress: an Ingress object should be created for the query and the .spec.ingress field should contain the same values

Do we need this? I thought we want to deprecate .spec.ingress from the discussion on the issue.

At some point, but not in the near future.

[pranoyk]

• If you specify: .spec.query.ingress: an Ingress object should be created for the query and the .spec.ingress field should contain the same values

Do we need this? I thought we want to deprecate .spec.ingress from the discussion on the issue.

At some point, but not in the near future.

Ok. So in case there are both .spec.query.ingress and .spec.ingress what should we consider? I think .spec.query.ingress would make more sense since we are going to deprecate .spec.ingress in the future.

[iblancasa]

• If you specify: .spec.query.ingress: an Ingress object should be created for the query and the .spec.ingress field should contain the same values

Do we need this? I thought we want to deprecate .spec.ingress from the discussion on the issue.

At some point, but not in the near future.

Ok. So in case there are both .spec.query.ingress and .spec.ingress what should we consider? I think .spec.query.ingress would make more sense since we are going to deprecate .spec.ingress in the future.

Yes.

[pranoyk]

So here is what I am planning to do. I am copying the data between .spec.query.ingress and .spec.ingress as per the above mentioned conditions.
I also plan to remove the dependency from .spec.ingress and add .spec.query.ingress throughout the code base because .spec.ingress would be deprecated.

One thing with spec.collector.ingress is that right now I cannot .spec.collector being dependent on .spec.ingress anywhere in the codebase. I am not sure how to handle this. @iblancasa can you help me with this ?

[iblancasa]

One thing with spec.collector.ingress is that right now I cannot .spec.collector being dependent on .spec.ingress anywhere in the codebase.

Please, could you elaborate a little bit more?

[pranoyk]

One thing with spec.collector.ingress is that right now I cannot .spec.collector being dependent on .spec.ingress anywhere in the codebase.

Please, could you elaborate a little bit more?

wrt .spec.query.ingress I can figure out how to use it in order to set the ingress, for example, we are validating and using the ingress in pkg/ingress/query.go. But with .spec.collector.ingress I cannot figure out where in the code we are already using .spec.ingress for .spec.collector.ingress.

[iblancasa]

One thing with spec.collector.ingress is that right now I cannot .spec.collector being dependent on .spec.ingress anywhere in the codebase.

Please, could you elaborate a little bit more?

wrt .spec.query.ingress I can figure out how to use it in order to set the ingress, for example, we are validating and using the ingress in pkg/ingress/query.go. But with .spec.collector.ingress I cannot figure out where in the code we are already using .spec.ingress for .spec.collector.ingress.

The collector is not creating any ingresses right now.

[pranoyk]

@iblancasa Could you approve the e2e-tests to be run, also the PR is ready to be reviewed.