| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This change adds paramters to specify which networks the Swift API
services will use. If the storage network exists, it will be used
for the Swift API, otherwise the Undercloud 'ctlplane' network will
be used. If the storage_mgmt network exists, it will be used for
the back-end storage services, otherwise the 'ctlplane' will be
used by default.
Change-Id: I1d5e966a16416c52935c22efe2d4783cd2192c32
|
|
This change adds parameters to specify which networks the Nova API and
metadata services will use. If the internal_api network exists, it will be
used for the bind IP for Nova API and metadata servers, otherwise the
Undercloud 'ctlplane' IP will be used by default.
Change-Id: Ie420274c7fba80abf9cf2b599431acc47e28fc7a
|
|
This change adds parameters to specify which networks the Heat services
will use. If the internal_api network exists, the Heat API, Heat Cloud
Formations, and Heat Cloudwatch services will bind to the IP address on
that network, otherwise the services will default to the IP on the
Undercloud 'ctlplane' network.
Change-Id: I5febe1b9071600b43fa76c6cf415db83cad472ab
|
|
|
|
This change adds parameters to specify which network the Neutron API should
use. If the internal_api network exists, Neutron will bind to the IP on that
network, otherwise the Undercloud 'ctlplane' network will be used. The
network that the Neutron API is bound to can be overridden in an environment
file.
Change-Id: I11bcebba3a22e8850095250a2ddfaf972339476b
|
|
This change adds parameters to specify which networks the Keystone API
services will use. If the external network exists, Keystone will bind to
the IP on that network for the public API, otherwise it will default to
the IP on the Undercloud 'ctlplane' network. If the internal_api network
exists it will be used for the Keystone Admin API, otherwise it will
default to the 'ctlplane' IP. The networks these APIs are bound to can
be overridden in an environment file.
Change-Id: I6694ef6ca3b9b7afbde5d4f9d173723b9ce71b20
|
|
This change adds parameters to specify which networks the Glance services
will use. If the internal_api network exists, Glance Registry will bind
to the IP on that network, otherwise it will default to the Undercloud
'ctlplane' network. If the storage network exists, Glance API will bind
to the IP on that network, otherwise it will default to 'ctlplane'. The
networks that these services use can be overridden with an environment
file.
Change-Id: I6114b2d898c5a0ba4cdb26a3da2dbf669666ba99
|
|
|
|
|
|
This change adds parameters to specify which networks the Cinder API and
Cinder iSCSI services will listen on. If the internal_api network exists,
Cinder API will be bound to the IP on that network, otherwise it will
default to the Undercloud 'ctlplane' network. The Cinder iSCSI service will
bind to the storage network if it exists, otherwise will also default to
using the Undercloud 'ctlplane' network.
Change-Id: I98149f108baf28d46eb199b69a72d0f6914486fd
|
|
|
|
|
|
|
|
This change adds the parameters to specify which networks the Ceilometer
and MongoDB servers listen on. It is set to the internal_api network if
present, and reverts to the default Undercloud 'ctlplane' network if not.
Change-Id: Ib646e4a34496966f9b1d454f04d07bf95543517f
|
|
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
|
|
This commit adds an environment file which adds all
the relevant resource registry entries to enable isolated
overcloud networks.
Change-Id: I8c5e0ca300b86a38925f59c9df7831d69da9f787
|
|
This patch removes the custom config_id outputs and replaces
it with OS::stack_id which allows us to just call get_resource
in the parent stack.
The motivation for this change is we'll be adding more os-net-config
templates and it would be nice to take advantage of this newer
template feature.
Change-Id: I6fcb26024b94420779b86766e16d8a24210c4f8e
|
|
This patch uses the new NetIpMap and ServiceMap abstractions
to assign the Neutron tenant tunneling network addresses.
By default this is associated with the tenant network. If no
tenant network is activated this will still default to
the control plane IP address.
Change-Id: I9db7dd0c282af4e5f24947f31da2b89f231e6ae4
|
|
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
|
|
This patch updates the cinder block storage roles so that
they can optionally make use of isolated network
ports on the storage, storage management, and internal_api
networks.
-Multiple networks are created based upon settings in the heat
resource registry. These nets will either use the noop network (the
control plane pass-thru default) or create a custom Neutron port on
each of the configured networks.
-The ipaddress/subnet of each network is passed passed into the
NetworkConfig resource which drives os-net-config. This allows the
deployer to define a custom network template for static IPs, etc
on each of the networks.
-The ipaddress is exposed as an output parameter. By exposing
the individual addresses as outputs we allow Heat to construct
collections of ports for various services.
Change-Id: I4e18cd4763455f815a8f8b82c93a598c99cc3842
|
|
This patch updates the swift roles so that
they can optionally make use of isolated network
ports on the storage, storage management, and internal API
networks.
-Multiple networks are created based upon settings in the heat
resource registry. These nets will either use the noop network (the
control plane pass-thru default) or create a custom Neutron port on
each of the configured networks.
-The ipaddress/subnet of each network is passed passed into the
NetworkConfig resource which drives os-net-config. This allows the
deployer to define a custom network template for static IPs, etc
on each of the networks.
-The ipaddress is exposed as an output parameter. By exposing
the individual addresses as outputs we allow Heat to construct
collections of ports for various services.
Change-Id: I9984404331705f6ce569fb54a38b2838a8142faa
|
|
This patch updates the ceph roles so that
they can optionally make use of isolated network
ports on the storage and storage management networks.
-Multiple networks are created based upon settings in the heat
resource registry. These nets will either use the noop network (the
control plane pass-thru default) or create a custom Neutron port on
each of the configured networks.
-The ipaddress/subnet of each network is passed passed into the
NetworkConfig resource which drives os-net-config. This allows the
deployer to define a custom network template for static IPs, etc
on each of the networks.
-The ipaddress is exposed as an output parameter. By exposing
the individual addresses as outputs we allow Heat to construct
collections of ports for various services.
Change-Id: I35cb8e7812202f8a7bc0379067bf33d483cd2aec
|
|
This patch updates the compute roles so that
they can optionally make use of isolated network
ports on the tenant, storage, and internal_api networks.
-Multiple networks are created based upon settings in the heat
resource registry. These nets will either use the noop network (the
control plane pass-thru default) or create a custom Neutron port on
each of the configured networks.
-The ipaddress/subnet of each network is passed passed into the
NetworkConfig resource which drives os-net-config. This allows the
deployer to define a custom network template for static IPs, etc
on each of the networks.
-The ipaddress is exposed as an output parameter. By exposing
the individual addresses as outputs we allow Heat to construct
collections of ports for various services.
Change-Id: Ib07b4b7256ede7fb47ecc4eb5abe64b9144b9aa1
|
|
This patch updates the controller roles so that
they can optionally make use of isolated network
ports on each of 5 available overcloud networks.
-Multiple networks are created based upon settings in the heat
resource registry. These nets will either use the noop network (the
control plane pass-thru default) or create a custom Neutron port on
each of the configured networks.
-The ipaddress/subnet of each network is passed passed into the
NetworkConfig resource which drives os-net-config. This allows the
deployer to define a custom network template for static IPs, etc
on each of the networks.
-The ipaddress is exposed as an output parameter. By exposing
the individual addresses as outputs we allow Heat to construct
collections of ports for various services.
Change-Id: I9bbd6c8f5b9697ab605bcdb5f84280bed74a8d66
|
|
This patch adds parameters so that we can pass in the
ipaddress/subnet for each of the isolated overcloud
traffic nets to os-net-config templates. This
interface change will allow deployers to plug
in a custom version of an os-net-config template
that drives isolated network configuration.
Change-Id: I35bbe9a0bd81e79f9bfd531fe89c700af8b354c4
|
|
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
|
|
|
|
When combined with --with-steps added to devtest_overcloud:
https://review.openstack.org/#/c/162109/ this enables stepped
deployments using heat hooks.
This environment file will break on all *StepN resources in every
*NodesPostDeployment resource, on both create and update.
Change-Id: Ibab567f0a37b832ea2b5966288ad55b5682c31ab
|
|
This patch enables uses to selectively enable the creation
of split out networks for the overcloud traffic. These
networks will be created on the undercloud's neutron
instance.
By default a noop network is used so that no extra networks
are created. This allows our default to continue being
all traffic on the control plane.
Change-Id: Ied49d9458c2d94e9d8e7d760d5b2d971c7c7ed2d
|
|
|
|
Previously the Glance Pacemaker resources were mistakenly defined
on all nodes causing intermittent duplication errors.
Change-Id: I839ee49b153aa96ec08ebdb7e44aaeac28785963
|
|
Change-Id: I4631f962415164975143e94ec0b251ee5972c552
|
|
|
|
|
|
Align all Deployment resource so we can use a glob convention for
stepped deployments via heat hooks/breakpoints.
Since most resources already use a FooDeployment_StepN convention,
align those which deviate from this as a precursor to supporting
stepped deployment, e.g stepping through "*Deployment_Step*".
Change-Id: I6bfee04649aa36116d1141ebe06d08b310ec8939
|
|
|
|
Change-Id: If87cc4d55e8524246d2cd41a62805f84780006b2
|
|
Add Pacemaker resources for Cinder services, also add relevant ordering
and colocation constraints.
Change-Id: Idc2e1b5ec96d882543f7a1a4ec723a010020ab02
|
|
|
|
With change I4b6b77e878017bf92d7c59c868d393e74405a355 we started
using the root user for clustercheck script so we don't need to
create the clustercheck user anymore.
Change-Id: Ic92bd12baeeeaf3f674e766fbc0a8badfb44822f
|
|
|
Jenkins
Dan Sneddon
Dan Prince
Steven Hardy
Giulio Fidente
Jay Dobies
Jiri Stransky