Skip to content

Conversation

@abhimanyu003
Copy link
Contributor

@abhimanyu003 abhimanyu003 commented Nov 20, 2025

Summary
This PR enhances the Nautobot operator so it can read Nautobot credentials from a referenced Secret and load device-type data from one or more ConfigMaps.

What this change does

  • Reads the Nautobot API token (or other keys) from the Secret referenced in the custom resource.
  • Loads device-type definitions from one or more ConfigMaps specified in the custom resource.
  • Supports multiple device-type references.

How it works

  1. Deploy the operator to the cluster.
  2. Create a Nautobot custom resource (example YAML below).
  3. The operator reads the referenced Secret and ConfigMap and sync the device-type data.

Usage example

apiVersion: sync.rax.io/v1alpha1
kind: Nautobot
metadata:
  name: nautobot-sample
spec:
  deviceTypeRef:
    - configMapSelector:
        name: device-types
        namespace: nautobot
      name: device-types
  nautobotSecretRef:
    key: NAUTOBOT_SUPERUSER_API_TOKEN
    name: nautobot-env
    namespace: default
  syncIntervalSeconds: 5

PS

  • You can provide multiple deviceTypeRef entries to load device types from several ConfigMaps.
  • If needed, update the ConfigMap and Secret references in the custom resource to point to the correct resources in your cluster.

Rough Diagram

image

Copy link
Contributor

@cardoe cardoe left a comment

Choose a reason for hiding this comment

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

Overall the change is good but too big to really review line by line or file by file. Let's rebase this and get it running in the dev environment and see it in action.

How do we define the CRD? From an object or by writing the YAML? I think we'll need to update the deployment docs around this going forward as well.

cardoe and others added 30 commits November 29, 2025 14:52
neutron's docs state that start-time needs to be defined. Increase the
number of workers as well.
When neutron starts up it is cleaning up OVN and it might take some
extra time to be ready so increase the amount of time.
This was pinned only for macOS testing of the code base and not an
actual runtime dependency so remove it to avoid version conflicts in the
actual deployed code.
If we are able to read the physical_network from the port binding
information then we should do that over looking it up.

Uses: https://review.opendev.org/c/openstack/ironic/+/964570
Switched to using more of a two part build in the containers to install
everything in the build layer and then copy it into the runtime
container to shrink them further. Switch to using uv exclusively to make
it consistent with the build tooling we use. Add the OpenStack
constraint file to ensure we do not upgrade to too new of a version when
installing additional dependencies.
The version of sushy that our current version of Ironic (2025.2) depends
on and is included in our container has sushy-oem-idrac included in it
and the Ironic code base will use it over sushy-oem-idrac. So there is
no point in installing this.
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.

6 participants