nova baremetal requires manual neutron setup for metadata access

Bug #1239481 reported by Robert Collins
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ironic
Invalid
Low
Unassigned
OpenStack Compute (nova)
Won't Fix
Low
Unassigned
neutron
Expired
Undecided
Unassigned
tripleo
Invalid
Low
Unassigned

Bug Description

a subnet setup with host routes can use a bare metal gateway as long as there is a metadata server on the same network:
neutron subnet-create ... (network, dhcp settings etc) ----host_routes type=dict list=true destination=169.254.169.254/32,nexthop=<nova metadata server> --gateway_ip=<actual gateway>

But this requires manual configuration - it would be nice if nova could configure this as part of bringing up the network for a given node.

Revision history for this message
Robert Collins (lifeless) wrote :

Relatedly, and possibly a different bug - we should be able to use neutron to configure the physical switches to handle 169.254.169.254 correctly and thus handle multi-subnet baremetal clouds trivially.

Changed in nova:
status: New → Triaged
importance: Undecided → Low
tags: added: neutron-baremetal
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix proposed to tripleo-incubator (master)

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

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Related fix merged to tripleo-incubator (master)

Reviewed: https://review.openstack.org/51502
Committed: http://github.com/openstack/tripleo-incubator/commit/44ea04e75480330676dda5aa656f96a2a1bd3075
Submitter: Jenkins
Branch: master

commit 44ea04e75480330676dda5aa656f96a2a1bd3075
Author: Robert Collins <email address hidden>
Date: Mon Oct 14 14:30:52 2013 +1300

    Separate out metadata and default routes.

    With the host routes extension we can access the metadata service
    without having to mess about with the default route, increasing
    performance. Yay. Only works for single L2 networks (because any
    router seeing traffic for 169.254.169.254 will discard it unless
    explicitly configured. Configuring that is a use case for neutron
    baremetal...

    Related-Bug: #1239481
    Change-Id: If434cc2e71ec9ee71c6e75b5aa4eff0a351d107b

Revision history for this message
Joe Gordon (jogo) wrote :

Since we are in the process of deprecating nova maremetal, we should focus work on ironic instead.

Changed in nova:
status: Triaged → Opinion
Revision history for this message
aeva black (tenbrae) wrote :

Please confirm whether this affects Ironic.

Changed in ironic:
status: New → Incomplete
Revision history for this message
Robert Collins (lifeless) wrote :

yes it affects Ironic.

Changed in ironic:
status: Incomplete → New
Changed in nova:
status: Opinion → Won't Fix
Revision history for this message
Bruce Thompson (brucet-s) wrote :

Unless I am missing something, I think this is a fairly major issue with Ironic / Neutron. We want to use Ironic to include bare metal applications as part of our cloud orchestration strategy. Instance metadata / Cloud-init is a core component to having unified orchestration across bare metal and virtualized applications. I went and tracked down how instance metadata works with Neutron today with virtual machines. It looks like the basic hook to redirect virtual machine requests to http://169.254.169.254 to the neutron-metadata-agent relies on a process running on the host OS (libvirt) of the compute node that the virtual machine is running on. See:
https://answers.launchpad.net/neutron/+question/240269 for details.

A bare metal node that has booted will not be able to use this hook since it is not running on a hypervisor with a host OS and libvirt. So what's the fix for bare metal nodes with Ironic? Am I missing something?

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

I am wondering if this issue can be considered blueprint work. My gut feel tells me that its scope is a lot larger than a simple bug fix.

Changed in neutron:
status: New → Confirmed
aeva black (tenbrae)
Changed in ironic:
status: New → Confirmed
aeva black (tenbrae)
Changed in ironic:
importance: Undecided → Medium
Revision history for this message
Kyle Mestery (mestery) wrote :

I agree with Armando, I think this is likely a blueprint/spec.

aeva black (tenbrae)
Changed in ironic:
importance: Medium → Undecided
Dmitry Tantsur (divius)
Changed in ironic:
importance: Undecided → Low
Revision history for this message
Steven Hardy (shardy) wrote : potentially eol bug

This bug was reported against an old version of TripleO, and may no longer be valid.

Since it was reported before the start of the liberty cycle (and our oldest stable
branch is stable/liberty), I'm marking this incomplete.

Please reopen this (change the status from incomplete) if the bug is still valid
on a current supported (stable/liberty, stable/mitaka or trunk) version of TripleO,
thanks!

Changed in tripleo:
status: Triaged → Incomplete
Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote : Cleanup EOL bug report

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (INCUBATOR-JUNO, LIBERTY, MITAKA, NEWTON).
  Valid example: CONFIRMED FOR: INCUBATOR-JUNO

Changed in neutron:
status: Confirmed → Expired
Revision history for this message
Jim Rollenhagen (jim-rollenhagen) wrote :

While this is an ironic-specific problem, I don't believe the fix here is in ironic.

Seems that Neutron and/or ML2 mechanisms need to set a proper route for this in the physical switch, but I'm not sure which layer that would be in. (I assume usually the agent on the host does it)

Changed in ironic:
status: Confirmed → Invalid
Revision history for this message
Emilien Macchi (emilienm) wrote :

This bug was last updated over 180 days ago, as tripleo is a fast moving project and we'd like to get the tracker down to currently actionable bugs, this is getting marked as Invalid. If the issue still exists, please feel free to reopen it.

Changed in tripleo:
status: Incomplete → Invalid
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.