User can not provision ironic node via nova when providing pre-created port
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Magnum |
Incomplete
|
Low
|
Dane LeBlanc | ||
OpenStack Compute (nova) |
Fix Released
|
Undecided
|
Unassigned | ||
OpenStack Heat |
Confirmed
|
Undecided
|
Unassigned |
Bug Description
When booting a nova instance with baremetal flavor, one can not provide a pre-created neutron port to "nova boot" command.
The reason is obvious - to successfully deploy, mac address of the port must be the same as mac address of the ironic port corresponding to the ironic node where provisioning will happen, and although it is possible to specify a mac address during port create, a user can not know to which exactly ironic node provisioning will be assigned to by nova compute (more over, ordinary user has no access to list of ironic ports/macs whatsoever).
This is most probably a known limitation, but the big problem is that it breaks many sorts of cloud orchestration attempts. For example, the most flexible in terms of usage approach in Heat is to pre-create a port, and create the server with this port provided (actually this is the only way if one needs to assign a floating IP to the instance via Neutron). Some other consumers of Heat extensively use this approach.
So this limitation precludes Murano or Sahara to provision their instances on bare metal via Nova/Ironic.
The solution might be to update the mac of the port to correct one (mac address update is possible with admin context) when working with baremetal nodes/Ironic.
Changed in nova: | |
status: | New → Confirmed |
Changed in magnum: | |
assignee: | nobody → Dane LeBlanc (leblancd) |
Changed in heat: | |
status: | New → Confirmed |
tags: | added: release-notes |
tags: | removed: release-notes |
Changed in magnum: | |
importance: | Undecided → Wishlist |
importance: | Wishlist → Low |
status: | New → Incomplete |
Changed in heat: | |
milestone: | none → no-priority-tag-bugs |
This is going to be incredibly environment specific in the future, and never work with an Ironic deployment today. I'd prefer to block calls like this for instances destined for an ironic driver, and fix it in heat/magnum.