This change adds a StorageNFS network. It's required by
https://review.openstack.org/#/c/471245 which implements
NFS Ganesha backend for Manila service.
To define and enable the StorageNFS network, deploy using
network_data_ganesha.yaml instead of network_data.yaml.
Besides the former adding the StorageNFS network, these
are otherwise identical.
If enabled it's also necessary to add StorageNFSIpSubnet and
StorageNFSNetworkVlanID heat parameters into network templates.
Co-Authored-By: Dan Sneddon <dsneddon@redhat.com>
Change-Id: If31722d669efe91082c93ecb815e6c41676480c8
Partially-Implements: blueprint nfs-ganesha
The subnet property is added to puppet/role.role.j2.yaml as
`{{role}}ControlPlaneSubnet`. Roles with a different subnet specified
can be used to deploy a routed network architecture by using one
role per routed network.
When enabling the neutron segments plug-in to support routed-networks
the neutron IPAM code will defer ipallocation unless the port create
request contain enough details. (Ref: LP Bug: #1695740) By adding the
subnet to port create request this change enables tripleo deployment
on an undercloud with Neutron segments plug-in and routed networks.
This depends on a Heat change that improves network logic in server
resource to not replace the current port if new props match what is
on the current interface. Without this adding the subnet property on
update/upgrades would cause a port replacement, which in turn would
cause IPAM info in undercloud neutron to miss-match the deployed
overcloud nodes.
Depends-On: Iab75ec49b962617943017dcaf1b04b89f91a982e
Change-Id: I33804bfd105a13c25d6057e8414e09957939e8af
Implements: blueprint tripleo-routed-networks-deployment
Add ODL endpoint and use it to get ODL port. Public access to
ODL is not allowed and hence the public endpoint is missing.
Internal endpoint is used for all internal communication and
TLS is enabled for that.
Change-Id: I66af960c6732f5d2efa8ea2db28cad122e321999
As a preparation for the new contrail microservices current templates are
removed.
Change-Id: Iea61fefe9a147b96cf00a008bbb61a482eb95a75
Closes-Bug: 1741452
Vnet interfaces are not supported by the dhcp client.
Bug #1731871
Change-Id: I8c0d6b0885f7e5fac94f78c8d6b6a6bf198ff424
Signed-off-by: Wojciech Dec <wdec@cisco.com>
Now that Keystone v2 has been removed, we can update this to a versionless
path. This output is used by tripleo-common to populate the overcloudrc file.
Closes-Bug: #1727454
Change-Id: I482f77443ed6255fb9f1b67241dd6260be574e7f
The role name is actually "ObjectStorage", not "SwiftStorage". This
leads do failing deployments if one or more ObjectStorage nodes are
deployed on the overcloud.
Closes-Bug: 1727475
Change-Id: I96fd27bdad5d417f23550ecc3387d81fd3c5418a
This reverts commit 97244b942d.
This introduced a bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1501515
where during upgrade, the previous heat resource would for the
InternalApi network would have the incorrect name "Internal" and the
upgrade would try to delete the resource in order to create
"InternalApi". This needs to be reverted and a proper fix will be
submitted that accounts for this upgrade scenario.
Related-Bug: #1718764
Change-Id: Ied908020ed856a5573f1333b9139029d0ffc37b4
This change removes the External network from the Networker
role, since it is not used or needed on that role.
The External network appers in the NIC config templates for the
Networker role, but this network is not used by the Networker
role. This results in deployment errors, since no IP address
is created for the External network, and the Networker roles
cannot reach an external gateway.
Change-Id: I78e0c9b50a7fee8efeea1ab639b44e0c6f2aa922
Closes-bug: 1720257
Cold migration network is determined by the value of my_ip in nova.conf.
If this isn't set then the network with the default gateway will be used.
This patch sets my_ip and the whitelisted IP for cold migation over SSH to the
NovaApiNetwork.
Until https://bugs.launchpad.net/nova/+bug/1671288 is fixed we cannot control
the network used for live migration over SSH. It is determined by hostname
resolution.
This patch sets the whitelisted IP for live migration over SSH to the hostname
resolution network for the role - which is typically the same as NovaApiNetwork.
(NB The puppet manifest will remove duplicates).
Live migration over TLS is not affected. It can control the network used so it
configurable via NovaLibvirtNetwork.
Change-Id: Ica3f79d6d0cfae446e276172146f3a9407f2971f
Depends-On: Id22a6c990f424b9f3ca6159088540ea207460ffd
With the dynamic Jinja2 rendering for networks, the heat resource for
Internal API network was accidentally being renamed to:
OS::TripleO::Network::Internal
when it should be the same as previous versions:
OS::TripleO::Network::InternalApi
This patch removes the 'compat_name' which was overriding the network
name for rendering the resource. This patch also removes the
compat_name functionality from the network/networks.j2.yaml file
since it is no longer needed.
Closes-Bug: 1718764
Change-Id: If756cddd91933edb303cc056515d98b941a3eb14
Signed-off-by: Tim Rozet <trozet@redhat.com>
Upgrades from older versions using Management network fail.
This patch enables the management network even though it is not
enabled in any of the role definitions. This will allow upgrades
to complete using existing network environment files, without
requiring operators to switch to the new method for defining
which networks are attached to roles. Eventually these older
environment files will be removed.
Change-Id: Iadd12a559f0ad6918958a1355f189187fd327363
Closes-bug: 1717123
This change renders the IPv6 versions of the isolated
networks using j2. To allow for backward compatibility,
there will be 2 versions of the network definitions,
<network>.yaml and <network>_v6.yaml. If the ip_subnet
contains an IPv6 address, or if ipv6: true is set on the
network definition in network_data.yaml, then the
<network>.yaml version will contain an IPv6 definition,
otherwise the <network>.yaml will be IPv4, and the
<network>_v6.yaml will be IPv6.
In a future follow-up patch, we will probably only
create the required versions of the networks, either
IPv4, IPv6, not both.
The ipv6_subnet, ipv6_allocation_pools, and ipv6_gateway
settings in the network_data.yaml definition file are
used for the <network>_v6.yaml network definition.
Note that these subnet/cidr/gateway definitions only set
the defaults, which can be overridden with parameters
set in an environment file.
Since the parameters for IP and subnet range are the
same (e.g. InternalApiNetCidr applies to both IPv4/v6),
only one version can be used at a time. If an operator
wishes to use dual-stack IPv4/IPv6, then two different
networks should be created, and both networks can be
applied to a single interface.
Note that the workflow for the operator is the same as
before this change, but a new example template has been
added to environments/network-environment-v6.yaml.
Change-Id: I0e674e4b1e43786717ae6416571dde3a0e11a5cc
Partially-Implements: blueprint composable-networks
Closes-bug: 1714115
Modified the config for compute with DPDKbond
and added a configuration for multiqueue
Change-Id: I1269b65160e07a6b59c64ccc98ac6df8306f9a8c
Signed-off-by: Karthik S <ksundara@redhat.com>
Configure_safe_defaults() should handle carrier check failures
in the same way as the change that was made to
dhcp-all-interfaces.sh in https://review.openstack.org/#/c/419527/.
That is, it should ignore failures when cat'ing the carrier file.
Change-Id: I100a40835d0ccecee9b4851aae6366c6ab4813a5
Closes-Bug: 1712687
Remove these from the j2 excludes and instead render all the networks
to avoid duplication.
Change-Id: Id8e14e06ffe959c50456b4c88fef306046a8b478
Partially-Implements: blueprint composable-networks
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
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
We were missing the square brackets around the list of arguments
for get_attr when building the networks cidr output.
This passed CI because Heat does not fail validation and Ceph (which
is consuming the cidr output) is tested with a single network (ctlplane)
which does not build the output using the same templates.
Change-Id: I40bba0784a30295cb0d4eda1fbff20ebac85db99
Closes-Bug: #1709464
We had an history mapping for InternalApi to InternalNetwork. If we
remove it then heat will want to destroy InternalNetwork and create
InternalApi which cannot work during upgrade.
This adds compat name parameters to network_data.yaml.
Closes-Bug: #1709105
Change-Id: I8ce6419a5e13a13ee6e991db5ca2196763f52d7a
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
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
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
This patch moves Contrail roles communication from public/external
to internal_api network for OpenStack API.
It also adds the option to enable dpdk.
Monolithic firstboot script is broken down into small pre-network
and per-node extraconfig scripts
Change-Id: I296a3bf60cef6fa950fd71d6e68effe367d1e66b
Closes-Bug: 1698422
Makes it possible to resolve network subnets within a service
template; the data is transported into a new property ServiceData
wired into every service which hopefully is generic enough to
be extended in the future and transport more data.
Data can be consumed in service templates to set config values
which need to know what is the subnet where a deamon operates (for
example the Ceph Public vs Cluster network).
Change-Id: I28e21c46f1ef609517175f7e7ee19e28d1c0cba2