https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Configuring_the_Director.html In section "3.7. CONFIGURING THE DIRECTOR" (and in the sample conf file) local_ip is shown to default to 192.0.2.1/24 and corresponding vip properties: undercloud_public_vip = 192.0.2.2 undercloud_admin_vip = 192.0.2.3 I set my local_ip to be a /27 and left the netmask off the *_vip properties. running `ip addr` showed them set to /32 correcting the netmask in the undercloud.conf file fixed netmask correctly. I'd suggest updating the doc (and the sample.conf) show the following defaults, so this is clear: local_ip = 192.0.2.1/24 undercloud_public_vip = 192.0.2.2/24 undercloud_admin_vip = 192.0.2.3/24
Assigning to Dan for review.
Hi Brian, Implementing this fix and will be published early this week. - Dan
Hi Brian, I've updated the docs to include the subnet with the *_vip params: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Configuring_the_Director.html Will be closing this bug, but please feel free to reopen if there's anything else I should correct.
(In reply to Dan Macpherson from comment #6) > Hi Brian, > > I've updated the docs to include the subnet with the *_vip params: > > https://access.redhat.com/documentation/en-US/ > Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/ > Director_Installation_and_Usage/sect-Configuring_the_Director.html > > Will be closing this bug, but please feel free to reopen if there's anything > else I should correct. When applying the following to my undercloud.conf undercloud_public_vip = 192.0.2.2/24 undercloud_admin_vip = 192.0.2.3/24 My undercloud installation fails when using SSL+SELinux. If I set undercloud.conf without the octet, undercloud_public_vip = 192.0.2.2 undercloud_admin_vip = 192.0.2.3 The installation works with SSL+SELinux. FYI, To get SSL+SELinux to work, I referenced BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1242660 I'm not sure if the issue is related to https://bugzilla.redhat.com/show_bug.cgi?id=1252846 with regards to the Common Name when generating the SSL cert. However, with the octet in place in the undercloud.conf file, then running: openssl req -new -x509 -key privkey.pem -out cacert.pem -days 365 When the prompt of Common Name displays, I tried both 192.0.2.2 and 192.0.2.2/24 and both cases cause undercloud failure. Failure below: Warning: Permanently added '192.0.2.1' (ECDSA) to the list of known hosts. The following cert files already exist, use --rebuild to remove the existing files before regenerating: /etc/keystone/ssl/certs/ca.pem already exists /etc/keystone/ssl/private/signing_key.pem already exists /etc/keystone/ssl/certs/signing_cert.pem already exists Connection to 192.0.2.1 closed. PKI initialization in init-keystone is deprecated and will be removed. + openstack role show ResellerAdmin WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. ERROR: openstack Could not determine a suitable URL for the plugin + openstack role create ResellerAdmin WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. ERROR: openstack Could not determine a suitable URL for the plugin [2015-08-24 15:42:02,250] (os-refresh-config) [ERROR] during post-configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/post-configure.d']' returned non-zero exit status 1] [2015-08-24 15:42:02,250] (os-refresh-config) [ERROR] Aborting... Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 526, in install _run_orc(instack_env) File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 461, in _run_orc _run_live_command(args, instack_env, 'os-refresh-config') File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 297, in _run_live_command raise RuntimeError('%s failed. See log for details.', name) RuntimeError: ('%s failed. See log for details.', 'os-refresh-config') ERROR: openstack Command 'instack-install-undercloud' returned non-zero exit status 1 If I go and change my undercloud.conf file and remove the octet from undercloud_public_vip & undercloud_admin_vip, and make sure that when I generate the SSL cert that I use the IP found within undercloud_public_vip it installs successfully. Regards, Roger
Just to add, The successful install still sees the issue that Brain mentioned. When I do a `ip addr` the *vips have an netmask octet of /32
As rlopez reported, adding the netmask to the end of the vip values is not correct. The defaults should _just_ be the ip addresses. The /32 is normal. I'm not sure of all the details, but vips are always displayed that way. Dan, should I open a new bug for this or re-open this one? Thanks.
Hi all, I'm facing too this bug but I have some news. I configured the directives: undercloud_public_vip = 172.16.111.2 undercloud_admin_vip = 172.16.111.3 My network is /24 , as wrote here: network_cidr = 172.16.111.0/24 As other people said, I have the /32 ip unless I update the file with the specific netmask. If I change both entry like: undercloud_public_vip = 172.16.111.2/24 undercloud_admin_vip = 172.16.111.3/24 My "openstack undercloud install" command finishes with errors: WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. ERROR: openstack Could not determine a suitable URL for the plugin + openstack role create ResellerAdmin WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. WARNING: keystoneclient.auth.identity.generic.base Discovering versions from the identity service failed when creating the password plugin. Attempting to determine version from URL. ERROR: openstack Could not determine a suitable URL for the plugin [2015-09-19 19:58:29,620] (os-refresh-config) [ERROR] during post-configure phase. [Command '['dib-run-parts', '/usr/libexec/os-refresh-config/post-configure.d']' returned non-zero exit status 1] [2015-09-19 19:58:29,621] (os-refresh-config) [ERROR] Aborting... Traceback (most recent call last): File "<string>", line 1, in <module> File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 526, in install _run_orc(instack_env) File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 461, in _run_orc _run_live_command(args, instack_env, 'os-refresh-config') File "/usr/lib/python2.7/site-packages/instack_undercloud/undercloud.py", line 297, in _run_live_command raise RuntimeError('%s failed. See log for details.', name) RuntimeError: ('%s failed. See log for details.', 'os-refresh-config') ERROR: openstack Command 'instack-install-undercloud' returned non-zero exit status 1 With some analisys I found this: ++ export OS_AUTH_URL=https://172.16.111.2/24:13000/v2.0 <-- ++ OS_AUTH_URL=https://172.16.111.2/24:13000/v2.0 <-- ++ export OS_CACERT=/etc/pki/instack-certs/undercloud.pem ++ OS_CACERT=/etc/pki/instack-certs/undercloud.pem (...) + REGISTER_SERVICE_OPTS='-p 172.16.111.2/24' <-- ++ hiera controller_public_vip + INIT_KEYSTONE_OPTS='-s 172.16.111.2/24' <-- + init-keystone -o 172.16.111.130 -t 41c06a72854889a65be84f7451dcc78de0772b65 -e admin -p d67ff65de32db8a32514593c701d5976b138baf4 -u root -s 172.16.111.2/24 <-- So the commands take the whole line without parsing the netmask. Did someone else get this? Regards Alessio Dini
/32 VIPs is exactly what you should see. Appending the netmask to the _vip options will break the deployment, as you discovered. Here's what one of my working deployments looks like (with irrelevant bits snipped): [cloud-user@bmu ~]$ ip a [snip] 5: br-ctlplane: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN link/ether fa:16:3e:56:85:22 brd ff:ff:ff:ff:ff:ff inet 9.1.1.1/24 brd 9.1.1.255 scope global br-ctlplane valid_lft forever preferred_lft forever inet 9.1.1.3/32 scope global br-ctlplane valid_lft forever preferred_lft forever inet 9.1.1.2/32 scope global br-ctlplane valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fe56:8522/64 scope link valid_lft forever preferred_lft forever [cloud-user@bmu ~]$ ping 9.1.1.2 PING 9.1.1.2 (9.1.1.2) 56(84) bytes of data. 64 bytes from 9.1.1.2: icmp_seq=1 ttl=64 time=0.053 ms As you can see, the /32 VIP responds as expected.
Ok, now it's a bit clear for me. At this point I think the "Director Installation and Usage Guide" should be updated because it says: (...) undercloud_public_vip The IP address and netmask defined for the director's Public API. Use an IP address on the Provisioning network that does not conflict with any other IP addresses or address ranges. For example, 192.0.2.2/24 . undercloud_admin_vip The IP address and netmask defined for the director's Admin API. Use an IP address on the Provisioning network that does not conflict with any other IP addresses or address ranges. For example, 192.0.2.3/24 . It should not say to use /24, it should says to use both ip without the "/24" prefix. Additionally it could gives some detail about the /32 prefix. Ben thank you for your reply and for your time Regards Alessio Dini
I opened a separate bug to fix the docs: https://bugzilla.redhat.com/show_bug.cgi?id=1265344 and I see the change is already live.
This content is live on the Customer Portal. Closing.