Portal:Cloud VPS/Admin/Bootstrap

From Wikitech
Data (addresses, vlan numbers, etc) may me stale due to network changes, FQDN changes, etc. Double check and understand them as example until this warning is removed

This page contains technical documentation about bootstrapping Openstack for our Cloud VPS infrastructure.

General bootstrap scripts (templates) are located in modules/openstack/templates/bootstrap/ which should be ready to work on jessie/mitaka.

First steps

Before starting, make sure you identify the physical servers in which Openstack will run:

  • control servers
  • networking servers
  • virtualization servers
  • services boxes

You should also identify the database that Openstack will use. This is usually either a production database or local database in control boxes.

keystone

The keystone service runs in control boxes. Follow puppet template script.

nova

The nova service runs mainly in the control boxes. Follow puppet template script.

For virtualization servers, no actual bootstrap is required, apart of setting all the config files.

neutron

The neutron service is by far the most complex element to boostrap. The database creation step is easy. What is rather complex is to populate the database with the right configuration, i.e. create networks, subnets, routers, etc.

Make sure you identify all the network CIDRs, all the network names, the vlan id/names, the physical NIC names, and you have a clear idea of the topology and networking environment/context that you will be using.

  • WAN (transport) network name: cloud-instances-transport1-b-eqiad
  • WAN (transport) network cidr: 10.64.22.0/24
  • WAN (transport) network gw: 10.64.22.1 (core router)
  • WAN (transport) vlan: 1120
  • WAN (transport) openstack net name: wan-transport-eqiad
  • WAN (transport) openstack subnet name: cloud-instances-transport1-b-eqiad

  • floating network name: cloud-eqiad1-floating
  • floating network cidr: 185.15.56.0/25 (start=185.15.56.10,end=185.15.56.30)
  • floating network vlan: no vlan id
  • main NAT addr: 185.15.56.1

  • provider network name: cloud-hosts1-b-eqiad
  • provider network cidr: 10.64.20.0/24
  • provider network vlan: 1118

  • LAN network name: cloud-instances2-b-eqiad
  • LAN network cidr: 172.16.0.0/21 (start=172.16.0.10,end=172.16.7.254)
  • LAN network vlan: 1105
  • LAN openstack net name: lan-flat-cloudinstances2b
  • LAN openstack subnet name: cloud-instances2-b-eqiad

  • main router name: cloudinstances2b-gw
  • main router LAN ip addr (gw): 172.16.0.1
  • main router WAN transport ip addr (gw): 10.64.22.4

  • network nodes: cloudnet1003.eqiad.wmnet, cloudnet1004.eqiad.wmnet


At a later stage, to fix an issue with floating IP allocations by horizon (allocating floating IPs from the wrong subnet), we applied these modification to subnet objects:

root@cloudcontrol1003:~# neutron subnet-update --allocation-pool start=10.64.22.4,end=10.64.22.4 e4fb2771-a361-4add-ac4e-280cc300c59f
root@cloudcontrol1003:~# neutron subnet-update --allocation-pool start=208.80.155.92,end=208.80.155.92 cloud-instances-transport1-b-eqiad1

Also, the compat networking needs this neutron setup:

See also