Repository navigation
EV-6699: Document license agent removal in 3.24.0-3 #3001
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -54,6 +54,28 @@ owned resources being garbage collected by Kubernetes. | |
|
|
||
| $[prodname] creates a default-deny for the calico-system namespace. If you deploy workloads into the calico-system namespace, you must create policy that allows the required traffic for your workloads prior to upgrade. | ||
|
|
||
| ### License agent removed | ||
|
|
||
| The license agent has been removed in $[prodname] v3.24.0-3. If you previously installed | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Under what circumstances would a CE users NOT have installed it? It seems to me that this applies to everyone using Calico Enterprise. Or is there a way to have a license without the agent?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The license agent has no operational role in the cluster. It runs as a standalone Deployment whose only job is to read the LicenseKey and expose Prometheus gauges — it does not gate, enforce or enable any feature. A Calico Enterprise cluster without it is fully functional; the only difference is those metrics. Its replacement is already running on every cluster installed from our manifests. tigera-operator exports The one real impact is on users whose dashboards or alerts reference the agent's metric names; those need repointing at the operator metrics. |
||
| it, uninstall it using the manifest from the version you are upgrading | ||
| **from** — it is still available at its versioned URL. For example, if upgrading from v3.23.2: | ||
|
|
||
| ```bash | ||
| kubectl delete -f https://downloads.tigera.io/ee/v3.23.2/manifests/licenseagent.yaml | ||
| ``` | ||
|
Comment on lines
+63
to
+65
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does this procedure look like for Helm installations?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. installing license agent is not part of the default installation, it comes as an additional step and therefore not included in the helm installations as well. the instructions to install license agent for reference: https://docs.tigera.io/calico-enterprise/3.21/operations/monitor/metrics/license-agent |
||
|
|
||
| If you no longer have that manifest: | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This seems to be a second, perhaps unnecessary method. We know that we host manifests for all published versions. So can't we just rely on the manifest being available?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. fair enough. I tried to be helpful to user but if it is too much explanation, I am okay with dropping this section and only refer them to find the correct manifest to do the uninstall. |
||
|
|
||
| ```bash | ||
| kubectl delete servicemonitor calico-lic-monitor -n tigera-prometheus --ignore-not-found | ||
| kubectl delete networkpolicies.projectcalico.org calico-system.tigera-license-agent-access -n tigera-license-agent --ignore-not-found | ||
| kubectl delete networkpolicies.projectcalico.org allow-tigera.tigera-license-agent-access -n tigera-license-agent --ignore-not-found | ||
| kubectl delete clusterrole,clusterrolebinding tigera-license-agent --ignore-not-found | ||
| kubectl delete namespace tigera-license-agent --ignore-not-found | ||
| ``` | ||
|
|
||
| To learn about the license metrics, see [Operator metrics](../../../../operations/monitor/metrics/operator-metrics.mdx). | ||
|
|
||
| ## Upgrade from 3.19 or later | ||
|
|
||
| :::note | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some general questions:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1. What happens if you don't remove it?
It keeps running and keeps exporting its metrics. Nothing in the release manages it — the operator doesn't reconcile it, nothing upgrades or removes it — so it becomes an orphan: not built, not tested, not patched. CVEs accumulate in an image that never gets rebuilt.
2. Before or after the upgrade?
Either works.
3. Keep the note until 3.27?
That's correct. When 3.24 is the oldest supported cluster, we are not supporting this upgrade path anymore.
4. Cleanup or breaking change?
No functionality breaks — license validity is still observable via the operator metrics. But it's a user-visible removal, not silent cleanup: the manifest URL will 404, and dashboards or alerts on the agent's metric names need repointing. Should be a deprecation/removal in the release notes.