feat: Routing Profile Configuration via REST API

[shevchenko-evgeny]

Is this a new feature, an enhancement, or a change to existing functionality?

New Feature

How would you describe the priority of this feature request

Critical (currently preventing usage)

Please provide a clear description of problem this feature solves

The current implementation does not allow Routing Profiles to be created, modified, or assigned through the REST API. As a result:

• Routing Profile configuration requires direct access to site configuration files.
• Changes cannot be performed dynamically by automation systems.
• Infrastructure operators must predefine all Routing Profiles in advance, reducing operational flexibility.

This limitation makes the feature difficult to use in dynamic, non-trusted multi-tenant deployments where network configuration must be managed programmatically and on demand.

Feature Description

The NVIDIA Infrastructure Controller currently supports BGP peering managing through Routing Profiles, as documented in the Day-2 Operations guide:

BGP peering

This functionality is highly valuable for automating network connectivity and route advertisement. However, Routing Profiles must currently be defined statically within site configuration files.

Describe your ideal solution

Introduce a REST API for Routing Profile lifecycle management

Describe any alternatives you have considered

No response

Additional context

No response

Code of Conduct

• I agree to follow NVIDIA Infra Controller's Code of Conduct
• I have searched the open feature requests and have found no duplicates for this feature request

[bcavnvidia]

Right now...

• Profiles get attached to tenants and optionally to VPCs.
• If a VPC is created without specifying a profile, it inherits from the tenant.
• If the VPC specifies a profile, the profile has to be "as or less privileged" than the tenant requesting it.
• The privilege level of a profile is defined buy the site operator, whoever controls the config, and there's a line between who controls the config and who can make API calls.

Seems like the likely ways we can satisfy this issue would be...

1. Full CRUD for routing profiles - With full profile lifecycle management, we just shift that to the DB: a privileged tenant would be in control of profile life-cycle, and non-privileged tenants can select profiles with the same or lower "privileges."
   The config definition path would/could still allow config to define it so the UX is simple for those who don't want a whole lot of ceremony to get going and just expect basic profiles that don't change much. This would be a fully new feature, so it'd take a little time.
2. In-line routing profiles per VPC - Existing, config driven profiles stay unchanged. No need for profile CRUD. VPCs get a field to hold a full profile. A privileged tenant would be in control of creating VPCs with full, in-lined profiles that override any existing profile, (and maybe normal tenants are allowed to inline profiles as long as they are a subset of the existing tenant profile, but that could come later if there were a use-case). Simple, much faster to implement, and sensible when the desire is per-VPC ephemeral profiles vs having to manage profile lifecycles just to create per-VPC profiles and when the expectation is that deployments will generally be split between those that want per-VPC profiles and those that don't need more than a few well-known profiles at initial site deployment/creation time.
3. Do both, starting with in-line. The question is whether that's redundant.

[deepak-poornachandra]

@nick-vetro - Can you pls add the milestone this will be part of ?
cc: @bcavnvidia

[bcavnvidia]

@shevchenko-evgeny Curious which describes/satisfies your current needs:

1. Fully defined, API-driven routing-profiles that can be applied at tenant or VPC level (option 1 above)
2. Ephemeral/in-line routing-profiles per-VPC (option 2 above)