User can not provision ironic node via nova when providing pre-created port

[Pavlo Shchelokovskyy]

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.

[Jim Rollenhagen (jim-rollenhagen)]

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.

[John Garbutt (johngarbutt)]

I think we may have fixed this now (depending on your neutron back end): https://github.com/openstack/nova/commit/15c583cb7c2d8fbad7c2334971a49ab520d22fa3

Can we see if this can be reproduced using the latest master for Nova?

[Pavlo Shchelokovskyy (pshchelo)]

I just tested this on master. It works now! (at least on DevStack):

- with Ironic set w/o multitenancy support, it works only with ports pre-created in what Ironic treats as provisioning network (by default in DevStack the 'private' one). This is expected for such mode of Ironic deployment

- with Ironic set with multitenancy support (e.g. see the job gate-tempest-dsvm-ironic-multitenant-network-nv for configuration example) it works with any port (I've created a new network with subnet, created a port there and successfully provisioned a Nova instance on Ironic node with this port provided to 'nova boot').

Two questions to John though:

- what do you mean by 'depending on network backend'? Do you know of any example where it would not work? What are requirements for the network backend for this to work?

- Would it be possible to backport this patch at least to Mitaka?

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/464710

[Matt Riedemann (mriedem)]

https://github.com/openstack/nova/commit/15c583cb7c2d8fbad7c2334971a49ab520d22fa3 wouldn't be backported to mitaka because mitaka is end of life at this point upstream, but also because that change was part of a larger blueprint refactor series in newton, so it's not a good candidate for a backport. I'm going to mark this as fixed for nova.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/464710
Committed: https://git.openstack.org/cgit/openstack/magnum/commit/?id=769f0eea41f0703deb6d239293af92feff44eb5c
Submitter: Jenkins
Branch: master

commit 769f0eea41f0703deb6d239293af92feff44eb5c
Author: Mark Goddard <email address hidden>
Date: Sun May 14 09:02:36 2017 +0100

    Extract kubernetes baremetal ports

    Previously the master's private IP address was not pushed through to the
    minion configuration when the load balancer is disabled as the heat
    templates were not wired up in this case. This change resolves that
    issue and makes it possible for security groups to be applied to the
    master and minion ports.

    Change-Id: If85a5434f014c5a09b54dda710d13739e9bff928
    Related-Bug: #1544195