RFC: Add --envoy-ingress-name, and --envoy-ingress-namespace flags. (#4952)

[kahirokunn]

#4952

I want to add --envoy-ingress-name and --envoy-ingress-namespace.
I'm thinking something like this, what do you think?
If you like it, I can implement the rest.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[skriss]

@kahirokunn first of all I want to apologize for how long it's taken us to review this. We appreciate your contributions to the project!

One thought I have here - maybe instead of having a pair of flags/config fields for Service, Ingress, Gateway, etc., we could just have three flags/fields -- resource type, namespace, and name. This would help avoid flag/config sprawl, and would be more extensible for any future ways of sourcing the LoadBalancerStatus. If we do like this pattern, then we need to decide whether we want to keep the existing fields for Service namespace/name, or deprecate them and replace them with more generally named fields. Deprecation is possible but requires a series of changes over multiple releases to allow folks a chance to migrate to the replacements. What are your thoughts on this approach?

[kahirokunn]

@skriss I agree, because that approach worked in all cases with minimal code.
If you want, I can implement it myself.

[skriss]

@skriss I agree, because that approach worked in all cases with minimal code. If you want, I can implement it myself.

👍 I'd like to get @sunjayBhatia and/or @tsaarni's input here as well before we move forward. Also, if you could take a look at #2539 and see if anything there would impact our approach here, that would be great! I haven't had a chance to review that issue in detail myself yet.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

Keep

[kahirokunn]

@skriss #2539
This issue does not affect my problem, but if I implement your suggestion the issue will be resolved.

we could just have three flags/fields -- resource type, namespace, and name

[kahirokunn]

@sunjayBhatia @tsaarni's Could you give me your opinion?

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[tsaarni]

Since there were no objections to suggestion #5083 (comment) it would be great to have short API proposal here - to get this PR unblocked! 😅

@skriss wrote:

One thought I have here - maybe instead of having a pair of flags/config fields for Service, Ingress, Gateway, etc., we could just have three flags/fields -- resource type, namespace, and name. This would help avoid flag/config sprawl, and would be more extensible for any future ways of sourcing the LoadBalancerStatus.

One more thought: what do people think about single switch with format like DISCOVERY_SCHEME:PARAMS, for example --loadbalancer-status=service:namespace/resource, --loadbalancer-status=ingress:namespace/resource, --loadbalancer-status=hostname:fqdn,hostname:fqdn ...

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

keep

[skriss]

I like @tsaarni's suggestion above for the flag design.

@kahirokunn to move this forward, could you write up a brief summary of the changes we plan here, taking into account the comments above? In short, I think we would be adding two new generic flags that would provide the existing functionality for getting the IP from a Service, adding the functionality to alternate get it from an Ingress, and then deprecating the existing --envoy-service-name/namespace flags (but we can't remove them for a couple of releases).

Assuming everyone supports that approach, then we can move forward with the implementation.

[github-actions]

The Contour project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 14d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the PR is closed

You can:

• Ensure your PR is passing all CI checks. PRs that are fully green are more likely to be reviewed. If you are having trouble with CI checks, reach out to the #contour channel in the Kubernetes Slack workspace.
• Mark this PR as fresh by commenting or pushing a commit
• Close this PR
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[kahirokunn]

@skriss Sorry, I agree with you.
However, I have lost track of time and it looks like I will not be able to proceed with this implementation.
I would appreciate it if someone else could implement a new one instead.