Repository navigation
[CORE-12848] Document the OpenStack Neutron-etcd resync process - #2800
Conversation
✅ Deploy Preview for calico-docs-preview-next ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview succeeded!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
Add a new networking/openstack/resync.mdx page covering the resync behaviour as it now exists after the post-v3.32 changes: one-shot startup resync (gated by [calico] startup_resync), the on-demand calico-resync command, per-item INFO logging, and performance and concurrency characteristics. Also note the removal of the old periodic resync and deprecation of resync_interval_secs and resync_max_interval_secs. Cross-reference the new page from configuration.mdx and add it to the calico sidebar. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
e393afe to
ae63aa1
Compare
There was a problem hiding this comment.
Pull request overview
Adds new Calico OpenStack documentation describing how the Neutron-to-etcd reconciliation (“resync”) works after the post-v3.32 behavior changes, and wires that content into the OpenStack docs navigation.
Changes:
- Adds a new
networking/openstack/resync.mdxpage documenting startup resync behavior, thecalico-resynccommand (including scoping), observability, and performance/concurrency characteristics. - Cross-references the resync behavior from the OpenStack configuration docs, including noting deprecated periodic-resync options.
- Adds the new page to the Calico OpenStack sidebar section.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| sidebars-calico.js | Adds the new OpenStack resync page to the Calico docs sidebar navigation. |
| calico/networking/openstack/resync.mdx | New documentation page detailing resync mechanisms (startup + on-demand) and upgrade notes. |
| calico/networking/openstack/configuration.mdx | Documents the startup_resync option and links to the new resync page; notes deprecated periodic-resync options. |
Note that the calico-resync command ships in a dedicated calico-resync package, to be installed on each control node like calico-control. Add an example ResyncResult JSON to the Output section, and correct the description of the endpoints phase, which counts WorkloadEndpoint and LiveMigration resources together rather than reporting them separately. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
| Neutron server starts or is restarted. This is the normal, hands-off | ||
| mechanism, and is enabled by default. | ||
|
|
||
| - **On-demand resync** — run explicitly by an operator using the |
There was a problem hiding this comment.
nit since it can be inferred from context: I'd prefer to use the term user or administrator to avoid possible confusion with automated operators such as the Tigera operator, but don't feel too strongly about it in this context
| watching, and endpoint-status watching), which elect a single active worker | ||
| dynamically through an etcd key so that the work fails over cleanly, the | ||
| startup resync is governed by this static `startup_resync` config switch. It | ||
| runs once rather than continuously, so operator-level control over whether and |
There was a problem hiding this comment.
again, maybe change operator to administrator?
ctauchen
left a comment
ctauchen
left a comment
There was a problem hiding this comment.
A few nits, otherwise LGTM.
| :::note | ||
|
|
||
| The `resync_interval_secs` and `resync_max_interval_secs` options that | ||
| configured the old periodic resync are deprecated and have no effect. See |
There was a problem hiding this comment.
| configured the old periodic resync are deprecated and have no effect. See | |
| configured the old periodic resync have been removed. See |
In our usage, 'deprecated' suggests a thing still functions, though it's scheduled for removal.
There was a problem hiding this comment.
The problem is that they haven't been removed. I think "deprecated and have no effect" is the accurate description here. More broadly, I think "deprecated" can include both "deprecated and has no effect" and "deprecated and we encourage a new approach, but this way still works too". I feel pretty sure we have prior examples of both of those.
There was a problem hiding this comment.
The functionality has been removed, despite whatever remnants you are leaving in the code. We can't use 'deprecated' here because they don't work anymore.
You're right that general usage of the word 'deprecated' is squishy. If you know of examples in our docs, by all means let me know and I'll set them right.
There was a problem hiding this comment.
Fair enough, I've pushed a commit to stop saying "deprecated" for these options.
Co-authored-by: Christopher Tauchen <tauchen@gmail.com>
We want 'deprecated' to mean something that still fully works but is scheduled for removal - which is different from how I was using it here.
Add a new networking/openstack/resync.mdx page covering the resync behaviour as it now exists after the post-v3.32 changes: one-shot startup resync (gated by [calico] startup_resync), the on-demand calico-resync command, per-item INFO logging, and performance and concurrency characteristics. Also note the removal of the old periodic resync and deprecation of resync_interval_secs and resync_max_interval_secs.
Cross-reference the new page from configuration.mdx and add it to the calico sidebar.