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
|
|
When you do a stack-update which affects, e.g ControllerDeployment
such that some value in hieradata is updated (for example changing
the "Debug" parameter to True), we only write the hieradata file and
don't reapply the manifests.
So we introduce a dependency on the deploy_stdout values from all
hieradata applying configs, such that the manifests will be re-applied
on update if the data is changed.
This requires https://review.openstack.org/#/c/190282/ so that
99-refresh-completed will return the derived config ID as part of the
deploy_stdout payload.
Closes-Bug: #1463092
Change-Id: I1175248c3236d0c42e37d062afce550efce8aadc
|
|
We want to make sure to be able to resolve the default domain
suffix (.localdomain) appended when no domain option is passed by
the dhcp server.
Change-Id: I33111e91b502f57da442e5745de2217bd6d2d882
|
|
This patch updates the Puppet Swift storage role
so that it supports network isolation. By default
all traffic still flows on the ctlplane network
but if network isolation is enabled then network
traffic will flow over the configured storage_mgmt
network interface.
This patch also fixes a few critical issues with
the swift storage role that prevented it from
working:
- oac_data for the swift devices was overriding the
data provided in the swift_devices_and_proxy
hieradata file.
- the role was missing declarations to load hieradata
files for swift_devices_and_proxy and all_nodes
- The required snmpd settings were not getting set
correctly in the 'object' hiera data file.
With all of these changes the Swift storage role
works correctly with and without network isolation.
Change-Id: I541abb2604380f603bba91ad88e54783ee450a8f
|
|
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
|
|
Currently we use NO_SIGNAL on both the NetworkConfig and subsequent config
deploying the data associated with the role. This means there is a risk that
should the NetworkConfig do anything interruptive (os-net-config can do
interface renaming based on discovery data for example) the role configuration
config could fail, and we'd never know until some later error occurs.
Additionally, we need to be sure that the heiradata deployed by each of the role
specicific configs is actually in-place before proceeding with any of the cluster
configuration - atm this works due to the inherent delays involved deploying to
bare-metal, but there's still a theoretical race if very fast deployment backends
(I'm thinking containers, e.g lxc backend to nova or something) were used instead.
Essentially, we should never be using NO_SIGNAL unless we want to ignore failure,
which AFAICT is not the case in this instance.
Change-Id: I0dbbcc87fb8df8e6bc4775c39fa616b0d0713464
|
|
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
|
|
These appear in the Tuskar UI and CLI so are worth keeping
consistent with those of the controller/compute nodes
Change-Id: I7cdd3a67d6f190f43e279fad0c4bf5f409d1e161
|
|
This updates all of the puppet roles to use an optional
osfamily hieradata file which can be used to provide
distro specific settings.
Also, updates the controller role to make use of this
new file for setting the rabbitmq package_provider
parameter.
Change-Id: I46417db51b87b82bf276dfcef5647a90c37fb07d
|
|
This patch adds a new ObjectStoreNodesPostDeployment resource
which can be used along with the environment file to
specify a nested stack which is guaranteed to execute
after all the ObjectStore config deployments have executed.
This is really useful for Puppet in that Heat actually
controls where puppet executes in the deployment
process and we want to ensure puppet runs after
all hiera configuration data has be deployed to
the nodes. With the previous approach some of the
data would be there, but allNodes data would not be
guaranteed to be there in time.
As os-apply-config (tripleo-image-elements) have their
ordering controlled within the elements themselves an empty stubbed
in nested stack has been added so that we don't break that
implementation.
Change-Id: I778b87a17d5e6824233fdf9957c76549c36b3f78
|
|
This cleans up the top level tree by moving all the puppet
related bits into the puppet directory. The only exception
is overcloud-resource-registry-puppet.yaml which is
the puppet environment file and is used externally.
Change-Id: Idb65a7143b0f29e5579d4e9d1642e4cda6f65d50
|