Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
This enables the deployer to dynamically add nova metadata to the
servers based on the output of service profiles that implement the
metadata_settings key in the role_data output for the profiles.
One can set an implementation via the OS::TripleO::ServerMetadataHook
resource, which currently is set as OS::Heat::None. So, because of
the default implementation, if left untouched it actually does
nothing.
Currently, besides the list, which is metadata_settings, this hook also
takes the name of the node that it's setting the metadata for.
This is useful for nova vendordata plugins that can parse said metadata.
Change-Id: I8a937f711f0b90156fbb6c4632760435ef846474
|
|
Currently when the docker environments are invoked, every node has the
boot script run which replaces os-collect-config with the heat-agents
container. This should only be happening on Compute nodes currently,
and each role will be converted to heat-agents one at a time.
This change implements a role-specific NodeUserData resource and uses
that mechanism to run docker/firstboot/install_docker_agents.yaml only
on Compute nodes.
Change-Id: Id81811dbcaf0e661c3980aa25f3ca80db5ef0954
|
|
This allows us to take advantage of the composable roles hiera
settings to connect the plugin to the northd/ovndb API without
needing to hard-code the IP of the node running the service.
Change-Id: I2508d48f81c1819ae3521fff271c0bdc50724604
Depends-On: I9af7bd837c340c3df016fc7ad4238b2941ba7a95
Closes-Bug: #1634171
|
|
There are some requirements for early configuration that involves
e.g setting kernel parameters then rebooting. Currently this can
be done via cloud-init, e.g firstboot templates, but there's been
discussion around enabling a SoftwareDeployment approach instead.
The main advantage of doing it this way is there's an error path
if something goes wrong with the config (except triggering the
reboot as we have to use NO_SIGNAL for that).
Change-Id: Ia54ee654f755631b8062eb5c209a60c6f9161500
|
|
This patch adds a new type called:
OS::TripleO::Network::Ports::ControlPlaneVipPort
This defaults to a normal OS::Neutron::Port object but can
be mocked out for some implementations like when installing
the undercloud where neutron doesn't exist.
Change-Id: Iebf2428432a98a9d789b206ce973599adbc0af8f
|
|
|
|
This shows how we could wire in the upgrade steps using Ansible
as was previously proposed e.g in https://review.openstack.org/#/c/321416/
but it's more closely integrated with the new composable services
architecture.
It's also very similar to the approach taken by SpinalStack where
ansible snippets per-service were combined then run in a series of
steps using Ansible tags.
This patch just enables upgrade of keystone - we'll add support for
other patches in subsequent patches.
Partially-Implements: blueprint overcloud-upgrades-per-service
Change-Id: I39f5426cb9da0b40bec4a7a3a4a353f69319bdf9
|
|
|
|
This patch drops use of the vip-hosts.yaml service which can
cause issues during deployment because puppet 'hosts' resources
overwrite the data in /etc/hosts. The only reason things seem to work
at all at the moment is because our hosts element in t-i-e runs
on each os-refresh-config iteration and re-adds the dropped hosts
entries.
To work around the issue we add a conditional which selectively
adds the extra hosts entries only if the AddVipsToEtcHosts is set
to true.
Closes-bug: 1645123
Change-Id: Ic6aaeb249a127df83894f32a704219683a6382b2
|
|
This adds the necessary hieradata for enabling TLS for MySQL (which
happens to run on the internal network). It also adds a template so
this can be done via certmonger. As with other services, this will
fill the necessary specs for the certificate to be requested in a
hash that will be consumed in puppet-tripleo.
Note that this only enables that we can now use TLS, however, we still
need to configure the services (or limit the users the services use)
to only connect via SSL. But that will be done in another patch, as
there is some things that need to land before we can do this (changes
in puppetlabs-mysql and puppet-openstacklib).
Change-Id: I71e1d4e54f2be845f131bad7b8db83498e21c118
Depends-On: I7275e5afb3a6550cf2abbb9a8007dedb62ada4b4
|
|
|
|
This change modifies the template interface to support containers and
converts the compute services to composable roles.
Co-Authored-By: Dan Prince <dprince@redhat.com>
Co-Authored-By: Flavio Percoco <flavio@redhat.com>
Co-Authored-By: Martin André <m.andre@redhat.com>
Co-Authored-By: Steve Baker <sbaker@redhat.com>
Change-Id: I82fa58e19de94ec78ca242154bc6ecc592112d1b
|
|
This integrates panko service api into tripleo heat templates.
By default, we will disable this service, an environment service
file is included to enable if needed.
Depends-On: I35f283bdf8dd0ed979c65633724f0464695130a4
Change-Id: I07da3030c6dc69cce7327b54091da15a0c58798e
|
|
Adds new puppet and puppet pacemaker specific services for Zaqar.
The Pacemaker templates extend the default Zaqar services and swap in
the Pacemaker specific puppet-tripleo profile instead.
Change-Id: Ia5ca4fe317339dd05b0fa3d5abebca6ca5066bce
Depends-On: Ie215289a7be681a2b1aa5495d3f965c005d62f52
Depends-On: I0b077e85ba5fcd9fdfd33956cf33ce2403fcb088
Implements: blueprint composable-services-within-roles
|
|
The capitalization of OS::Tripleo is wrong compared to all other services
so correct this for avoidance of confusion when folks write custom roles_data
files or pass custom service lists via *Services parameters.
Change-Id: Ib73c80871b45586edb5774e90280ff89fc0d9895
Closes-Bug: 1640871
|
|
|
|
After deploying a fresh installed Overcloud or updating the stack
the haproxy configuration is updated correctly but no change in the
HA proxy stats happens.
This submission will add the missing resources to run pre and post
puppet tasks.
Closes-bug: 1640175
Change-Id: I2f08704daeee502c618256695a30ce244a1d7ba5
|
|
For parameter merge strategies to work we need to merge multiple environment
files, which doesn't consider the defaults defined in the heat template.
Moving where we define these defaults will enable the merge strategies
applied when appending services to roles in environment files to work.
Change-Id: I1ef1ad685c8a15308d051665c576a98b277f2496
Closes-Bug: #1635409
|
|
|
|
This adds an environment file that can be used to enable TLS in
the internal endpoints via certmonger if used. This will include
a nested stack that will create the hash that will be used to
create the certmonger certificates.
When setting up a service over apache via puppet, we used to disable
explicitly ssl (which sets modd_ssl-related fields for that vhost).
We now make this depend on the EnableInternalTLS flag. This has only
been done for keystone, but more services will be added as the
puppet code lands
bp tls-via-certmonger
Depends-On: I303f6cf47859284785c0cdc65284a7eb89a4e039
Change-Id: I12e794f2d4076be9505dabfe456c1ca6cfbd359c
|
|
Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
Depends-On: If2804b469eb3ee08f3f194c7dd3290d23a245a7a
Depends-On: I091ecfbcb2e38fe77203244ac7a597aedcb558fb
Change-Id: Iacc504fc4fa2d06893917024ce2340d3fb80b626
|
|
|
|
This patch moves the hosts configuration into its own deployment.
It will continue to use os-apply-config as something that is
required early on in the bootstrapping (it needs to be
configured before puppet runs for example).
The motivation here is so we can refactor all-nodes-config.yaml to use a
new hiera hook that that avoids os-apply-config entirely.
Change-Id: Ib3e4380f205358b27d22a1102b663cf300b1ed86
Partial-bug: #1596373
|
|
|
|
Added contrail resource registry entries.
Implements: blueprint contrail-services
Change-Id: I03894bff63d54637ba1b10a279e2d75f97a06b3c
|
|
Unfortunately we use "SwiftStorage" in the ObjectStorage role
template, so we have to special-case this for backwards compatibility
or deployments enabling the ObjectStorage role will fail.
Ideally we'd align the port names in the objectstorage-role.yaml, but we
can't becauuse all the ports would be replaced in existing deployments
on update.
Change-Id: Ia07e193d2b9a4d33c6272c2b4448133584b81350
Closes-Bug: #1632663
|
|
This patch modifies the service name to be more appropriately called
"OpenDaylightApi" along side the "OpenDaylightOvs" service used to
configure OpenVSwitch. It also splits out the OVS configuration for
controller nodes into the composable OpenDaylightOvs service.
Related-Bug: #1629408
Change-Id: I15221401acdfb2a9ef81107b54a8005348f8372f
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
When generating these templates, we should
create them with the "-role" appended as they will
be generated from a role.role.j2.yaml file.
i.e. role.role.j2.yaml will generate <service>-role.yaml
config.role.j2.yaml will generate <service>-config.yaml
Partial-Bug: #1626976
Change-Id: I614dc462fd7fc088b67634d489d8e7b68e7d4ab1
|
|
|
|
This adds some basic pieces to get certmonger to manage the
certificates for HAProxy. The aim is to be flexible enough that we
will be able to manage both public and internal certificates.
This also adds a relevant environment to get the endpoints to have
TLS everywhere.
bp tls-via-certmonger
Depends-On: I89001ae32f46c9682aecc118753ef6cd647baa62
Change-Id: Ife5f8c2f07233295bc15b4c605acf3d9bd62f162
|
|
We do not want cinder-volume to be managed by Pacemaker on
BlockStorage nodes, where Pacemaker is not running at all.
This change adds a new BlockStorageCinderVolume service name
which can (and is, by default) mapped to the non Pacemaker
implementation of the service.
The error was:
Could not find dependency Exec[wait-for-settle] for
Pacemaker::Resource::Systemd[openstack-cinder-volume]
Also moves cinder::host setting into the Pacemaker specific service
definition because we only want to set a shared host= string when
the service is managed by Pacemaker.
Closes-Bug: #1628912
Change-Id: I2f7e82db4fdfd5f161e44d65d17893c3e19a89c9
|
|
Moving the rest of the static based resource registry
entries to j2, this allows to extend the content of the
template to the roles_list.
Also moved the templates to correspond with the role name.
Partial-Bug: #1626976
Change-Id: I1cbe101eb4ce5a89cba5f2cc45cace43d3380f22
|
|
The default resource-registry file contains a bunch of per-role
things which mean you need to cut/paste into a custom environment
file for custom roles, even if you only want the defaults like the
built-in roles. Using j2 we can template these just like in the
overcloud.j2.yaml and other files.
Change-Id: I52a9bffd043ca8fb0f05077c8a401a68def82926
Partial-Bug: #1626976
|