| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Currently, we use the heat default server names, which results in some
fairly unreadable hostnames due to the level of nesting in the templates.
e.g ov-sszdbj5rdne-0-bhseh65edxv6-Controller-zoqc6tlypbdp
Instead, we allow the user to specify a format string per role, defaulted
to a string which formats the name e.g <stackname>-controller-<index>
e.g overcloud-controller-0
Optionally additional hostname components (not replaced by heat) could be
added, such that deployment time customization of hostnames via firstboot
scripts (e.g cloud-init) may be possible.
Should anyone wish to maintain the old heat-generated names, they can pass
an empty string via these parameters, which heat will treat as if no "name"
property was provided to OS::Nova::Server.
Change-Id: I1730caa0c2256f970da22ab21fa3aa1549b3f90b
|
|
This change adds config and deployment resources to trigger package
updates on nodes. The deployments are triggered by doing a stack-update
and setting one of the parameters to a unique value.
The intent is that rolling update will be controlled by setting
breakpoints on all of the UpdateDeployment resources inside the
role resource groups.
Change-Id: I56bbf944ecd6cbdbf116021b8a53f9f9111c134f
|
|
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 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 bumps the HOT version for the overcloud
to Kilo 2015-04-30. We should have already done this
since we are making use of OS::stack_id (a kilo feature)
in some of the nested stacks. Also, this will give us access to
the new repeat function as well.
Change-Id: Ic534e5aeb03bd53296dc4d98c2ac5971464d7fe4
|
|
Remove references to the .novalocal domain part in the hosts file.
Change-Id: Idf14907adaf2f35440b6f28870fe18434eadd1be
Depends-On: Iadfdf4120c4d1c9b6976321753957fd4eecf301c
|
|
This change allows a different network config for each family of hosts. For
instance, the controller may have a different network configuration than a
block storage node. This change adds a declaration for each family in the
overcloud-resource-registry.yaml & overcloud-resource-registry-puppet.yaml.
Change-Id: I083df7ebbb535f97d8ddec2ac0e06281c55986cd
|
|
Currently all the OS::Nova::Server resource created don't pass any
user-data. It's possible to pass user-data as well as using heat
SoftwareConfig/SoftwareDeployment resources, and this can be useful
when you have simple "first boot" tasks which are possible either via
cloud-init, or via simple run-once scripts.
This enables passing such data by implementing a new provider resource
OS::TripleO::NodeUserData, which defaults to passing an empty mime
archive (thus it's a no-op). An example of non no-op usage is also
provided.
Change-Id: Id0caba69768630e3a10439ba1fc2547a609c0cfe
|
|
Our existing default (replicas == 1) means that no data
(or copies) is being replicated in a multi-node Swift
environment. This seems like a bad production default
setting and could easily slip by if not set.
Setting it to 3 shouldn't hurt anything and seems to follow
suit with what several production installers (based around Puppet)
actually use. If using an installation with less than 3 swift
nodes I believe swift will do its best, and still work fine.
FWIW I noticed this when testing a multi-node Puppet swift
installation and was surprised when I didn't see any *data
files getting replicated across the storage cluster.
Change-Id: I44bdfff7aae6bdf845b79ca1f8f450c22113caed
|
|
In doing the Puppet version of the Swift role I noticed
4 parameters which we apply to storage nodes which should
not be required. This patch drops the following parameters
from the swift-storage and swift-storage-puppet nested
stacks which should not be required.
1) ControllerIP: There is no reason a storage node should need
the IP address of the controller. The swift proxy would need
this information in order to be able to contact keystone.
This swift-proxy is not installed on storage nodes so we can
drop the parameter here.
2) NeutronEnableTunnelling: There is no reason for Neutron
to be installed on Swift storage nodes. No need to create
an OVS bridge either.
3) NeutronNetworkType: Similar to above. No neutron requirements
exist here so this parameter is not required.
4) Password: This only applies to the the swift-proxy which is
currently part of our controller role. Storage nodes shouldn't need
the keystone service-password for any reason.
Change-Id: Icbf05363475c388fc722277da3d3d00a7355b19a
|
|
This was added in I36fece56bafa9fe9c4883b572687b3fc819eeae1
and is missing from overcloud-without-mergepy.
Change-Id: I5c2566cc77247574f8d687eaab8094de481a8c67
|
|
This was added in Icc5e431a7e2884b3ca3a255b6fd901619bc98460
and is missing from overcloud-without-mergepy.
Change-Id: I1273b646c04783712fd3f8baccafead11817689c
|
|
With the push to using the new setup-flavors provided by
os-cloud-config, the default flavor will no longer be called
'baremetal', and Heat will always validate the default even if it
is overridden. To that end, remove the default flavor from every
flavor definition. Just to be certain, also add a custom_constraint
to every flavor definition that was missing it.
Change-Id: I24251e73be4e86738857f73b89499f592c4908de
|
|
We've submitted a patch (https://review.openstack.org/#/c/130172/)
to set the value of mount_check to swift.mount-check if it exists,
and otherwise to set mount_check to false. By default TripleO
deployments set mount_check to false since they do not use mounted
disks to store data. However we (HP) and others are now using
TripleO to deploy Swift servers with mounted drives for data, in
which case mount_check should be set to True. This change adds
swift.mount-check data and sets it to the value of the
SwiftMountCheck parameter, which has a default value of False.
Change-Id: I36fece56bafa9fe9c4883b572687b3fc819eeae1
|
|
This patch extends the previous 'Don't use merge.py for overcloud'
commit with the cinder-storage.yaml and swift-storage.yaml templates.
Requirements for this to deploy:
1. Block and object storage images have to be built
(overcloud-cinder-volume and overcloud-swift-storage)
2. The images have to be loaded by devtest_overcloud.sh
OVERCLOUD_CINDER_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-cinder-volume.qcow2)
OVERCLOUD_SWIFT_ID=$(load-image -d $TRIPLEO_ROOT/overcloud-swift-storage.qcow2)
Change-Id: I45f9d9f051970a83e26c0fd924d7c98276958113
|
Steven Hardy
Steve Baker
Dan Prince
Giulio Fidente
Dan Sneddon
Steve Kowalik
Eamonn O'Toole
Peter Belanyi