Skip to content

Conversation

@shafi-elastisys
Copy link
Contributor

@shafi-elastisys shafi-elastisys commented Sep 16, 2025

Warning

This is a public repository, ensure not to disclose:

  • personal data beyond what is necessary for interacting with this pull request, nor
  • business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

  • kind/feature
  • kind/improvement
  • kind/deprecation
  • kind/documentation
  • kind/clean-up
  • kind/bug
  • kind/other

Optional: Mark one or more of the following that are applicable:

Important

Breaking changes should be marked kind/admin-change or kind/dev-change depending on type
Critical security fixes should be marked with kind/security

  • kind/admin-change
  • kind/dev-change
  • kind/security
  • [kind/adr](set-me)

What does this PR do / why do we need this PR?

This PR enables Calico Typha in the default configuration.
...

Information for reviewers

  • Enabled Typha in the SME long-running environment and in my dev cluster.
  • Created a ServiceMonitor to scrape Typha metrics.
  • Verified in Grafana that connection drops look normal.
  • Checked calico-node pod logs to confirm connections are established to Typha.

Checklist

  • Proper commit message prefix on all commits
  • Change checks:
    • The change is transparent
    • The change is disruptive
    • The change requires no migration steps
    • The change requires migration steps
  • Documentation checks:
  • Metrics checks:
    • The metrics are still exposed and present in Grafana after the change
    • The metrics names didn't change (Grafana dashboards and Prometheus alerts required no updates)
    • The metrics names did change (Grafana dashboards and Prometheus alerts required an update)
  • Logs checks:
    • The logs do not show any errors after the change
  • PodSecurityPolicy checks:
    • Any changed Pod is covered by Kubernetes Pod Security Standards
    • Any changed Pod is covered by Gatekeeper Pod Security Policies
    • The change does not cause any Pods to be blocked by Pod Security Standards or Policies
  • NetworkPolicy checks:
    • Any changed Pod is covered by Network Policies
    • The change does not cause any dropped packets in the NetworkPolicy Dashboard
  • Audit checks:
    • The change does not cause any unnecessary Kubernetes audit events
    • The change requires changes to Kubernetes audit policy
  • Falco checks:
    • The change does not cause any alerts to be generated by Falco
  • Bug checks:
    • The bug fix is covered by regression tests

@shafi-elastisys shafi-elastisys requested a review from a team as a code owner September 16, 2025 07:26
@shafi-elastisys shafi-elastisys changed the title enabled calico typha enables calico typha Sep 16, 2025
@shafi-elastisys shafi-elastisys changed the title enables calico typha config: enables calico typha Sep 16, 2025
@shafi-elastisys shafi-elastisys changed the title config: enables calico typha config: enables calico typha as default Sep 16, 2025
Copy link
Contributor

@Xartos Xartos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, but did we test to enable it in long-running first?

I see that this is the first step of the issue.

@shafi-elastisys
Copy link
Contributor Author

shafi-elastisys commented Sep 16, 2025

Yes I have tested in my dev and also tested by updating the SME Long running. Also enabled service monitor for typha to check on the metrics & verified checking logs of calico-node as well which looks good.

Copy link
Contributor

@Xartos Xartos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@shafi-elastisys shafi-elastisys merged commit 2d6adff into main Sep 22, 2025
5 of 6 checks passed
@shafi-elastisys shafi-elastisys deleted the typha-enabled branch September 22, 2025 15:49
@aarnq
Copy link
Contributor

aarnq commented Nov 10, 2025

Question on an old PR: Was there any intention of enabling this for existing environments by writing a migration to enable it? I don't see that that has been done here, and options from the default config does not propagate in this repo to existing configs.

@anders-elastisys
Copy link
Contributor

anders-elastisys commented Nov 10, 2025

I believe @shafi-elastisys tested just enabling this in an existing cluster and there was no need for any migration steps (besides enabling this in the config) right? If so, we should just add a prepare script for this before next release, should not need a separate issue

@aarnq
Copy link
Contributor

aarnq commented Nov 12, 2025

I believe @shafi-elastisys tested just enabling this in an existing cluster and there was no need for any migration steps (besides enabling this in the config) right? If so, we should just add a prepare script for this before next release, should not need a separate issue

From the issue it should "... be applied during regular Kubespray upgrade", and with that migration missing that won't happen, so I just don't want to see this become lost as that issue has been closed. 😅

@shafi-elastisys
Copy link
Contributor Author

Now I have added migration script for the typha enabling. PR #473

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants