Bug 1313351 - [Docs][Director] Replace openstack overcloud deploy networking related arguments with environment files
Summary: [Docs][Director] Replace openstack overcloud deploy networking related argume...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 8.0 (Liberty)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ga
: 8.0 (Liberty)
Assignee: RHOS Documentation Team
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-03-01 12:45 UTC by Marius Cornea
Modified: 2018-03-14 01:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-14 01:07:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Marius Cornea 2016-03-01 12:45:07 UTC
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.