Add IP and Resource Sync proposal document

[geetikabatra]

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.

[cardoe]

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.

[cardoe]

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.

[geetikabatra]

Correct! Then this needs rephrasing.

[cardoe]

Just want to check which cluster you mean

[geetikabatra]

Global! My bad, I dodn't know thatmanagement cluster is just CI. I missed this detail.

[mfencik]

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/

[geetikabatra]

Notes from Syncup Call:
We should focus on VLAN Groups
https://github.com/RSS-Engineering/undercloud-deploy/blob/main/hardware/vlan-groups/staging/vlan-groups.yaml.
We can move gradually to other resources.
Idea is to keep values.yaml as source of truth.
We need a validator, nautobot has a validation way. How will this service validate all the data, eg VLAN.yaml if location name is not correct, how do we validate it. @abhimanyu003 thinks, I can call the nautobot API directly to do so.
@haseebsyed12: We are using Ansible, but there is a challenge to delete. How does the connection work? We can keep an operator running? We can make an API call from site to the master.(Maybe and agent on site). We might have a setup already?
We have argo events:


We are capturing events and then we run argo workflows, we are using openstack oslo for that. There is one ironic nautobot client which just makes a call to the Nautobot.

Following are the generic ones

Oslo events sends event to handler, which calls nautobot underneath.

We are running a nautobot worker which is commanded by global.

Earlier service now job was used.

Now, we need to create a generic agent which can bring us correct data from the site. With k8s operator there, we can have more control over the site. we can features like observability and metrics.

This was related to VLAN. How about

Preferable is pull mechanism. Pull from the site.

Two things to solve.

1. Read from the YAML, validation could be a problem.
2. How do we extract the data.

We can put the idea of identifying each source(dynamic and static) later.

We can focus on 1 resource(let us day we are targetting VLANS). Let us create a servcie which will do all the CRUD operations for 1 VLAN.