Bug 1251271 - [Docs] [Director] undercloud.conf doc missing netmask on undercloud_*_vip property
[Docs] [Director] undercloud.conf doc missing netmask on undercloud_*_vip pro...
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
medium Severity medium
: z1
: 7.0 (Kilo)
Assigned To: Dan Macpherson
: Documentation, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-06 17:03 EDT by Brian Demers
Modified: 2016-01-11 05:11 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-11 05:11:14 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Brian Demers 2015-08-06 17:03:21 EDT
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
Comment 3 Andrew Dahms 2015-08-06 22:10:24 EDT
Assigning to Dan for review.
Comment 4 Dan Macpherson 2015-08-10 00:19:24 EDT
Hi Brian,

Implementing this fix and will be published early this week.

- Dan
Comment 6 Dan Macpherson 2015-08-10 11:20:54 EDT
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.
Comment 7 rlopez 2015-08-24 17:41:41 EDT
(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
Comment 8 rlopez 2015-08-24 18:55:52 EDT
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
Comment 9 Ben Nemec 2015-08-28 17:56:34 EDT
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.
Comment 10 Alessio 2015-09-19 14:36:01 EDT
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@example.com -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
Comment 11 Ben Nemec 2015-09-22 13:29:20 EDT
/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.
Comment 12 Alessio 2015-09-23 10:52:55 EDT
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
Comment 14 Ben Nemec 2015-09-25 11:00:27 EDT
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.
Comment 15 Andrew Dahms 2016-01-11 05:11:14 EST
This content is live on the Customer Portal.

Closing.

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