Bug 1306350 - With RDO-manager, if not configured, the first nic on compute nodes gets addresses from dhcp as a default
With RDO-manager, if not configured, the first nic on compute nodes gets addr...
Product: RDO
Classification: Community
Component: rdo-manager (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: trunk
Assigned To: Hugh Brock
Shai Revivo
Depends On:
  Show dependency treegraph
Reported: 2016-02-10 11:09 EST by Raoul Scarazzini
Modified: 2017-06-18 02:34 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-06-18 02:34:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Raoul Scarazzini 2016-02-10 11:09:29 EST
Description of problem:

Deploying Mitaka with rdo-manager does not complete successfully if you don't want to use the first nic until you explicit this in the compute.yaml nic configs:

  type: interface
  name: nic1
  use_dhcp: false

Without this even if you have something like this in compute.yaml (That means that everything goes on the second nic):

              type: ovs_bridge
              name: {get_input: bridge_name}
              use_dhcp: false
              dns_servers: {get_param: DnsServers}
                      - '/'
                      - - {get_param: ControlPlaneIp}
                        - {get_param: ControlPlaneSubnetCidr}
                  next_hop: {get_param: EC2MetadataIp}
                  default: true
                  next_hop: {get_param: ControlPlaneDefaultRoute}
                  type: interface
                  name: nic2
                  # force the MAC address of the bridge to this interface
                  primary: true
                  type: vlan

Overcloud deploy will fail. This does not happen in RDO/Liberty.

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

CentOS Linux release 7.2.1511 (Core)

How reproducible:

Configure a network-isolation setup for an overcloud environment in which the first network card is not used for internal communication and try to deploy the overcloud.

Actual results:

Overcloud deploy fails on the compute validation.

Expected results:

Compute validation should succeed.

Additional info:

The network isolation setup that was used in this deployment is explained here https://github.com/rscarazz/openstack/blob/master/ospd-network-isolation-considerations.md
Comment 2 Christopher Brown 2017-06-17 12:52:35 EDT
This has been fixed for a while so can be closed.

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