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

Bug #1544195 reported by Pavlo Shchelokovskyy
22
This bug affects 4 people
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.

Tags: ironic
Changed in nova:
status: New → Confirmed
Dane LeBlanc (leblancd)
Changed in magnum:
assignee: nobody → Dane LeBlanc (leblancd)
Changed in heat:
status: New → Confirmed
Revision history for this message
Jim Rollenhagen (jim-rollenhagen) wrote :

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.

tags: added: release-notes
tags: removed: release-notes
Revision history for this message
John Garbutt (johngarbutt) wrote :

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?

Changed in nova:
status: Confirmed → Incomplete
Revision history for this message
Pavlo Shchelokovskyy (pshchelo) wrote :

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?

Adrian Otto (aotto)
Changed in magnum:
importance: Undecided → Wishlist
importance: Wishlist → Low
status: New → Incomplete
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to magnum (master)

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

Revision history for this message
Matt Riedemann (mriedem) wrote :

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.

Changed in nova:
status: Incomplete → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to magnum (master)

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

Rico Lin (rico-lin)
Changed in heat:
milestone: none → no-priority-tag-bugs
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.