feat: add location sync to nautobot operator

[abhimanyu003]

Summary

This PR adds Location sync support to the Nautobot Operator.

The operator now reads Location defined in a Kubernetes ConfigMap and ensures they are created and kept in sync with Nautobot via the Nautobot API.

How it works

1. The Nautobot Operator reads the Location configuration from a Kubernetes ConfigMap.
2. It processes only the Location that are referenced by the Nautobot CRD.
3. The operator then syncs these Location with Nautobot using the Nautobot API.

flowchart
    n1["Nautobot Operator"]
    n2["Kubernetes Location ConfigMap"]
    n3["Nautobot API"]

    n1 --> n2
    n2 --> n3

Loading

Example ConfigMap

apiVersion: v1
data:
  locations.yaml: |
    # yaml-language-server: $schema=https://rackerlabs.github.io/understack/schema/locations.schema.json
    ---
    - name: Global
      description: Global (Root)
      location_type: Global
      status: Active
      children:
        - name: Rackspace
          description: Rackspace
          location_type: Company 
          status: Active
          children:
            - name: IAD
              description: IAD3 Metro
              location_type: Region
              status: Active
kind: ConfigMap
metadata:
  name: locations
  namespace: nautobot

Important

• This feature uses a new manifest structure based parent-child relationships.
• Location must be defined using the children field to represent the multiple children.

Example hierarchy:

Global
└── Company
    └── Region
        └── Site

[cardoe]

Any reason not to do an actual CRD?

[abhimanyu003]

Any reason not to do an actual CRD?

That can be done, but it may become a bit challenging to maintain multiple YAML files and different reconcile timings.
Few things need to run one after the other like Location Types need to be added first before Locations.

What can be done, is we create CRD for Locations that contains bot ( Location Type and Location ) and another for Groups etc.

The underlying logic will remain the same and can be refactored later. We can discuss this further.