| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This reverts commit 520be6bb4056ead8e6fad08ad96e99f7da5b341e.
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: Id906fac421db317ce48d5cecfcd43397a0f4ab3d
|
|
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>
(cherry picked from commit 97244b942d29d2b5acd7a3eb07acdba0d9b99677)
|
|
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
(cherry picked from commit 5b9fbc2b2bfa00de2fe0f437f21e05e3fc09a53d)
|
|
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
(cherry picked from commit dd299f08bd6b1df43760148d83ce9b6e09ba6572)
|
|
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 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
|
|
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
|
|
This moves the hard-coded networks from the default environment,
and provides the first step towards enabling composable networks.
Co-Author: Dan Sneddon <dsneddon@redhat.com>
Partial-Bug: #1633090
Depends-On: I9f818912bd8e2a3220e41c8ccbbab3d9063b4d72
Change-Id: I7793b8badede5450b05437c84d9b40c28de7546b
|
Tim Rozet
Dan Sneddon
Sofer Athlan-Guyot
Giulio Fidente
Steven Hardy