| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Master is now the development branch for pike
changing the release alias name.
Change-Id: I938e4a983e361aefcaa0bd9a4226c296c5823127
|
|
This will hopefully help developers know what to do if their patch fails
this verification.
Change-Id: I01fe9ca30295c6264affdbdb773b039a744289ea
|
|
the version it was using was 2015-04-30, but we should be using ocata
instead.
Change-Id: I3eca2f235b3623f08e9cd6b7c2eafe0959b2fb3c
|
|
The endpoint map has the capability of using the cloud's name for the
endpoint. This is broken, however, since this has the problem that we
only take into account the overcloud's external endpoint name, which
we then cannot use if we have network-isolation enabled, which is
the most common use-case for real deployments.
So this change proposes the following:
* The external endpoint is still CloudName.
* We can now set different (or the same if we want) names for the
different VIPs of the network.
* Using CLOUDNAME for the endpoint map will get a name for the
appropriate network.
bp tls-via-certmonger
Change-Id: I3e7144653f0a1d783d87e6f638304b297f718929
|
|
Currently we have a hard-coded set of per-service parameters, which
will cause problems for custom roles and full composability.
As a first step towards making this more configurable, remove the
hard-coded per-service parameters from overcloud.yaml, and adjust
the EndpointMap generation to instead accept two mappings, the
ServiceNetMap and a mapping of networks to IPs (effectively this
just moves the map lookup inside the endpoint map instead of
inside overcloud.yaml)
Change-Id: Ib522e89c36eed2115a6586dd5a6770907d9b33db
Partially-Implements: blueprint custom-roles
|
|
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
|
|
A stack is an extremely heavyweight abstraction in Heat. Particularly in
TripleO, every stack includes a copy of all the template and environment
data for all of the stacks in the tree, all of which must be stored anew
in the database.
The EndpointMap abstraction created no fewer than 30 nested stacks, none
of which contained any resources but which existed purely for the
purpose of abstracting out some intrinsic functions used to calculate
the endpoint URLs for the various services. This likely adds several GB
to the memory requirements of the undercloud, and can cause things to
slow to a crawl since all 30 nested stacks need to be queried whenever
we need data from any one of them.
This change eliminates the nested stacks and instead generates the
endpoint map statically. This can be done offline in less than 250ms,
allows the input data to be expressed in an even more human-readable
form, and reduces the runtime overhead of the endpoints map by a factor
of 31, all with no loss of functionality, compatibility or flexibility.
Since we don't run a setup script to generate the tarball, the
endpoint_map.yaml output is checked in to source control. The build
script offers a --check option that can be used to make sure that the
output file is up-to-date with the input data.
Change-Id: I2df8f5569d81c1bde417ff5b12b06b7f1e19c336
|
Carlos Camacho
Juan Antonio Osorio Robles
Steven Hardy
Dan Sneddon
Zane Bitter