aboutsummaryrefslogtreecommitdiffstats
path: root/network/ports
AgeCommit message (Collapse)AuthorFilesLines
2017-10-07Fixes missing type for heat param TenantNetNameTim Rozet1-24/+0
Closes-Bug: 1720823 Change-Id: I239cc9f827fe99a553f9c18b80336bc6ce0b1d14 Signed-off-by: Tim Rozet <trozet@redhat.com> (cherry picked from commit ba5436099d37898e418406f8b4376923e14f4c89)
2017-08-21Render port templates via j2Steven Hardy29-1372/+91
Remove these from the j2 excludes and instead render all the networks to avoid duplication. Change-Id: Id8e14e06ffe959c50456b4c88fef306046a8b478 Partially-Implements: blueprint composable-networks
2017-08-17Merge "Render IP map and host maps according to network_data.yaml"Jenkins3-238/+95
2017-08-16Merge "Render VIPs dynamically based on network_data.yaml"Jenkins4-156/+85
2017-08-16Render IP map and host maps according to network_data.yamlDan Sneddon3-238/+95
This change renders the network IP maps and hostname maps for all networks defined in network_data.yaml. This should make it possible to create custom networks that will be rendered for all applicable roles. Note that at this time all networks will be rendered whether they are enabled or not. All networks will be present in all roles, but ports will be associated with noop.yaml in roles that do not use the network. This is in accordance with previous behavior, although we may wish to change this in the future to limit the size of the role definitions and reduce the number of placeholder resources in deployments with many networks. Note that this patch is a replacement for original patch https://review.openstack.org/#/c/486280, which I was having trouble rebasing to current. Change-Id: I445b008fc1240af57c2b76a5dbb6c751a05b7a2a Depends-on: I662e8d0b3737c7807d18c8917bfce1e25baa3d8a Partially-implements: blueprint composable-networks
2017-08-15Convert network templates to be rendered via j2Steven Hardy10-16/+16
Use the network.network.j2.yaml to render these files, instead of relying on the hard-coded versions. Note this doesn't currently consider the _v6 templates as we may want to deprecate these and instead rely on an ipv6 specific network_data file, or perhaps make the network/network.network.j2.yaml generic and able to detect the version from the cidr? Change-Id: I662e8d0b3737c7807d18c8917bfce1e25baa3d8a Partially-Implements: blueprint composable-networks
2017-08-04Render VIPs dynamically based on network_data.yamlDan Sneddon4-156/+85
This change modifies the templates to dynamically define the VIPs based on network_data.yaml. If a network is defined and marked with "vip: true" in network_data.yaml, it will be included in the overcloud.yaml which defines the deployment-level resources. This should make it possible to create custom networks and use them for services which use high-availability through VIPs. Also, extraconfig/nova_metadata/krb-service-pricipals.yaml was modified to dynamically produce the FQDN map for VIPs on isolated networks, to match overcloud.j2.yaml. Depends-On: If074f87494a46305c990a0ea332c7b576d3c6ed8 Depends-On: Iab8aca2f1fcaba0c8f109717a4b3068f629c9aab Partially-implements: blueprint composable-networks Closes-bug: 1667104 Change-Id: I71339a6ac41133e95dbc3f93abb7a9fdeb0f2da0
2017-08-03Merge "Make many networking parameters consistent"Jenkins31-35/+50
2017-08-02Make many networking parameters consistentBen Nemec31-35/+50
These are mostly the low hanging fruit that only required a few minor changes to fix. There are more that require a lot of changes or might be more controversial that will be done later. Change-Id: I55cebc92ef37a3bb167f5fae0debe77339395e62 Partial-Bug: 1700664
2017-07-26Render isolated network templates using jinja2Dan Sneddon2-0/+137
This change adds templates that are used to create network and port definition templates for each network that is defined in network_data.yaml. In order to render the templates, additional fields have been added to the network_data.yaml file. If this optional data is present, it will be used to populate the default parameter values in the network template. The only required parameters in the network_data.yaml file is the network name. If the network will have IPv6 addresses, then ipv6: true must be set on the network. The existing networks have been modeled in the network_data.yaml, but until these templates are removed from the j2_excludes.yaml file they will not be generated on the fly. Any additional networks will have templates generated. This change also removes an unnecessary conditional from the networks.j2.yaml file, since InternalApiNetwork doesn't need to be reformatted as InternalNetwork (it's only used in this one file). A follow-up patch will remove the existing network definitions so all networks are created dynamically. Change-Id: If074f87494a46305c990a0ea332c7b576d3c6ed8 Depends-On: Iab8aca2f1fcaba0c8f109717a4b3068f629c9aab Partially-Implements: blueprint composable-networks
2017-06-28Make CephValidationDelay/Retries default consistentBen Nemec1-0/+1
Also fix one instance of ManagementIpSubnet that was missing a description. Change-Id: I7c5b31d9ef464cefee1dd6ae7ebb9c017cbbd894 Partial-Bug: 1700664
2017-06-27Merge "Provides a list of per-service ctlplane IPs to the workflows env"Jenkins1-0/+14
2017-06-26Provides a list of per-service ctlplane IPs to the workflows envGiulio Fidente1-0/+14
Adds in the execution environment of the workflow steps a list of per-service network IPs. This can be used by the workflows to execute actions against the nodes hosting a given service. Change-Id: Id7c735d53f04f6ad848b2f9f1adaa3c84ecd2fcd Implements: blueprint tripleo-ceph-ansible
2017-06-15Add split-stack environmentsJames Slagle1-1/+1
Add 2 new environments to faciltate deploying split-stack: environments/overcloud-baremetal.j2.yaml environments/overcloud-services.j2.yaml The environments are used to deploy 2 separate Heat stacks, one for just the baremetal+network configuration and one for the service configuration. In order to keep Heat's view of the server's hostname consistent across the 2 stacks the 2 environments set the same HostnameFormat with "overcloud" as the stack name. implements blueprint split-stack-default Change-Id: I0b3f282c08af6fecea8f136908b806db70bada46
2017-05-19Update the template_version alias for all the templates to pike.Carlos Camacho34-34/+34
Master is now the development branch for pike changing the release alias name. Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
2017-02-17Don't assume default network names in net_ip*mapSteven Hardy2-43/+177
This needs to handle a ServiceNetMap containing non-default network names when they are overridden via the *NetName parameters. Closes-Bug: #1651541 Change-Id: I95d808444642a37612a495e822e50449a7e7da63
2016-12-23Bump template version for all templates to "ocata"Steven Hardy34-34/+34
Heat now supports release name aliases, so we can replace the inconsistent mix of date related versions with one consistent version that aligns with the supported version of heat for this t-h-t branch. This should also help new users who sometimes copy/paste old templates and discover intrinsic functions in the t-h-t docs don't work because their template version is too old. Change-Id: Ib415e7290fea27447460baa280291492df197e54
2016-12-21Add a per service bootstrap node variableMichele Baldessari1-0/+17
In order to call commands that need to be run on a single node, we create a new per-service variable that will contain the first node of each role containing the service. Change-Id: I03e8685f939e8ae1fcd8b16883b559615042505d Partial-Bug: #1615983
2016-10-05Select per-network hostnames for service_node_namesSteven Hardy1-1/+26
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com> Depends-On: Ic6fec1057439ed9122d44ef294be890d3ff8a8ee Change-Id: I754c4a41d8a294a4c7c18bd282ae014efd4b9b16 Closes-Bug: #1628521
2016-09-30Make keystone api network hiera composableSteven Hardy1-2/+25
These hard-coded references to the Controller role mean that things won't work if the keystone service is moved to any other role, so we need to generate the lists dynamically based on the enabled services for each role. Change-Id: I5f1250a8a1a38cb3909feeb7d4c1000fd0fabd14 Closes-Bug: #1629096
2016-09-23Add FixedIPs parameter to from_service.yamlBen Nemec2-0/+12
Without this, deployments using the from_service.yaml port for service VIPs will fail with: "Property error: : resources.RedisVirtualIP.properties: : Unknown Property FixedIPs" Change-Id: Ie0d3b940a87741c56fe022c9e50da0d3ae9b583b Closes-Bug: 1627189
2016-09-16Fix _from_pool_v6.yaml str_splitGiulio Fidente6-6/+6
Previously [1] we updated from_pool_v6 to use str_split but mistakenly copy/pasting lines referencing an attribute which isn't created in these templates. 1. I282dbc025500b1628d4f08a49b54a2adefd38b5f Closes-Bug: 1624412 Change-Id: I409ff5b36eab2a791db4d352dea5b68096c2dc21
2016-09-03Create NetIpListMap for all rolesSteven Hardy1-6/+12
This allows us to create $service_node_ips and $service_node_names hiera entries for services not deployed on the Controller role. Co-Authored-By: Thomas Herve <therve@redhat.com> Change-Id: I688618dda05ff908293c32b9d8518697d57e9eb0 Partially-Implements: blueprint custom-roles
2016-09-02Generate composable service node_names listsSteven Hardy1-0/+13
Some puppet interfaces require a comma separated list of hostnames where a service is running, so generate it in a similar way to th service ips. Change-Id: Icdf5d993d089dc94035194bdbd52299fcbc793be Partially-Implements: blueprint custom-roles
2016-08-28Create composable mapping between enabled services and role ipsSteven Hardy1-1/+36
Currently we have a hard-coded list of ips for various services that run on the controller, instead we can dynamically generate that list of per-service ips, initially only for the controller but this approach can be extended so it works for any role. Change-Id: I3c8a946e439539d239ad7281a1395414df0893eb Partially-Implements: blueprint custom-roles
2016-08-16Remove deprecated net_ip_uri_map outputGiulio Fidente3-45/+10
Takes the net_ip_uri_map value from the *_uri values emitted by net_ip_map instead. Also removes TenantIp and TenantIpUri from net_vip_map_external templates as there won't be any VIP on the tenant network. Change-Id: Icdac3d58162891f5ca3d5c20f14fcdff1781996f
2016-08-16Remove deprecated net_ip_subnet_map outputGiulio Fidente1-18/+0
Change-Id: I83ca923140d7f8ca3101e851e88ca3107a99555a
2016-08-09Allow map_replace substitution of network namesSteven Hardy1-0/+21
To allow per-node data such as bind_ip's to move into the composable services templates, we do a value substitution on the config settings hiera map, where e.g internal_api will be replaced with the NetIpMap IP assigned to that. To enable subnet/uri lookup via the same method, we add all the subnet/uri mappings to the main net_ip_map output. Change-Id: I7850d4dc8bf4db5f7ac6a6b53c1d900b561b4580
2016-06-20Add IPv6 support for the management networkMarius Cornea1-0/+52
This change introduces the ability to use IPv6 addressing for the management network by passing the network-management-v6.yaml environment file. It also adjusts the network-management.yaml environment file to point to the right network config templates. Change-Id: I7f797c49f03b2623a08e033bdf45772edff0f08f
2016-05-24Merge "Dump IPs configuration as hieradata"Jenkins2-48/+40
2016-05-23Update management_from_pool template version to 2015-10-15Giulio Fidente1-1/+1
The str_split function was added after the 2015-04-30 release so it wasn't working as intended. Change-Id: Ib8827879182e6ea3bd2227b0cfa77f70aabb0ac6 Closes-Bug: 1575622
2016-05-18Dump IPs configuration as hieradataGiulio Fidente2-48/+40
This might be useful if we switch to %{hiera()} calls to lookup the bind address from within a service. Also gets rid of NetIpSubnetMap and provides same output from NetIpMap instead. Change-Id: I328a417d1f1fff9c31e9ad7b2b5083ac19bc7329
2016-04-29Use str_split to compute netmask in _v6 port templatesGiulio Fidente11-44/+22
Change-Id: I282dbc025500b1628d4f08a49b54a2adefd38b5f
2016-03-15Merge "Fix typos"Jenkins6-9/+9
2016-03-09Make External Load Balancer templates work with IPv6Dan Sneddon7-0/+406
This change modifies the network isolation templates that allow for fixed IP addresses on the controllers' IPs and VIPs, and makes them compatible with IPv6 addresses. The latest version of the patchset creates an from_service_v6.yaml in order to properly handle service VIPs on IPv6 networks. Note that since OVS is not currently compatible with IPv6 tunnel endpoints, this patch does not yet enable IPv6 for the Tenant network by default. Change-Id: If881b000c6000ec13b54c0ee39f1c8940f079ae3 Co-Authored-By: Giulio Fidente <gfidente@redhat.com>
2016-03-08Fix typosSwapnil Kulkarni (coolsvap)6-9/+9
Multiple files in t-h-t were having small typos. Fixed in this patchset. . Change-Id: I82d7071747f47544990ed46e2be22931190406b3
2016-03-04Add IPv6 Support to Isolated NetworksDan Sneddon25-0/+550
This change adds a new set of network templates with IPv6 subnets that can be used instead of the existing IPv4 networks. Each network can use either the IPv4 or IPv6 template, and the Neutron subnet will be created with the specified IP version. The default addresses used for the IPv6 networks use the fd00::/8 prefix for the internal isolated networks (this range is reserved for private use similar to 10.0.0.0/8), and 2001:db8:fd00:1000::/64 is used as an example default for the External network (2001:db8::/32 are the documentation addresses [RFC3849]), but this would ordinarily be a globally addressable subnet. These parameters may be overridden in an environment file. This change will require updates to the OpenStack Puppet Modules to support IPv6 addresses in some of the hieradata values. Many of the OPM modules already have IPv6 support to support IPv6 deployments in Packstack, but some OPM packages that apply only to Instack/TripleO deployments need to be updated. IPv6 addresses used in URLs need to be surrounded by brackets in order to differentiate IP address from port number. This change adds a new output to the network/ports resources for ip_address_uri, which is an IP address with brackets in the case of IPv6, and a raw IP address without brackets for IPv4 ports. This change also updates some URLs which are constructed in Heat. This has been tested and problems were found with Puppet not accepting IPv6 addresses. This is addressed in the latest Puppet. Additional changes were required to make this work with Ceph. IPv6 tunnel endpoints with Open vSwitch are not yet supported (although support is coming soon), so this review leaves the Tenant network as an isolated IPv4 network for the time being. Change-Id: Ie7a742bdf1db533edda2998a53d28528f80ef8e2
2016-03-04Allow for usage of pre-allocated IPs for the management networkSteven Hardy2-0/+49
Id3d4f12235501ae77200430a2dc022f378dce336 added support for pre-allocated IPs on the other overlay networks, but because the patch adding the managment network (I0813a13f60a4f797be04b34258a2cffa9ea7e84f) was under review around the same time, we missed adding the from_pool capability to the ManagementNetwork. Change-Id: If99f37634d5da7e7fb7cfc31232e926bd5ff074a
2016-01-12Convert port cidr splitting to str_splitSteven Hardy13-52/+26
Previously we used an interim workaround which required a 2 digit subnet but now heat (as of liberty) has str_split, which was implemented for this purpose. Change-Id: I29bb5f407b717e26a09c8c661954ee07fff72d71
2015-12-18Add Management Network For System Administration.Dan Sneddon4-0/+54
This change adds a system management network to all overcloud nodes. The purpose of this network is for system administration, for access to infrastructure services like DNS or NTP, or for monitoring. This allows the management network to be placed on a bond for redundancy, or for the system management network to be an out-of-band network with no routing in or out. The management network might also be configured as a default route instead of the provisioning 'ctlplane' network. This change does not enable the management network by default. An environment file named network-management.yaml may be included to enable the network and ports for each role. The included NIC config templates have been updated with a block that may be uncommented when the management network is enabled. This change also contains some minor cleanup to the NIC templates, particularly the multiple nic templates. Change-Id: I0813a13f60a4f797be04b34258a2cffa9ea7e84f
2015-12-15Allow for usage of pre-allocated IPs for the controller nodesGiulio Fidente15-2/+311
This change adds a new *_from_pool.yaml meant to return an IP from a list instead of allocating a Neutron port, useful to pick an IP from a pre-defined list and making it possible to configure, for example an external balancer in advance (or dns), with the future IPs of the controller nodes. The list of IPs is provided via parameter_defaults (in the ControllerIPs struct) using ControllerIPs param. Also some additional VipPort types are created for the *VirtualIP resources. The VIPs were previously created using the same port resource used by the nodes, but when deploying with an external balancer we want the VIP resource to be nooped instead. Change-Id: Id3d4f12235501ae77200430a2dc022f378dce336
2015-12-11Merge "Update typos"Jenkins8-8/+8
2015-12-03Merge "Make all network ports type to consume FixedIPs"Jenkins4-0/+28
2015-11-24Update typosSwapnil Kulkarni (coolsvap)8-8/+8
Change-Id: Id63c1bcfc34058eb7285698ba9bf86d1cf2025a6
2015-11-24Add net_vip_map_external to be used for an external balancerDan Prince8-1/+57
Changes VipMap into a new NetVipMap resource which defaults to being the same as the 'old' VipMap. An environment file can be used to map NetVipMap instead to the net_vip_map_external.yaml which allows for passing in explicit Virtual IP addresses. It also ensures that references to the Virtual IPs are gathered from the VipMap resource and allows for an empty ControlPlaneIP parameter in the neutron port templates where it can be. Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Change-Id: Ifad32e18f12b9997e3f89e4afe3ebc4c30e14a86
2015-11-16Make all network ports type to consume FixedIPsGiulio Fidente4-0/+28
This change adds to the internal_api, storage, storage_mgmt and tenant network ports the FixedIPs param and make them consume it when passed. Change-Id: Ica2bca9f573b206cc60c9d572224a8cc7b9b8aa4
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-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-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-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