Bug 1313351 - [Docs][Director] Replace openstack overcloud deploy networking related arguments with environment files
[Docs][Director] Replace openstack overcloud deploy networking related argume...
Status: CLOSED CURRENTRELEASE
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
8.0 (Liberty)
Unspecified Unspecified
unspecified Severity high
: ga
: 8.0 (Liberty)
Assigned To: RHOS Documentation Team
RHOS Documentation Team
: Documentation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-01 07:45 EST by Marius Cornea
Modified: 2018-03-13 21:07 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-03-13 21:07:08 EDT
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 Marius Cornea 2016-03-01 07:45:07 EST
Description of problem:
In OSP8 'openstack help overcloud deploy' shows all or most networking related arguments as DEPRECATED. The current recommended way is to pass them as parameters in environment files. 

We should get the docs updated to exemplify such deployment commands. 

Below is an example network-environment.yaml that contains some of the networking options as parameters:

resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig: /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  InternalApiNetCidr: 172.16.20.0/24
  InternalApiAllocationPools: [{'start': '172.16.20.10', 'end': '172.16.20.100'}]
  InternalApiNetworkVlanID: 200

  StorageNetCidr: 172.16.21.0/24
  StorageAllocationPools: [{'start': '172.16.21.10', 'end': '172.16.21.100'}]
  StorageNetworkVlanID: 300

  StorageMgmtNetCidr: 172.16.19.0/24
  StorageMgmtAllocationPools: [{'start': '172.16.19.10', 'end': '172.16.19.100'}]
  StorageMgmtNetworkVlanID: 301

  TenantNetCidr: 172.16.22.0/24
  TenantAllocationPools: [{'start': '172.16.22.10', 'end': '172.16.22.100'}]

  ExternalNetCidr: 172.16.23.0/24
  ExternalAllocationPools: [{'start': '172.16.23.10', 'end': '172.16.23.100'}]
  ExternalInterfaceDefaultRoute: 172.16.23.251
  ExternalNetworkVlanID: 100

  ControlPlaneSubnetCidr: "24"
  ControlPlaneDefaultRoute: 192.0.2.1

  EC2MetadataIp: 192.0.2.1
  DnsServers: ["10.16.36.29","10.11.5.19"]  

  NeutronExternalNetworkBridge: "''"
  NeutronBridgeMappings: 'datacentre:br-ex,tenantvlan:br-infra'
  NeutronEnableIsolatedMetadata: 'True'
  NeutronNetworkType: 'gre,vxlan,vlan,flat'
  NeutronTunnelTypes: 'gre,vxlan' 
  NeutronNetworkVLANRanges: 'datacentre:1000:1100'

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