tripleo-heat-templates/deployed-server
Harald Jensås f35479563a Set tags on all OS::Neutron::Port resources
This combines several changes that added tags to port
resources into one commit.

Set up tag hints on all OS::Neutron::Port resources.
The network-data-v2 work uses tags on neutron resources
to find existing resources so that we update instead
of create. Also for generating environment files info
in the neutron tag field is utilized.

Conflicts:
  network/ports/deployed_port.j2

Related: blueprint network-data-v2-ports
(cherry picked from commit 28f2a70912)
(cherry picked from commit 6d39c90a22)
(cherry picked from commit cea78ad4fd)
(cherry picked from commit 73684d0a89)
(cherry picked from commit d3b8515c4f)
(cherry picked from commit b4b2bc5d70)
(cherry picked from commit 659cc55277)
Change-Id: I178ac067e4fd77ddfa0eed963c79603576994433
2021-05-21 09:00:29 +02:00
..
scripts Change enable-ssh-admin.sh script to use playbook 2020-09-25 13:46:10 +05:30
README.rst Make NetworkConfigWithAnsible parameter non-role specific 2020-10-15 19:41:27 +05:30
ctlplane-port.yaml Set tags on all OS::Neutron::Port resources 2021-05-21 09:00:29 +02:00
deployed-neutron-port.yaml Set tags on all OS::Neutron::Port resources 2021-05-21 09:00:29 +02:00
deployed-server-environment-output.yaml Give the OVN DBS service a separate Vip 2019-09-23 13:05:39 +00:00
deployed-server.yaml Set tags on all OS::Neutron::Port resources 2021-05-21 09:00:29 +02:00

README.rst

TripleO with Deployed Servers

The deployed-server set of templates can be used to deploy TripleO via tripleo-heat-templates to servers that are already installed with a base operating system.

When OS::TripleO::Server is mapped to the deployed-server.yaml template via the provided deployed-server-environment.yaml resource registry, Nova and Ironic are not used to create any server instances. Heat continues to create the SoftwareDeployment resources, and they are made available to the already deployed and running servers.

Template Usage

To use these templates pass the included environment file to the deployment command:

-e environments/deployed-server-environment.yaml

Deployed Server configuration

It is currently assumed that the deployed servers being used have the required set of software and packages already installed on them. These exact requirements must match how such a server would look if it were deployed the standard way via Ironic using the TripleO overcloud-full image.

An easy way to help get this setup for development is to use an overcloud-full image from an already existing TripleO setup. Create the vm's for the already deployed server, and use the overcloud-full image as their disk.

Each server must have a fqdn set that resolves to an IP address on a routable network (e.g., the hostname should not resolve to 127.0.0.1). The hostname will be detected on each server via the hostnamectl --static command.

Each server also must have a route to the configured IP address on the undercloud where the OpenStack services are listening. This is the value for local_ip in the undercloud.conf.

It's recommended that each server have at least 2 nic's. One used for external management such as ssh, and one used for the OpenStack deployment itself. Since the overcloud deployment will reconfigure networking on the configured nic to be used by OpenStack, the external management nic is needed as a fallback so that all connectivity is not lost in case of a configuration error. Be sure to use correct nic config templates as needed, since the nodes will not receive dhcp from the undercloud neutron-dhcp-agent service.

For example, the net_config_static_bridge.j2 template could be used for controllers, and the net_config_static.j2 template could be used for computes by specifying:

parameter_defaults:

ControlleNetworkConfigTemplate: 'templates/net_config_static_bridge.j2' ComputeNetworkConfigTemplate: 'templates/net_config_static.j2'

In a setup where the first nic on the servers is used for external management, set the nic's to be used for OpenStack to nic2:

parameter_defaults:

NeutronPublicInterface: nic2 HypervisorNeutronPublicInterface: nic2

The above nic config templates also require a route to the ctlplane network to be defined. Define the needed parameters as necessary for your environment, for example:

parameter_defaults:

ControlPlaneDefaultRoute: 192.168.122.130 ControlPlaneSubnetCidr: "24"

In this example, 192.168.122.130 is the external management IP of an undercloud, thus it is the default route for the configured local_ip value of 192.168.24.1.