Description of problem: local-ipv4 requests against the ec2 metadata service return both instance and controller IPv4 addresses. For example : root@instance # curl -q http://169.254.169.254/2009-04-04/meta-data/local-ipv4 192.168.12.10, 10.10.10.10 This has been raised [1] and resolved [2] upstream. Version-Release number of selected component (if applicable): openstack-nova-api-2014.1.3-4.el7ost.noarch openstack-nova-cert-2014.1.3-4.el7ost.noarch openstack-nova-common-2014.1.3-4.el7ost.noarch openstack-nova-compute-2014.1.3-4.el7ost.noarch openstack-nova-conductor-2014.1.3-4.el7ost.noarch openstack-nova-console-2014.1.3-4.el7ost.noarch openstack-nova-novncproxy-2014.1.3-4.el7ost.noarch openstack-nova-scheduler-2014.1.3-4.el7ost.noarch python-nova-2014.1.3-4.el7ost.noarch python-novaclient-2.17.0-2.el7ost.noarch How reproducible: Always. Steps to Reproduce: 1. root@instance # curl -q http://169.254.169.254/2009-04-04/meta-data/local-ipv4 Actual results: Both the instance and controller IPv4 addresses are returned. Expected results: Only the instance IPv4 address is returned. Additional info: [1] https://bugs.launchpad.net/nova/+bug/1334857 [2] https://review.openstack.org/#/c/104138/
code is in openstack-nova-api-2014.2.3-65.el7ost.noarch automation passed https://rhos-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/RHOS/view/RHOS6/job/rhos-jenkins-rhos-6.0-puddle-rhel-7.2-multi-node-packstack-neutron-ml2-vxlan-rabbitmq-tempest-git-all/17/
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://rhn.redhat.com/errata/RHBA-2016-0500.html