Bug 1465017

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

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

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.

Dan's answer is very complete and references the existing documentation. As here has been no more requests from the reporter, closing this out.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days