Skip to content

Add IP and Resource Sync proposal document#2153

Open
geetikabatra wants to merge 3 commits into
rackerlabs:mainfrom
geetikabatra:geetikabatra-patch-1
Open

Add IP and Resource Sync proposal document#2153
geetikabatra wants to merge 3 commits into
rackerlabs:mainfrom
geetikabatra:geetikabatra-patch-1

Conversation

@geetikabatra

Copy link
Copy Markdown

This document outlines the proposal for IP and Resource Sync (ipsync) between Nautobot and Undercloud sites, detailing the motivation, goals, requirements, and implementation plans for achieving two-way synchronization of IPs and VLANs.

This document outlines the proposal for IP and Resource Sync (ipsync) between Nautobot and Undercloud sites, detailing the motivation, goals, requirements, and implementation plans for achieving two-way synchronization of IPs and VLANs.
Removed an alternative consideration regarding full two-way sync due to potential sync loops.

@cardoe cardoe left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Overall I agree here. This is written up like a ADR (which is great). We should have a section for these in the docs so that it'll pass.

Comment thread docs/IpSyncProposal.md

This isn't settled yet, and it decides how the site talks to the operator:

- **If sites can reach the management cluster's API directly:** no new plumbing needed. The site just runs a scoped Kubernetes client (limited to its own site's CRs) reading `spec` and writing `status`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Well the management cluster is the ArgoCD / logging environment. Not where Nautobot is running. The sites can reach the global cluster where Nautobot and Nautobot operator are running.

Comment thread docs/IpSyncProposal.md

#### Subtasks

- Confirm with Abhimanyu/Haseeb whether sites can reach the management cluster directly (blocks the interface design).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just want to check which cluster you mean

@mfencik

mfencik commented Jul 22, 2026

Copy link
Copy Markdown
Contributor

We have to be very careful here. First we need to understand the difference between static and dynamic data. Nautobot is not the source of truth for many things. i.e for dynamic data:

  • each site's neutron is the SoT for the following:
    • VLANs
    • VNIs
    • tenant subnets
      Nautobotop should never touch any of these and the sync should always be in one direction.

As for IPs, this is more complicated. For OOB IP ranges, we'll use static generator which @stevekeay is working on as well as for other static data such as:

  • VNI ranges per site
  • BGP ASNs
  • Loopback IPs for switches
    and bunch of other things.

I think what we need to decide right now is what data needs to be in Nautobot and make a clear separation on static vs dynamic data and what mechanisms we'll be in charge of syncing that.

Nautobotop was meant to deal with static data only, which would use the data from the file generated by static generator.

The architecture of this is captured in https://docs.undercloud.rackspace.net/architecture-decisions/adr027-automated-cab-addition/

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.

3 participants