aboutsummaryrefslogtreecommitdiffstats
path: root/network
AgeCommit message (Collapse)AuthorFilesLines
2015-11-11Expose the IP of the EndpointsMark Chappell1-0/+1
We expose all of the other parameters, so expose the IP too for consistency Change-Id: I5c31befde51e398318c7b8c744310212288ad892
2015-11-11Make CloudName available for EndpointsMark Chappell2-3/+48
CloudName is the DNS name for the public VIP this means we will likely want it available for use in the endpoint hostnames, rather than people needing to copy and paste the same hostname Change-Id: Ic6d708b083244442195eee890de91bbc7e133ec2
2015-11-11Refacter Endpoints into EndpointMapMark Chappell2-0/+429
Because many of the service endpoints URLs use the same patterns for generating the URLs it makes sense to use the same templates to reduce the copy and paste. In the process also adds support for explicitly specifying hostnames for use in the endpoints. Note: DNS must be pre-configured. The Heat templates do not directly configure DNS. Change-Id: Ie3270909beca3d63f2d7e4bcb04c559380ddc54d Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
2015-11-05Add network templates for multiple NIC configurationDan Sneddon6-0/+642
This change adds a set of network interface configurations for use with network isolation. The multiple-nics templates includes one separate NIC per network, and assumes that nic1 is used for the provisioning network (ctlplane). Also included is an environment file for including the multiple-nics configuration in a deployment. This revision changes the ordering of the NICs. By doing that, it is possible to wire up only a subset of the NICs for the storage nodes, and it is possilbe to leave the External NIC only configured on the controllers. rdo: Updated this commit for static control plane configuration Co-Authored-By: Rhys Oxenham <roxenham@redhat.com> Change-Id: Ic878d1ed1a85b5705295d087a743570ca8213504
2015-09-30Add DnsServers param to network config templatesDan Prince10-0/+50
This patch adds a new optional DnsServers parameter which can be used to provide a custom list of DNS resolvers which will be configured in resolv.conf. Change-Id: I2bb7259ebc09d786dc56da18694c862f802091b1 Depends-On: I9edecfdd4e1d0f39883b72be554cd92c5685881d
2015-09-17Configure ctlplane network with a static IPDan Prince10-66/+353
This patch updates all network configuration templates so that we configure the ctlplane network interface with a static IP instead of using DHCP. The IP address used for the static IP is passed into each nested stack network configuration template via the ControlPlaneIp parameter. Three new nested stack parameters called ControlPlaneSubnetCidr, ControlPlaneDefaultRoute, and EC2MetadataIp have been added to help configure the CIDR, default route, and EC2 metadata route on the ctlplane statically. These parameters can be customized via the parameter_defaults section in the heat environment. A single new template called net-config-static-bridge.yaml has been added to help migrate towards using the static configuration templates when not using network isolation. Depends-On: I257e1cba6dee16f73f75512d1284e1e3b9d4c831 Change-Id: Ib267e6dcf2d5ff77f7a82ee20a123965c2d07565
2015-09-08Set NetValueSpecs parameter types to JsonDan Prince5-5/+5
The latest Heat API is a bit more strict in validating the datatypes for the OS::Neutron::Net value_specs. This patch converts the default parameter types for these from string to json. Change-Id: Iaad6ee6417d3ae55c52ffe2f4e6ed79124161923 Closes-bug: #1493502
2015-09-05Allow 'ctlplane' to be used within Net IP MapsDan Prince3-0/+51
When using network isolation you might want to selective move one of the services back to the default ctlplane network by simply using the ServiceNetMap parameter. This patch adds ctlplane to the output parameters for both the net_ip_map and net_ip_list_map nested stacks so that this is possible. As part of this patch we also split out the NetIpSubnetMap into its own unique nested stack so that the Heat input parameters for this stack are more clearly named. Change-Id: Iaa2dcaebeac896404e87ec0c635688b2a59a9e0f
2015-08-17Remove hardcoded bridge name in bonded compute NIC configDan Sneddon1-1/+1
This change removes a hardcoded value for the bond name in the NIC config for the compute node in the bond-with-vlan NIC config templates. When this hardcoded value of "br-bond" is used, then the Neutron bridge mappings must be set to set to datacentre:br-bond in order for VLAN mode networking to recognize the bridge. By using the input value for bridge_name we will ensure that the controller and compute nodes have the same bridge name (defaults to "br-ex"), and that the defaults will work with VLAN mode. Change-Id: I28654ab93e3c10a8597c8b877f3f2f6b3eca887c
2015-07-24Add a default setting for BondInterfaceOvsOptionsDan Sneddon1-1/+2
This change adds a default setting for the OVS bond options to the bond-with-vlans controller.yaml. This default will attempt to bring up LACP bonding, but should that fail it will bring up the bond in active/backup mode. This is a safe configuration if the switch is not configured for bonding. Change-Id: I91aad1e061ed1ecf26636e60da7a9a6e9cde50a5
2015-07-22Convert PublicVirtualIP to new port creation methodDan Sneddon4-6/+35
This change brings PublicVirtualIP in line with the rest of the VIPs in how it is created. This allows the network where PublicVirtualIP is instantiated to be on cltplane when network isolation is not used, and on the external network when network isolation is used. This change removes the PublicVirtualNetwork parameter, since it is no longer used. In order to continue to support the PublicVirtualFixedIPs parameter, which is used to provide a specific IP for the PublicVirtualIP, the FixedIP parameter was added to cltplane_vip.yaml, vip.yaml, and noop.yaml. The value of PublicVirtualIP is passed to FixedIP in the VIP templates. This change also moves the default network for keystone public api to the external net (which will fallback to ctlplane if network isolation isn't used). Change-Id: I3f5d35cbe55d3a148e95cf49dfbaad4874df960b
2015-07-06Merge "Add ControlPlaneNetwork to vip.yaml"Jenkins1-0/+4
2015-06-29Add a default route to the external isolated networkDan Sneddon2-4/+20
This change adds a parameter for ExternalInterfaceDefaultRoute and uses that parameter to set the default route on the controller nodes. This allows Horizon and the public APIs to be reachable from routed networks outside the overcloud. Co-Authored-By: Dan Prince <dprince@redhat.com> Change-Id: I67a72767342237049f53f5085a6faf891fbf0c30
2015-06-27Remove bridge from nic1 in network bond templatesDan Sneddon5-51/+1
The bridge that is built on the bonds in the bond-with-vlans example has an extraneous bridge on the storage and compute templates, and an incorrect bridge on the controller template. There is no reason to do anything on nic1, which is assumed to be the provisioning interface, because it will be configured by DHCP. Also, on the controller template we actually want br-ex to contain the VLAN with the external network, rather than be configured on the provisioning interface. Change-Id: Ibe2343d5281f7b63a7b63b17d96d8442d0b96105
2015-06-27Add ControlPlaneNetwork to vip.yamlDan Sneddon1-0/+4
There are two files in network/ports which control the VIP behavior called ctlplane_vip.yaml and vip.yaml. One of these files was missing ControlPlaneNetwork, since it wasn't used inside the template. Unfortunately, tuskar chokes on this, even though Heat can build the stack just fine. This change makes the vip.yaml and ctlplane_vip.yaml equivalent by adding ControlPlaneNetwork to the vip.yaml template. Change-Id: Ic20281e58a1130afe18d5aec505a3df199841fd5
2015-06-18Merge "Fix grammar nits in bond-with-vlans templates"Jenkins5-5/+5
2015-06-17Merge "Remove Redis VirtualIP from params and build it from Neutron::Port"Jenkins3-0/+95
2015-06-17Merge "Fix allocation pool in external.yaml"Jenkins1-1/+1
2015-06-16Fix allocation pool in external.yamlDan Sneddon1-1/+1
The file network/external.yaml has a typo in the last commit. It should have been a get_param instead of a get_resource. This change fixes that line in that file. Change-Id: Ibc0db0510e9b5dae3c4669a620c642357906cbc2
2015-06-16Configurable vlan_id's for isolated networksDan Prince10-32/+161
This patch adds parameters to configure the various vlan IDs to all of the bond-with-vlans and single-nic-vlans network config templates. Change-Id: Ia6196735927777b73879e8086568f8a435597c6c
2015-06-16Merge "Add BondInterfaceOvsOptions parameter"Jenkins10-10/+30
2015-06-16Merge "network/config storage role fixes"Jenkins6-14/+6
2015-06-13Remove Redis VirtualIP from params and build it from Neutron::PortGiulio Fidente3-0/+95
The redis_vip should come from a Neutron Port as its cidr depends on the Neutron Network configuration. This change adds 2 new files and modifies 1 in the network/ports directory: - noop.yaml - Passes through the ctlplane Controller IP (modified) - ctlplane_vip.yaml - Creates a new VIP on the control plane - vip.yaml - Creates a VIP on the named network (for isolated nets) Also, changes to overcloud-without-mergepy.yaml create the Redis Virtual IP. The standard resource registry was modified to use noop.yaml for the new Redis VIP. The Puppet resource registry was modified to use ctlplane_vip.yaml by default, but can be made to use vip.yaml when network isolation is used by using an environment file. vip.yaml will place the VIP according to the ServiceNetMap, which can also be overridden. We use this new VIP port definition to assign a VIP to Redis, but follow-up patches will assign VIPs to the rest of the services in a similar fashion. Co-Authored-By: Dan Sneddon <dsneddon@redhat.com> Change-Id: I2cb44ea7a057c4064d0e1999702623618ee3390c
2015-06-12Flexible IP allocations for isolated netsDan Prince5-1/+25
This patch adds new '<net name>AllocationPool' parameters to all of the isolated network nested stacks so that users can easily control the allocation ranges on these networks. Change-Id: I44b564831446c62e3489a69d992e0fb1f642b085
2015-06-09Add BondInterfaceOvsOptions parameterDan Prince10-10/+30
This patch adds a new BondInterfaceOvsOptions to the bond-with-vlans network config templates. This can be used to configure things like LACP or the bonding mode via a nested stack heat parameter. The patch also removes the hard coded ovs_options relating to both bond-with-vlans and single-nic-with-vlans configurations which do not actually require this setting to be hard coded because by default OVS trunks vlan ports automatically. Change-Id: I3effbccba8ed7ed28d6ba715e5709275d4e7f984
2015-06-09network/config storage role fixesDan Prince6-14/+6
None of the storage roles have Heat parameters for the bridge name. Instead of wiring in Heat parameters for bridge name this patch hard codes the bridge name for the storage roles to 'br-storage'. This functionally fixes the network config scripts for each of the storage roles. For the single-nic-vlans storage roles we also remove the 'bond1' reference which was also incorrectly specified. Change-Id: I460d1a17e44ee49e960117ec85edd3ae25894333
2015-06-04Merge "Add PortName to ports stacks"Jenkins6-0/+29
2015-06-04Merge "Make all-nodes Ip networks configurable"Jenkins2-1/+31
2015-06-03Add PortName to ports stacksDan Prince6-0/+29
For VIP ports we set an explicit name on the ports. This patch adds an optional PortName parameter to the ports objects which can be used to specify a name. Change-Id: Iad0f5e4cfc31a931dbb574d9e589570125e9465c
2015-06-03Make all-nodes Ip networks configurableDan Prince2-1/+31
This patch adds a new NetIpListMap abstraction which we can use to make the all-nodes-config IP list network assignments configurable. Ip address lists for all overcloud services which require IPs were added to all-nodes-config so that puppet manifests can be directly supplied the correct network list for each service. Change-Id: I209f2b4f97a4bb78648c54813dad8615770bcf1a
2015-06-01os-net-config templates to configure vlansDan Prince6-0/+383
This patch adds 5 new role templates to help configure a vlans on top for each of the overcloud roles. This patch adds vlans on top of a single NIC attached to the control plane network (already used for provisioning). The patch also includes an environment file to enable configuration of vlans by simply sourcing this file. Change-Id: Ibc40e452dec9b372ff10442aab2bddaf382b0a2f
2015-05-26Fix grammar nits in bond-with-vlans templatesBen Nemec5-5/+5
Change-Id: Ifa59cf2f1f6b16bc785b19aef215659b95876237
2015-05-26os-net-config templates to configure vlans on bondDan Prince6-0/+462
This patch adds 5 new role templates to help configure an OVS bond with vlans on top for each of the overcloud roles. These are meant to represent a more production network which might use isolated nets, and should help facilitate create a CI job which configures a bond w/ vlans on it. The patch also includes an environment file to enable configuration of bonded vlans by simply sourcing this file. Change-Id: Ibe4c9d933445014ce3bec5fb3d7e3139fc40cb32
2015-05-26Add a network ports IP mapping resourceDan Prince1-0/+30
This patch adds a resource which constructs a Json output parameter called net_ip_map which will allow us to easily extract arbitrary IP addresses for each network using the get_attr function in heat. The goal is to use this data construct in each role template to obtain the correct IP address on each network. Change-Id: I1a8c382651f8096f606ad38f78bbd76314fbae5f
2015-05-26Add a ports (ip address) abstraction layerDan Prince6-0/+207
This patch adds a set of templates to create ports on isolated networks via Heat. There are 5 port templates in total which are split out according to the available overcloud networks. Change-Id: I5175ef48c1960ea0d13fc8518328db53921c70cd
2015-05-20Overcloud: bump HOT version to 2015-04-30Dan Prince7-7/+7
This patch bumps the HOT version for the overcloud to Kilo 2015-04-30. We should have already done this since we are making use of OS::stack_id (a kilo feature) in some of the nested stacks. Also, this will give us access to the new repeat function as well. Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4
2015-05-06Create split out neutron networks via Heat.Dan Prince7-0/+309
This patch adds a new abstraction for network creation within Heat. This (optional) set of templates may be disabled if you wish to create Neutron networks for the undercloud via Heat templates... instead of using os-cloud-config JSON to do so. Creating networks with Heat has the benefit of being parameter driven so that users can quickly enable networks using the resource registry and parameters. There are 5 networks to start with which are roughly modeled around networks an Overcloud user might want to use to isolate their traffic. The intent is to make these opt-in and configurable for end users. The networks.yaml template can be used to create all of the networks using parameters in the resource registry. Change-Id: I5f2b3356378eb263d90d428cc83c7f5b141957e1