GatewayAPI: fix LB status address exception

[izturn]

Signed-off-by: Gang Liu [email protected]

When the user explicitly specifies an address, but the load balancer has not yet assigned this specified address to the gateway, the current logic here evaluates to false. After subsequently receiving the updated address status, the related update logic will not be triggered again (as currently only the generation is compared), so this situation is treated as true.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 81.78%. Comparing base (808864b) to head (73744fd).
Report is 67 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6644      +/-   ##
==========================================
+ Coverage   81.76%   81.78%   +0.01%     
==========================================
  Files         133      133              
  Lines       15944    15944              
==========================================
+ Hits        13037    13040       +3     
+ Misses       2614     2611       -3     
  Partials      293      293              

Files with missing lines	Coverage Δ
internal/dag/gatewayapi_processor.go	94.08% <100.00%> (+0.21%)	⬆️

---- 🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[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

[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

[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

[tsaarni]

Hi @izturn,

I'm not fully familiar with this case but could this change result in the condition not being displayed in cases where the status is never updated, even when it should be? If so, should the comparison logic for Gateway also take the status into account, similarly as here, to re-trigger the update?

[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

[izturn]

Hi @izturn,

I'm not fully familiar with this case but could this change result in the condition not being displayed in cases where the status is never updated, even when it should be? If so, should the comparison logic for Gateway also take the status into account, similarly as here, to re-trigger the update?

Apologize for the delayed response, TBH, my fix only solved the problem we discovered, and we did not conduct a comprehensive evaluation of its impact. Based on your suggestions, I will conduct an evaluation later.
Thank you

[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