OVN is already default ML2 plugin in Overcloud since
Stein release[1]. OVN 22.06+ supports DHCP for IPv4 baremetal
ports so we can now use it instead of Ml2 OVS Services on
Undercloud.
This patch update roles and add environment file to allow
the Undercloud deployments with OVN.
Once upgrade/migration path is evaluated for Undercloud
from Ml2 OVS to Ml2 OVN we can consider switching default
Ml2 Plugin on Undercloud.
[1] https://review.opendev.org/c/openstack/tripleo-heat-templates/+/593056/
Change-Id: I724934f511a2d530521fd368e56e7bc2bcb07d76
This fixes the wrong command for undercloud installation mentioned in
the description of Undercloud role.
Change-Id: I6b51e0c8210d660e52b7078d2f043bc982b2e746
In ancient times, B&R used heat templates to deploy ReaR to the
controllers. Since a long time, this has been superseded by an ansible
playbook ran by openstack overcloud backup --setup-rear. Now, that
feature is duplicated, so we remove the possibility of installing
ReaR with heat.
A deprecation notice has been submitted to stable/train in patch #847148
Related-Bug: rhbz#2097611
Change-Id: Ic01c44ba35b6d28cb45879b1006633ac1fcf8d19
Keystone is no longer used in undercloud since we replaced it by basic
auth mechanism[1].
Also, memcached was used by caching(Keystone, Nova and Heat) and
the authtoken middleware but all of these are no longer used in
undercloud. (Ephemeral Heat does not use caching with memcached.)
[1] c293dfc7b1
Change-Id: Ifa80bee358edf1e8c07ed4ac62bcf676d65ab925
The iscsid service in undercloud was used for iscsi deploy interface
in Ironic but it was deprecated during Victoria cycle[1] and was
removed during Xena cycle[2].
[1] d8dccc8d06017e79f2b49afec069a18b3c7413fc
[2] 929907d68473ae8a433ebb8c4dcb110473d42676
Closes-Bug: #1973682
Change-Id: Ia430ffb7fb7ffe2d49e6b32f94d10a72c59e3a14
This is partial revert of 5bf166be61 and
adds back FRR to Undercloud. Actually it is required to use BGP in
control plane network but was removed by mistake.
Change-Id: I6d9a8260cc1e8cb1cf9e128fe8c09c59ebf026b1
With the recent changes meant to allow deployment of Ganesha on the
"external" network, the CephNfs service can be added to more roles
than just ControllerStorageNfs.
Change-Id: Ic9010307c2aab7041c8ae30c72cc1bf99fdd22f6
Closes-Bug: 1961578
As of Wallaby, Nova service no longer in use on Undercloud.
Keeping these in roles data waste container prepare cycles
and the registry space for unused container images.
Depends-On: https://review.opendev.org/827257
Change-Id: I36367b58d43347ccf0fc18de4665a10891faef10
Related-bug: #1959662
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Zaqar was deprecated in Wallaby and is no longer in use on the
undercloud and it hasn't been officially supported in the
overcloud for some time.
Change-Id: I3bdcc72d6127ec96ff2307cafbf57f6178c3ef5c
Mistral was deprecated in Wallaby and is no longer in use on the
undercloud and it hasn't been officially supported in the overcloud for
some time.
Change-Id: I6963453f53cb554ca8fdb58706f04838bbd11ba0
Rather than using a new service, we can use the existing HeatEphemeral
service we added to ensure the undercloud is prepared for the overcloud
deployment usage of the ephemeral heat version. Additionally this will
properly tear down the previous containered heat services once the data
has been extracted from the existing databases.
Change-Id: I13270a4866f9b339cb31ebba223121978e52b499
Adds a ephemeral heat service that ensures the containers are fetched on
the system and tagged specially for usage later with the overcloud
deployment process. After the service deploys, the following container
images should be available on the local system.
localhost/tripleo/openstack-heat-all:ephemeral
localhost/tripleo/openstack-heat-engine:ephemeral
localhost/tripleo/openstack-heat-api:ephemeral
Depends-On: https://review.opendev.org/c/openstack/tripleo-common/+/796614
Partial-Bug: #1931995
Change-Id: I923856c83c14eb54073684ace93e9e1e85f53329
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Co-Authored-By: Alex Schultz <aschultz@redhat.com>
Signed-off-by: Alex Schultz <aschultz@redhat.com>
A new service, OS::TripleO::Services::UndercloudUpgradeEphemeralHeat is
added to the Undercloud role. The service is mapped to OS::Heat::None by
default, but when environments/lifecycle/undercloud-upgrade-prepare.yaml
is included, the service will be enabled and will migrate any already
deployed stacks in the undercloud's Heat instance to be able to be used
with the ephemeral Heat deployment option from tripleoclient.
Signed-off-by: James Slagle <jslagle@redhat.com>
Change-Id: If11e2fc07a1ff773f6eaf209d8b48493f0b60e85
This adds support for BGP via the OS::TripleO::Services::Frr service.
Spec: https://review.opendev.org/c/openstack/tripleo-specs/+/758249
We create the frr configuration via the corresponding tripleo_frr
ansible role at step0. We start the FRR container at deployment step
1 before pacemaker gets configured as the routing to all the other nodes
needs to be functional before setting up the cluster.
Co-Authored-By: Carlos Gonçalves <cgoncalves@redhat.com>
Change-Id: I7cef73c57e7b69f4d031e220c954803afd5e0b8c
This is using linux-system-roles.certificate ansible role,
which replaces puppet-certmonger for submitting certificate
requests to certmonger. Each service is configured through
it's heat template.
Partial-Implements: blueprint ansible-certmonger
Depends-On: https://review.rdoproject.org/r/31713
Change-Id: Ib868465c20d97c62cbcb214bfc62d949bd6efc62
Previoously the default route was concatenated with the
host_routes in the NetworkConfig. This change moves that
concatenation to overcloud.yaml.
GroupVars {{network.name_lower}}_host_routes and
ctlplane_host_routes will have the default route appended
based on role.default_route_networks setting.
For heat base NetworkConfig the parameters
ControlPlaneStaticRoutes and {{network.name}}InterfaceRoutes
will have the default route appropriately appended.
Doing the concatenation in overcloud.yaml enable simplified
user-facing NetworkConfig templates.
For standalone and undercloud define the default_route_networks
with an empty list. Cannot leave it undefined as this will
default the default route to the ctlplane's gateway. Undercloud
and Standalone uses the management interface as the gateway by
default, so we should not set a default gateway for these roles.
Change-Id: I3a35c4b46536fa2916d9fa387278077884adaf68
This commit attempts to build out a composible service that enrolls the
undercloud as a FreeIPA host using an OTP. This is similar to what we've
done in the past for tls-everywhere except we're not using novajoin.
Change-Id: I770227b2f4f1ea447cf0138f57a6ed66c034d225
We don't deploy Keepalived in multi-node as our HA story is done with
Pacemaker. Therefore, we don't use VRRP protocol that Keepalived
provides to maintain the VIPs alive, so we don't really need this
service.
Instead, we can configure the VIPs on the br-ctlplane interface which
already handled the local_ip. Now it also handles the configuration of
public ip and admin ip.
Keepalived is now deprecated and will be removed in the next cycle.
blueprint replace-keepalived-undercloud
Change-Id: I3192be07cb6c19d5e26cb4cddbe68213e7e48937
There is no longer a need for stable/train to have a working nova-metadata-api
This reverts commit 00cd4b0aea.
Change-Id: I520b1104e0dff683834f5bed13a33858ce21abaf
This service is not required normally, but is required when updating
an existing overcloud from non-TLS to TLS (existing nodes need to
fetch the new vendor-data, which isn't available in the initial boot
config-drive)
Change-Id: I3685bd481fd23fbd83d8e6a1fadb72f2e57578bc
Partial-Bug: #1855929
Transfering to containerized deployment of undercloud we lost automated
configuration of SNMP for undercloud. Telemetry stack is now failing to
HW monitor this node.
Change-Id: I219e2a8a08bc9b47bd7110fadcb188ef703acfce
Create a new Rsyslog service that is deployed on the host (not in a
container) and with Ansible.
Make it so it's deployed by default on Undercloud & Standalone setups.
Also move the tasks that configure rsyslogd for HAproxy & Swift to be
executed after the host prep tasks (using deploy step tasks).
Change-Id: I027c64aefcc4715da17836a5cf0141152cf146aa
Closes-Bug: #1850562
The NovaAZConfig service is added to all the compute related roles
of the box so that the nodes are automatically in a new AZ when the
service is enabled.
By default, the service is mapped to OS::Heat::None so no change in
default behavior is made.
Change-Id: If1e4e149100dccfe76ccd807997a611d0fc8841f
This patch removes fluentd composable service in favor of rsyslog composable service
and modifies *LoggingSource configuration accordingly.
Change-Id: I1e12470b4eea86d8b7a971875d28a2a5e50d5e07
These endpoints won't exist on the undercloud in the U cycle, and this
sort of check overlaps with tripleo-validations anyway. This change
also removes the disable_constraints roles data attribute as there is
no longer anything to disable.
Possibly this means deployed-server/deployed-server-roles-data.yaml is
no longer required because it only exists to set
disable_constraints:true (although it lags roles_data.yaml by quite a
lot now)
It looks like tripleo-validations has checks for flavor and image
already, but not keypair. It is unlikely users stray from the
'default' keypair so it is probably fine to not have a validation of
this for the Train release.
Change-Id: Id6146bfdc124e6e3e64ee7caea3ddeb2552bfa71
Blueprint: nova-less-deploy
This is part 1 of a series of patches to properly deploy multipathd.
This patch makes Multipathd an optional TripleO service (defaults to
OS::Heat::None), and binds it to every role that might use the service.
This is essentially any role that accesses cinder volumes. Previously,
the service was not optional, but was not bound to any roles and so it
was never deployed.
Partial-Bug: #1834042
Change-Id: I3bc7d8557f758103c35533a59e06e36cd15f98b9
All known consumers of boot data (os-collect-config, etc) have a
preference for using config-drive as the data source.
The last known consumer was novajoin, but that switched to preferring
config-drive early in the Stein development cycle[1] so it should now
be safe to switch off the nova metadata API service.
[1] https://review.opendev.org/#/c/607492/
Blueprint: nova-less-deploy
Change-Id: If35aec24f446769fca7897c2126fb6657454f073
This change introduces an optional extracted version of the Placement
service into TripleO. This extracted version will only be required once
the Placement service is fully removed from Nova during the T cycle
(previously S but delayed) at which point the corresponding
NovaPlacement service will also be removed from TripleO.
The majority of this change is code motion between the original
NovaPlacement service and the new PlacementAPI service.
Upgrades from the original NovaPlacement service to the extracted
PlacementAPI service are not currently supported by this change and will
be worked on independently during the Train cycle.
Co-authored-by: mschuppert@redhat.com
Depends-On: https://review.openstack.org/#/c/624335/
Change-Id: I9e3287bcbe9d317f32bf6b468c6ee17f04b6fff9
We've switched the selinux mode management to ansible as part of the
deploy-steps and it's always included now so the service is not
necessary.
Change-Id: I562053ba6767bd9ab7af3cf06b93906568bec5cd
Installing and configuring tmpwatch allows to get rid of some
ugly things in logrotate configuration. As the container has no
network access anymore, we have to install the tool on the host
directly - this isn't that bad.
In order to avoid issues with logrotate manage logs, we explicitely
exclude patterns manage in the specific logorate configuration.
Also, always in order to avoid issues and ensure logrotate does its
own cleanup, we clean files one day later.
Change-Id: Ic666388d9ba7556e7b68ab2fc1082957a9e26552
We stopped managing this service with the switch containers. This change
starts the removal and deprecated the TripleO management of the service.
Change-Id: Idc35bdfad126f21280444ebffaa5017e73ba8368
Change https://review.openstack.org/614457 added these
networks because of the defaults in ServiceNetMap. With
changes related to LP Bug #1809313 these are no longer
required, as the ServiceNetMap fall's back to ctlplane
when networks are not defined or disabled in networks
data.
Related-Bug: #1809313
Depends-On: I102912851a3b9952daaf7c4d5a34a919f527f805
Change-Id: Ic4f22692f93db4ce0db0f4fbc83eca6b492b28e7
Add timezone service to the undercloud role so that it is properly
configured when we install the undercloud.
Change-Id: I4814cfb52f57d8260cda61adb6ac20609f435846
Depends-On: https://review.openstack.org/#/c/628015/
Closes-Bug: #1784068
When using neutron routed networks we need to specify
either the subnet or a ip address in the fixed-ips-request
when creating neutron ports.
a) For the Vip's:
Adds VipSubnetMap and VipSubnetMapDefaults parameters in
service_net_map.yaml. The two maps are merged, so that the
operator can override the subnet where VIP port should be
hosted. For example:
parameter_defaults:
VipSubnetMap:
ctlplane: ctlplane-leaf1
InternalApi: internal_api_leaf1
Storage: storage_leaf1
redis: internal_api_leaf1
b) For overcloud node ports:
Enrich 'networks' in roles defenition to include both
network and subnet data. Changes the list to a map
instead of a list of strings. New schema:
- name: <role_name>
networks:
<network_name>
subnet: <subnet_name>
For backward compatibility a conditional is used to check
if the data is a map or not. In either case the internal
list of role networks is created as '_role_networks' in
the jinja2 templates.
When the data is a map, and the map contains the 'subnet'
key the subnet specified in roles_data.yaml is used as
the subnet in the fixed-ips-reqest when ports are created.
If subnet is not set (or role.networks is not a map) the
default will be {{network.name_lower}}_subnet.
Also, since the fixed_ips request passed to Vip ports are no
longer [] by default, the conditinal has been updated to
test for 'ip_address' entries in the request.
Partial: blueprint tripleo-routed-networks-templates
Depends-On: I773a38fd903fe287132151a4d178326a46890969
Change-Id: I77edc82723d00bfece6752b5dd2c79137db93443
Ghanshyam Mann
yatinkarel