Bug 1080646 - admin_password not set in /etc/neutron/metadata_agent.ini
Summary: admin_password not set in /etc/neutron/metadata_agent.ini
Keywords:
Status: CLOSED DUPLICATE of bug 1055852
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-foreman-installer
Version: 4.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: z4
: 4.0
Assignee: Jiri Stransky
QA Contact: Ami Jeain
URL:
Whiteboard:
Depends On:
Blocks: 1040649 1104759
TreeView+ depends on / blocked
 
Reported: 2014-03-25 21:03 UTC by Steve Reichard
Modified: 2014-06-04 16:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-28 13:15:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Steve Reichard 2014-03-25 21:03:10 UTC
Description of problem:

In a Cisco config we issues with metadata working.  this was traced down to the admin_password being set to "CHANGEME" in  /etc/neturon/metadata_agent.ini.

When I look at quickstack:neutron:networker, I see the following for setting the metadata:


  class { 'neutron::agents::metadata':
    auth_password => $admin_password,
    shared_secret => $neutron_metadata_proxy_secret,
    auth_url      => "http://${controller_priv_host}:35357/v2.0",
    metadata_ip   => $controller_priv_host,
  }


But Is don't see admin_password being set:

class quickstack::neutron::networker (
  $fixed_network_range           = $quickstack::params::fixed_network_range,
  $neutron_metadata_proxy_secret = $quickstack::params::neutron_metadata_proxy_secret,
  $neutron_db_password           = $quickstack::params::neutron_db_password,
  $neutron_user_password         = $quickstack::params::neutron_user_password,
  $nova_db_password              = $quickstack::params::nova_db_password,
  $nova_user_password            = $quickstack::params::nova_user_password,
  $controller_priv_host          = $quickstack::params::controller_priv_host,
  $ovs_tunnel_iface              = 'em1',
  $mysql_host                    = $quickstack::params::mysql_host,
  $qpid_host                     = $quickstack::params::qpid_host,
  $external_network_bridge       = 'br-ex',
  $tenant_network_type           = $quickstack::params::tenant_network_type,
  $ovs_bridge_mappings           = $quickstack::params::ovs_bridge_mappings,
  $ovs_bridge_uplinks            = $quickstack::params::ovs_bridge_uplinks,
  $ovs_vlan_ranges               = $quickstack::params::ovs_vlan_ranges,
  $tunnel_id_ranges              = '1:1000',
  $enable_tunneling              = $quickstack::params::enable_tunneling,
  $verbose                       = $quickstack::params::verbose,
) 

I am not sure but when I was searcing for BZ I came accross Bug 1028619 which looks like it removed admin_password and is using neutron_user_password, which probably should also be done here.


Version-Release number of selected component (if applicable):

[root@cvf13-foreman neutron]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 6.5 (Santiago)
[root@cvf13-foreman neutron]# uname -a
Linux cvf13-foreman.os.cvfdmz.sdu 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Dec 13 06:58:20 EST 2013 x86_64 x86_64 x86_64 GNU/Linux
[root@cvf13-foreman neutron]# yum list installed | grep -e puppet -e foreman
This system is receiving updates from Red Hat Subscription Management.
This system is not registered with RHN Classic or RHN Satellite.
You can use rhn_register to register.
RHN Satellite or RHN Classic support will be disabled.
foreman.noarch                       1.3.0.2-1.el6sat      @rhel-6-server-openstack-4.0-rpms
foreman-installer.noarch             1:1.3.0-1.el6sat      @rhel-6-server-openstack-4.0-rpms
foreman-mysql.noarch                 1.3.0.2-1.el6sat      @rhel-6-server-openstack-4.0-rpms
foreman-mysql2.noarch                1.3.0.2-1.el6sat      @rhel-6-server-openstack-4.0-rpms
foreman-proxy.noarch                 1.3.0-3.el6sat        @rhel-6-server-openstack-4.0-rpms
foreman-selinux.noarch               1.3.0-1.el6sat        @rhel-6-server-openstack-4.0-rpms
openstack-foreman-installer.noarch   1.0.3-1.el6ost        @rhel-6-server-openstack-4.0-rpms
packstack-modules-puppet.noarch      2013.2.1-0.22.dev956.el6ost
puppet.noarch                        3.2.4-3.el6_5         @rhel-6-server-openstack-4.0-rpms
puppet-server.noarch                 3.2.4-3.el6_5         @rhel-6-server-openstack-4.0-rpms
ruby193-rubygem-foreman_openstack_simplify.noarch
rubygem-foreman_api.noarch           0.1.6-1.el6sat        @rhel-6-server-openstack-4.0-rpms
[root@cvf13-foreman neutron]# 



How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Jiri Stransky 2014-03-28 12:55:03 UTC
I think this has already been fixed upstream as bug 1055852:

https://github.com/redhat-openstack/astapor/commit/cefe430dbc8e66f37be11aaa35d86a7a91916f1c

The relevant part of metadata_agent.ini that got generated for me:

auth_url = http://192.168.122.10:35357/v2.0
auth_region = RegionOne
admin_tenant_name = services
admin_user = neutron
admin_password = 07275844ee5ee784f010d5ac504f4be6

(The "07275844ee5ee784f010d5ac504f4be6" string is what i have in "neutron_user_password" parameter in Foreman.)

I used Astapor master but openstack-foreman-installer-1.0.5-1.el6ost.noarch (from 2014-03-18.2 build) seems to have the fixed code present too.

Comment 2 Jiri Stransky 2014-03-28 13:15:45 UTC

*** This bug has been marked as a duplicate of bug 1055852 ***

Comment 3 Steve Reichard 2014-03-31 12:09:17 UTC
I just installed a local environment to check.  I see them set to the following.
Tried googling to see if this is valid.  But haven't found it.   


admin_tenant_name = %SERVICE_TENANT_NAME%
admin_user = %SERVICE_USER%
admin_password = %SERVICE_PASSWORD%

Comment 4 Jiri Stransky 2014-03-31 13:16:13 UTC
Hmm no that doesn't seem valid to me. Two things to check come to my mind:

* Are you using a recent RHOS build?

* I think the neutron-metadata-agent service is only configured to run on Networker node. Maybe you were looking at the Controller node instead?

Comment 5 Steve Reichard 2014-03-31 13:27:13 UTC
you are correct, I was looking on the wrong node.

On the networker, things do look good.


Thank you


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