Allow to set Ironic node `properties`.

[synthe102]

User Story

As a user I would like to be able to set custom properties in Ironic because some hardware vendor rebrand firmwares, making it impossible for Ironic to correctly guess the vendor without setting properties.vendor.

Detailed Description

I would like to be able to set Ironic's properties either through an annotation or a new field on the BMH CRD.

Annotation:

apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  annotations:
    properties.metal3.io: '{"vendor":"ami"}'
  name: my-server
spec: {}

CRD :

// BareMetalHostSpec defines the desired state of BareMetalHost.
type BareMetalHostSpec struct {
    Properties map[string]string `json:"properties,omitempty"`
}

Anything else you would like to add:

An example use case it to be able to set the vendor to "ami" on GBx00 Nvidia GPU servers, as the firmware is AMI, but the vendor is reported as Dell, which makes Ironic send the wrong request to set the boot device. Setting the properties.vendor seems more straightforward than patching Ironic to have a more complex vendor detection logic (if it is even possible).

/kind feature

[Rozzii]

I would suggest something a bit more generic, we could have something like :

type BareMetalHostSpec struct {
    HostProvisionerProperties map[string]string 
}

IMO:
There are a lot of things on Ironic Node API like "description, extra, properties," these are quite specific to Ironic and might not be relevant for other provisioners. I would say 1 generic map for all these non BMO related metadata could be stored in 1 spec value that clearly states it is related to host specific provisioner tuning. I don't think it is a good idea to 1to1 map Ironic API to BMH.

[Rozzii]

/triage accepted
/kind feature

[Rozzii]

We agreed on 2026 Feb.11. Community meeting to go in the direction of the generic "metadata map".

[dtantsur]

We agreed on 2026 Feb.11. Community meeting to go in the direction of the generic "metadata map".

Annotations are generic metadata maps, you don't need to invent more. Even less to fix one field which should most likely be fixed on the Ironic side.

[Rozzii]

We agreed on 2026 Feb.11. Community meeting to go in the direction of the generic "metadata map".

Annotations are generic metadata maps, you don't need to invent more. Even less to fix one field which should most likely be fixed on the Ironic side.

I was pushing toward the CRD direction as annotations are not as explicit on API documentation they require separate docs , it is just my personal preference to go in the CRD direction, not a deal breaker for me I just ask for a descriptive name that specifies that this is metadata related specific to the provisioner.

[Rozzii]

We agreed on 2026 Feb.11. Community meeting to go in the direction of the generic "metadata map".

Annotations are generic metadata maps, you don't need to invent more. Even less to fix one field which should most likely be fixed on the Ironic side.

I was pushing toward the CRD direction as annotations are not as explicit on API documentation they require separate docs , it is just my personal preference to go in the CRD direction, not a deal breaker for me I just ask for a descriptive name that specifies that this is metadata related specific to the provisioner.

But then you have described your opinion to limit the scope to a vendor override instead of the generic provisioner metadata map. @synthe102 @dtantsur I guess then this whole PR will be rewritten and limited to a vendor override. If that satisfies both parties so be it .