Feature Request Overview  

Introduce Neutron "Port Flavors" as a first-class, RBAC-shareable primitive that bundles a vetted set of port behaviors—most critically QoS/DSCP marking, plus security-groups, port-security, allowed-address-pairs, DHCP/DNS options, binding hints (e.g., SR-IOV), and tags—into a single handle attachable at port-create time.
At creation, the server materializes the flavor into the concrete port attributes (with optional, policy-controlled tenant overrides). The design relies on existing Neutron QoS/DSCP semantics and ML2/OVN realization (OVN NB QoS rows), without changing current behavior for non-flavor ports.

Forward-looking: expose port_flavor metadata to CloudKitty so platform teams can rate/charge/showback premium ports (e.g., EF46 DSCP, SR-IOV/direct) by tenant/project.

Business justification

• Consistency at scale: Eliminates per-port flag sprawl by collapsing known-good settings into governed, reusable artifacts (like Nova flavors, for networking).

• Deterministic QoS: Standardizes DSCP marking across fleets; prevents drift and misconfig.

• Operational governance: Operators publish approved flavors; projects consume them via RBAC, reducing bespoke tuning and audit overhead.

• Hardware-aware profiles: Encodes SR-IOV/direct/offload hints once; tenants get simple, reliable outcomes.

• Chargeback/showback: Tagging ports with port_flavor_id (and optional cost_class/tags) enables CloudKitty meters and rating rules for premium network features.

• Backwards compatible: No impact on existing APIs or tenants who prefer current per-flag workflows.

 

Functional requirements

New API Resource: port_flavor

CRUD & RBAC

• Endpoints: POST /v2.0/port_flavors, GET /v2.0/port_flavors[/\{id}], PUT /v2.0/port_flavors/{id}{}, DELETE /v2.0/port_flavors/{id}{}.

• Shareable via RBAC; is_public and project-level shares supported.

Attributes

• id, name, description, is_public, tags[]

• QoS/DSCP: qos_policy_id (must contain exactly one DSCP rule for deterministic marking)

• Security posture: security_groups[], port_security_enabled

• L2/L3 templates: allowed_address_pairs_template[], extra_dhcp_opts_template[], dns_name_template, dns_domain

• Binding: binding:vnic_type (normal|direct|macvtap), binding:profile_template (JSON for SR-IOV/VF hints)

• Mutability policy: granular bitmap declaring which attributes tenants may override at create time

• Constraints: schema-level guards (e.g., SGs required when port-security enabled; DSCP values validated)

Validation & Errors

• 400 for invalid schema, missing/duplicate DSCP rules, or conflicting settings

• 403 for RBAC violations

• 404 for unknown flavor

• 409 when user overrides violate mutability or flavor constraints

Port Creation Association

• POST /v2.0/ports accepts port_flavor_id|name.

• Server materializes flavor → merges with user args only where allowed by mutability.

• Persist port_flavor_id on the port for audit, telemetry, and chargeback.

DSCP Marking Realization (ML2/OVN)

• Attaching a flavor with qos_policy_id binds the QoS policy to the port.

• ML2/OVN renders DSCP via OVN NB QoS rows on the logical switch port (directional matches as today).

• Overlay note: marking applies to inner headers; outer header behavior unchanged.

CLI / UX Surface

New (proposed) OpenStackClient commands

• openstack network port flavor create <name> [--qos-policy <policy>] [--security-group <sg> ...] [--binding-vnic-type <type>] [--extra-dhcp-opt name=<n>,value=<v> ...] [--tag <t> ...] [--share|--project <id>]

• openstack network port flavor list|show|set|delete

Consumer workflow

• openstack port create p1 --network netA --port-flavor gold-ef46

• • Equivalent to today's manual combination of:

    --qos-policy, --security-group, --binding-*, --extra-dhcp-opt, --enable-port-security, etc.
    

Mapping to existing knobs the flavor encapsulates

• QoS/DSCP: --qos-policy

• Security: {}security-group/{}no-security-group, enable/{-}-disable-port-security

• L2: --allowed-address ip-address=...,mac-address=...

• DHCP/DNS: --extra-dhcp-opt ...

• Binding: {}binding-vnic-type{-}{}, -binding-profile

Auditability & Drift Control

• Store port_flavor_id on the port; expose in GET/SHOW.

• Optional admin action: reconcile (reapply flavor to an existing port) with dry-run to preview changes.

Backward Compatibility

• No behavior change to existing APIs or flags; flavors are additive/opt-in.

Observability & Telemetry

• Emit events when flavors are created/updated and when materialized on port-create.

• Export port_flavor_id, port_flavor_name, and flavor.tags via metrics/logs for inventory and governance.

CloudKitty Integration (chargeback/showback)

• Expose port_flavor_id, port_flavor_name, and optional cost_class tag in metering pipelines (e.g., Gnocchi/Prometheus exporters → CloudKitty).

• Provide a reference rating map:

• • baseline (best-effort) → rate X

• • af31 (assured forwarding) → rate X+Δ

• • ef46 (expedited forwarding) or direct/sriov → premium rate X+Δ+Ω

• Include sample CloudKitty mappings and labels so tenants see premium ports on invoices/showback.

Acceptance & Test Outline

• Create a flavor with DSCP=46 + SG baseline; create 100 ports using it; verify each port has the QoS policy and OVN DSCP rows.

• Negative tests: invalid DSCP/duplicate rules; RBAC denial; mutability violations.

• Performance: flavor resolution adds negligible latency to port-create.

• Telemetry: port_flavor_* labels are visible end-to-end and consumable by CloudKitty.

 

Describe the customer impact

• https://issues.redhat.com/browse/ACCT-832

(Optional) Point of contact

• gprocuni@redhat.com 
• aaustin@redhat.com 

(Optional) Additional links

Click More > Link to add any links to issues, such as an outcome, that are related to this feature request.