Bug 1474690 - [Doc] Suggestion for improving upgrade doc OSP11
Summary: [Doc] Suggestion for improving upgrade doc OSP11
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Documentation Team
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-25 07:25 UTC by Chaitanya Shastri
Modified: 2017-07-26 00:27 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-07-26 00:27:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Chaitanya Shastri 2017-07-25 07:25:53 UTC
Description of problem:
Under the section 3.4.1- Upgrading the Director 4th point, we have an 'Important' section which states that the default provisioning / control plane has changed from 192.0.2.0/24 to 192.168.24.0/24: https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html-single/upgrading_red_hat_openstack_platform/#sect-Major-Updating_Director_Packages

It states to check certain parameters in undercloud.conf file like local_ip, network_gateway etc. and in the end its asks the users to make sure that the undercloud.conf file is proper before running the undercloud upgrade.

This section is confusing and it does not clearly mention what needs to be done if default provisioning plane is configured: Do we have to change it to 192.168.24.0/24 in the undercloud.conf file and run the upgrade / keep the undercloud.conf file as it is.

The solution to this is known when we go through the install-undercloud.log file     for OSP10 which states the following:

~~~
WARNING: 
*****************************************************************************
The old default CIDR of 192.0.2.0/24 is deprecated due to it being an
unroutable address range under RFC 5737.  This default will change in the
Ocata release of OpenStack, so you should stop using the default CIDR and set
a valid, routable CIDR instead.

Note that if you have already deployed an overcloud with the 192.0.2.0/24
CIDR, it will not be possible to change it without re-deploying.  If the
overcloud cannot be re-deployed, you must explicitly set the network values
in undercloud.conf to ensure continued use of the 192.0.2.0/24 CIDR during
future upgrades.
*****************************************************************************
~~~

Solution: Explicitly set the network values in undercloud.conf to ensure continued use of the 192.0.2.0/24 CIDR during future upgrades.

I think it would be great if we can include some of this text to the undercloud upgrade documentation to avoid confusion. 

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

Comment 1 Dan Macpherson 2017-07-25 13:23:28 UTC
Hi Chaitanya,

I've revised the text in the section your specified:

"The default Provisioning/Control Plane network has changed from 192.0.2.0/24 to 192.168.24.0/24. If you used default network values in your previous undercloud.conf file, your Provisioning/Control Plane network is set to 192.0.2.0/24. This means you need to set certain parameters in your undercloud.conf file to continue using the 192.0.2.0/24 network. These parameters are:

etc, etc, etc"

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html/upgrading_red_hat_openstack_platform/chap-director-major-upgrade#sect-Major-Updating_Director_Packages

How does that read now? Does it clarify what the user needs to do?

Comment 2 Chaitanya Shastri 2017-07-25 13:40:18 UTC
Hi Dan,

  Thanks for the revision.

Can you include the following text in the end(or something like):

~~~
you must explicitly set the network values in undercloud.conf to ensure continued use of the 192.0.2.0/24 CIDR during future upgrades.
~~~

That would be more clear to understand.

Comment 4 Chaitanya Shastri 2017-07-25 15:24:08 UTC
Hi Dan,

 That looks perfect now.

Thanks!

Comment 5 Dan Macpherson 2017-07-26 00:27:09 UTC
No prob. Thanks for highlighting this.


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