Bug 1256816 - Backport request: Support dhcp metadata service for all networks
Summary: Backport request: Support dhcp metadata service for all networks
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 7.0 (Kilo)
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: z3
: 7.0 (Kilo)
Assignee: Nir Magnezi
QA Contact: Toni Freger
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-25 13:52 UTC by Nir Magnezi
Modified: 2019-09-10 14:10 UTC (History)
8 users (show)

Fixed In Version: openstack-neutron-2015.1.1-8.el7ost
Doc Type: Bug Fix
Doc Text:
Previously, in certain circumstances (such as deployments using a vendor-specific implementation of the neutron L3 API), the neutron router was not available to provide the IP route for the metadata service. This issue can be addressed using DHCP to allocate this information. Setting 'force_metadata = False' causes the DHCP server to append specific host routes to the DHCP request. As a result of performing this configuration change, the metadata service will be activated for all networks.
Clone Of:
Environment:
Last Closed: 2015-12-21 16:58:35 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
dhcp log (2.34 KB, text/plain)
2015-09-24 12:47 UTC, Toni Freger
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1483939 0 None None None Never
Launchpad 1499406 0 None None None Never
OpenStack gerrit 216750 0 'None' ABANDONED Support dhcp metadata service for all networks 2020-07-30 14:39:47 UTC
OpenStack gerrit 227358 0 'None' MERGED The option force_metadata=True breaks the dhcp agent 2020-07-30 14:39:47 UTC
Red Hat Product Errata RHBA-2015:2652 0 normal SHIPPED_LIVE openstack-neutron bug fix advisory 2015-12-21 21:50:47 UTC

Description Nir Magnezi 2015-08-25 13:52:37 UTC
Description of problem:
=======================
Vendors implementing Neutron L3 API in their devices may not be able to provide metadata server access via the Neutron router.
In such cases it is useful for the deployer to force metadata server access using host route injection as done for isolated network segments.

The upstream patch:
===================
https://review.openstack.org/#/c/211963

Comment 7 Nir Magnezi 2015-09-24 08:34:06 UTC
Verification Steps:
===================

1. Create isolated network and subnet:
  $ neutron net-create isolated
  $ neutron subnet-create isolated 30.3.3.0/24 --no-gateway --name isolated_subnet

2. Create key and boot an instance:
  $ nova keypair-add test > test
  $ nova boot cirros_test --flavor 42 --image 958a122e-2954-45fa-9f90-b7a0d60b4d91 --key-name test --nic net-id=1124cb9f-eb9c-48d7-98e2-7652c8abc22c
 
   
3. Allow SSH in your security group rules.

4. SSH to your instance via qdhcp namespace using your key
  $ sudo ip netns exec qdhcp-1124cb9f-eb9c-48d7-98e2-7652c8abc22c ssh -i test cirros.3.3

5. From within th VM verify that the route is there and you can reach the metadata service:
  $ route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
30.3.3.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.169.254 30.3.3.1        255.255.255.255 UGH   0      0        0 eth0

 
  $ curl http://169.254.169.254:/openstack
2012-08-10
2013-04-04
2013-10-17

Comment 8 Nir Magnezi 2015-09-24 12:00:08 UTC
Some additions:

* In Step 2, don't use --no-gateway.

* You may or may not attach a router to your network:

VM routing table should look like:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         55.5.5.1        0.0.0.0         UG    0      0        0 eth0
55.5.5.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.169.254 55.5.5.2        255.255.255.255 UGH   0      0        0 eth0


55.5.5.2 --> DHCP port.

dnsmasq config:
$ cat /opt/openstack/data/neutron/dhcp/96b93669-9147-45ac-a5d5-26f2a68f4f45/opts
tag:tag0,option:classless-static-route,169.254.169.254/32,55.5.5.2,0.0.0.0/0,55.5.5.1
tag:tag0,249,169.254.169.254/32,55.5.5.2,0.0.0.0/0,55.5.5.1
tag:tag0,option:router,55.5.5.1
tag:tag0,option:dns-server,55.5.5.2

Comment 9 Toni Freger 2015-09-24 12:45:40 UTC
The verification is FailedQA

Tested with AIO on rhel7.1
openstack-neutron-2015.1.1-5.el7ost.noarc

Steps to reproduce:
1. Create a network with attached router
2. set within /etc/neutron/dhcp-agent.ini  
"force_metadata = True"
restart the agent
3.create a VM with ssh key, it should transfer to a VM via metadata

Result: VM didn't get an IP address

The log is attached

Comment 10 Toni Freger 2015-09-24 12:47:11 UTC
Created attachment 1076534 [details]
dhcp log

Comment 11 Nir Magnezi 2015-09-24 16:15:27 UTC
This is a bug originated from the upstream patch.
Working on a fix: https://review.openstack.org/#/c/227358/

Comment 13 Nir Magnezi 2015-10-06 08:29:04 UTC
The Fix for the issue raised in comment #9 got merged[1] both to upstream master and Liberty.
This is also handled in a bug 1267669.

[1] https://review.openstack.org/#/q/I4e1d918e3a24dd483ee134021f587ae4520bf431,n,z

Comment 15 Toni Freger 2015-11-23 07:51:46 UTC
Thanks Nir, we will retest it.

Comment 16 Toni Freger 2015-11-23 11:32:02 UTC
Verified on openstack-neutron-2015.1.2-2.el7ost.noarch
Rhel7.2 AIO


cat /var/lib/neutron/dhcp/8092a357-6bd4-46db-b272-2632a57c8dd7/opts
tag:tag0,option:classless-static-route,169.254.169.254/32,10.10.10.2,0.0.0.0/0,10.10.10.1
tag:tag0,249,169.254.169.254/32,10.10.10.2,0.0.0.0/0,10.10.10.1
tag:tag0,option:router,10.10.10.1
tag:tag0,option:dns-server,10.10.10.2

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.10.10.1      0.0.0.0         UG    0      0        0 eth0
10.10.10.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.169.254 10.10.10.2      255.255.255.255 UGH   0      0        0 eth

Comment 18 errata-xmlrpc 2015-12-21 16:58:35 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2015:2652


Note You need to log in before you can comment on or make changes to this bug.