1 TripleO with Deployed Servers
2 =============================
4 The deployed-server set of templates can be used to deploy TripleO via
5 tripleo-heat-templates to servers that are already installed with a base
8 When OS::TripleO::Server is mapped to the deployed-server.yaml template via the
9 provided deployed-server-environment.yaml resource registry, Nova and Ironic
10 are not used to create any server instances. Heat continues to create the
11 SoftwareDeployment resources, and they are made available to the already
12 deployed and running servers.
16 To use these templates pass the included environment file to the deployment
19 -e deployed-server/deployed-server-environment.yaml
21 Deployed Server configuration
22 -----------------------------
23 It is currently assumed that the deployed servers being used have the required
24 set of software and packages already installed on them. These exact
25 requirements must match how such a server would look if it were deployed the
26 standard way via Ironic using the TripleO overcloud-full image.
28 An easy way to help get this setup for development is to use an overcloud-full
29 image from an already existing TripleO setup. Create the vm's for the already
30 deployed server, and use the overcloud-full image as their disk.
32 Each server must have a fqdn set that resolves to an IP address on a routable
33 network (e.g., the hostname should not resolve to 127.0.0.1). The hostname
34 will be detected on each server via the hostnamectl --static command.
36 Each server also must have a route to the configured IP address on the
37 undercloud where the OpenStack services are listening. This is the value for
38 local_ip in the undercloud.conf.
40 It's recommended that each server have at least 2 nic's. One used for external
41 management such as ssh, and one used for the OpenStack deployment itself. Since
42 the overcloud deployment will reconfigure networking on the configured nic to
43 be used by OpenStack, the external management nic is needed as a fallback so
44 that all connectivity is not lost in case of a configuration error. Be sure to
45 use correct nic config templates as needed, since the nodes will not receive
46 dhcp from the undercloud neutron-dhcp-agent service.
48 For example, the net-config-static-bridge.yaml template could be used for
49 controllers, and the net-config-static.yaml template could be used for computes
53 OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/deployed-server/tripleo-heat-templates/net-config-static-bridge.yaml
54 OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/deployed-server/tripleo-heat-templates/net-config-static.yaml
56 In a setup where the first nic on the servers is used for external management,
57 set the nic's to be used for OpenStack to nic2:
60 NeutronPublicInterface: nic2
61 HypervisorNeutronPublicInterface: nic2
63 The above nic config templates also require a route to the ctlplane network to
64 be defined. Define the needed parameters as necessary for your environment, for
68 ControlPlaneDefaultRoute: 192.168.122.130
69 ControlPlaneSubnetCidr: "24"
70 EC2MetadataIp: "192.0.2.1"
72 In this example, 192.168.122.130 is the external management IP of an
73 undercloud, thus it is the default route for the configured local_ip value of
79 os-collect-config on each deployed server must be manually configured to poll
80 the Heat API for the available SoftwareDeployments. An example configuration
81 for /etc/os-collect-config.conf looks like:
85 command=os-refresh-config
88 # you can get these values from stackrc on the undercloud
89 user_id=<a user that can connect to heat> # note this must be the ID, not the username
91 auth_url=<keystone url>
92 project_id=<project_id> # note, this must be the ID, not project name
94 resource_name=<resource_name>
96 Note that the stack_id value is the id of the nested stack containing the
97 resource (identified by resource_name) implemented by the deployed-server.yaml
100 Once the configuration for os-collect-config has been defined, the service
101 needs to be restarted. Once restarted, it will start polling Heat and applying
102 the SoftwareDeployments.
104 A sample script at deployed-server/scripts/get-occ-config.sh is included that
105 will automatically generate the os-collect-config configuration needed on each
106 server, ssh to each server, copy the configuration, and restart the
107 os-collect-config service.
110 The get-occ-config.sh script is not intended for production use, as it
111 copies admin credentials to each of the deployed nodes.
113 The script can only be used once the stack id's of the nested deployed-server
114 stacks have been created via Heat. This usually only takes a couple of minutes
115 once the deployment command has been started. Once the following output is seen
116 from the deployment command, the script should be ready to run:
118 [Controller]: CREATE_IN_PROGRESS state changed
119 [NovaCompute]: CREATE_IN_PROGRESS state changed
121 The user running the script must be able to ssh as root to each server. Define
122 the hostnames of the deployed servers you intend to use for each role type::
124 export controller_hosts="controller0 controller1 controller2"
125 export compute_hosts="compute0"
127 Then run the script on the undercloud with a stackrc file sourced, and
128 the script will copy the needed os-collect-config.conf configuration to each
129 server and restart the os-collect-config service.