Bug 1465017 - [RFE]Documentation Shortcomings: Network Setup for Dual NIC Configuration [NEEDINFO]
[RFE]Documentation Shortcomings: Network Setup for Dual NIC Configuration
Status: NEW
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
10.0 (Newton)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dan Macpherson
RHOS Documentation Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-26 08:38 EDT by Ganesh Kadam
Modified: 2017-08-03 22:10 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dmacpher: needinfo? (gkadam)


Attachments (Terms of Use)

  None (edit)
Description Ganesh Kadam 2017-06-26 08:38:18 EDT
Description of problem:

Cu wants to deploy the RHOSP 10, while they were referring to the intro of "Chapter 5. Configuring Basic Overcloud Requirements with the CLI Tools" 
of "Director Installation and Usage", they expect directions sufficient to get a setup with basic customization (like configuration of networks as even the Single NIC configuration uses VLANs) and some words about those templates one is supposed to include. 


Also, under "Including an Environment File Directory" there's a "00-node-info.yaml" suggesting there's some node-specific data (maybe assignment of IPs to nodes?) to enter but there's no further mention of this file in the document.


As per Cu. Networking Guide's intro doesn't mention any initial configuration:

~~~
"1.1. Topics covered in this book
* Preface - Describes the political landscape of SDN in large organizations, and offers a short introduction to general networking concepts. 
* Part 1 - Covers common administrative tasks and basic troubleshooting steps: [...]
* Part 2 - Contains cookbook-style scenarios for advanced OpenStack Networking features, including: [...]"
~~~




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

RHOSP 10 Networking Guide


Actual results:


No directions sufficient to get a setup with basic customizations

Expected results:

Directions to get a setup with basic customizations, some words about those templates, add node-specific data.
Comment 1 Dan Macpherson 2017-06-26 12:02:53 EDT
Hi Ganesh,

Answers inline...

> Description of problem:
> 
> Cu wants to deploy the RHOSP 10, while they were referring to the intro of
> "Chapter 5. Configuring Basic Overcloud Requirements with the CLI Tools" 
> of "Director Installation and Usage", they expect directions sufficient to
> get a setup with basic customization (like configuration of networks as even
> the Single NIC configuration uses VLANs) and some words about those
> templates one is supposed to include. 
> 

There is a section [1] in the Director Guide that links to the the Advanced Overcloud Customizations guide [2]. This guide contains various advanced features, such as network isolation [3]. The intention of the director guide is to only deploy a basic overcloud with no additional features, which you add on with environment file configuration from the Advanced Overcloud Guide.

> Also, under "Including an Environment File Directory" there's a
> "00-node-info.yaml" suggesting there's some node-specific data (maybe
> assignment of IPs to nodes?) to enter but there's no further mention of this
> file in the document.

So this is just an example of a filenaming convention to show how environment files are interpreted. There is a similar file (node-info.yaml) mentioned in the previous section [4]

Did you have any further questions or suggestions on these items?



[1] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installation_and_usage/chap-configuring_basic_overcloud_requirements_with_the_cli_tools#sect-Customizing_the_Overcloud

[2] https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/paged/advanced-overcloud-customization/

[3] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/advanced_overcloud_customization/sect-isolating_networks(In reply to Ganesh Kadam from comment #0)

[4] https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/director_installation_and_usage/chap-configuring_basic_overcloud_requirements_with_the_cli_tools#sect-Including_Environment_Files_in_Overcloud_Creation
Comment 2 Ganesh Kadam 2017-06-28 01:10:04 EDT
Hi Dan,
 


(In reply to Dan Macpherson from comment #1)
> Hi Ganesh,
> 
> Answers inline...
> 
> > Description of problem:
> > 
> > Cu wants to deploy the RHOSP 10, while they were referring to the intro of
> > "Chapter 5. Configuring Basic Overcloud Requirements with the CLI Tools" 
> > of "Director Installation and Usage", they expect directions sufficient to
> > get a setup with basic customization (like configuration of networks as even
> > the Single NIC configuration uses VLANs) and some words about those
> > templates one is supposed to include. 
> > 
> 
> There is a section [1] in the Director Guide that links to the the Advanced
> Overcloud Customizations guide [2]. This guide contains various advanced
> features, such as network isolation [3]. The intention of the director guide
> is to only deploy a basic overcloud with no additional features, which you
> add on with environment file configuration from the Advanced Overcloud Guide.
> 
> > Also, under "Including an Environment File Directory" there's a
> > "00-node-info.yaml" suggesting there's some node-specific data (maybe
> > assignment of IPs to nodes?) to enter but there's no further mention of this
> > file in the document.
> 
> So this is just an example of a filenaming convention to show how
> environment files are interpreted. There is a similar file (node-info.yaml)
> mentioned in the previous section [4]
> 
> Did you have any further questions or suggestions on these items?
> 
> 
> 
> [1]
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/
> html/director_installation_and_usage/chap-
> configuring_basic_overcloud_requirements_with_the_cli_tools#sect-
> Customizing_the_Overcloud
> 
> [2]
> https://access.redhat.com/documentation/en/red-hat-openstack-platform/10/
> paged/advanced-overcloud-customization/
> 
> [3]
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/
> html/advanced_overcloud_customization/sect-isolating_networks(In reply to
> Ganesh Kadam from comment #0)
> 
> [4]
> https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/
> html/director_installation_and_usage/chap-
> configuring_basic_overcloud_requirements_with_the_cli_tools#sect-
> Including_Environment_Files_in_Overcloud_Creation



Thanks for the update. I have shared above information with Cu. 

However, they are expecting below as well:
 
~~~
There's also no mention about how one is supposed to assign the services' Virtual IPs (vip-msg, vip-keystone-int, ..., mentioned in 
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/networking_guide/#isolating_vlan_traffic)

I'd guess one is supposed to populate NetVipMap (evaluated in /usr/share/openstack-tripleo-heat-templates/puppet/all-nodes-config.yaml,
from the package openstack-tripleo-heat-templates-5.2.0-15.el7ost.noarch ) for this purpose but it's not clear if those are necessary in a 
non-HA setup.
~~~

Is possible to address above issue?


Regards,
Ganesh
Comment 4 Dan Macpherson 2017-07-06 08:44:43 EDT
Hi Ganesh,

Sorry about the delay. I've been doing some benchmark testing.

So assigning VIP to services requires the following:

- Isolate your network - This involves splitting your network into the following networks: internal_api, tenant, storage, storage_mgmt, external. Instruction are found in this chapter:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html/advanced_overcloud_customization/sect-isolating_networks

- Assign your services to each network - This involves setting the ServiceNetMap parameter and defining a full list of service to isolated networks. The default ServiceNetMap is located in network/service_net_map.j2.yaml but you can set ServiceNetMap to your own list in a separate environment file. Full instructions in this section:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html/advanced_overcloud_customization/sect-isolating_networks#sect-Assigning_OpenStack_Services_to_Isolated_Networks

- Set Predictable VIPs for your networks - This is just a matter of using the respective parameter for each network. For example, InternalApiVirtualFixedIPs sets the VIP for the internal_api network. Syntax for setting these parameters is here:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/11/html/advanced_overcloud_customization/sect-controlling_node_placement#sect-Predictable_VIPs

What will happen is this: The network isolation feature will configure the NICs on each node (and in most cases, you'll create a bridge with a NIC and VLANs attached). The ServiceNetMap configures the internal load balancer (HAProxy) to receive data from the VIP of each service and send it to the node that contains the service (or if the service exists on more than one node, it'll load balance and pick one). The predictable VIP feature ensures you define your own VIPs on each network so that you don't have to look them up after deployment.

For example, by default, HorizonNetwork is mapped to internal_api in ServiceNetMap. The Horizon composable service takes the mapping from ServiceNetMap and applies the whichever internal_api IP was assigned to the node to the horizon::bind_address Puppet hieradata. HAProxy then maps the internal_api VIP to this node. So when you deploy, Horizon is accessible on port 80 of the internal API VIP. In addition, HAProxy also maps this port for access on the external VIP (set with PublicVirtualFixedIPs) so that you can access the Horizon web UI from outside of your OpenStack environment. 

This should work in both HA and non-HA environments. HAProxy is installed by default to act as a traffic director for all the network data. Having a HA environment means that Pacemaker has multiple instances of HAProxy available in case one goes down.

Let me know if you or Cu had any further questions on this.

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