summaryrefslogtreecommitdiffstats
path: root/overcloud-resource-registry-puppet.yaml
AgeCommit message (Collapse)AuthorFilesLines
2016-04-21composable glance servicesDan Prince1-0/+2
Adds new puppet and puppet pacemaker specific services for Glance API and Glance Registry. The Pacemaker templates extend the default glance services and swap in the pacemaker specific puppet-tripleo profile instead. In the case of pacemaker glance-registry there is no separate puppet manifest so only the configuration parameters are maintained there. (Due to the way the pacemaker glance constraints are written the pacemaker varients of this service can't be split out...) Depends-On: Ifc388f7058ccfff2818f531bcbc00c7179874bbc Change-Id: I00a8c916129af43cda225754eb10370289bb4b41
2016-04-11Merge "composable keystone services"Jenkins1-0/+1
2016-04-11Merge "Replace extraconfig/tasks/noop.yaml w/ Heat::None"Jenkins1-3/+3
2016-04-09composable keystone servicesDan Prince1-0/+1
Adds new puppet and puppet pacemaker specific services for Keystone. The puppet manifests for keystone now live in puppet-tripleo. Hiera settings are driven by the nested stack heat templates and used to control puppet-keystone and puppet-tripleo directly. The Pacemaker template extends the default keystone service and swaps in the pacemaker specific puppet-tripleo profile instead. Change-Id: I8b30438a27e9d5ec4e7d335e0bd1a931a20b03a2 Depends-On: I2faf5a78db802549053ec41678bf83bf28108189
2016-04-08Replace extraconfig/tasks/noop.yaml w/ Heat::NoneDan Prince1-3/+3
Removes the old noop nested stack template for extraconfig tasks and instead uses OS::Heat::None. This should avoid a few extra resource checks on create and update. Change-Id: I5a42fc78ece2553e86385236e214aa1e3c91cd85
2016-04-08Remove network/noop.yaml, use OS::Heat::NoneDan Prince1-7/+6
Removes the old noop nested stack template for networks and instead uses OS::Heat::None instead. This should avoid a few extra resource checks on create and update. Change-Id: Ia3d7f62dbda2705ffc3d9edcddebcd3ece3cc9d2
2016-03-31Configure ControllerServices via resource chainsDan Prince1-0/+3
This patch wires in a new for Mitaka Heat feature that allows us to dynamically include a set of nested stacks representing individual services via a Heat resource chain. Follow on patches will use this interface to decompose the controller role into isolated services. Co-Authored-By: Steve Hardy <shardy@redhat.com> Depends-On: If510abe260ea7852dfe2d1f7f92b529979483068 Change-Id: I84c97a76159704c2d6c963bc4b26e365764b1366
2016-02-25Merge "Introduce update/upgrade workflow"Jenkins1-0/+1
2016-02-24Generate the endpoint map staticallyZane Bitter1-1/+0
A stack is an extremely heavyweight abstraction in Heat. Particularly in TripleO, every stack includes a copy of all the template and environment data for all of the stacks in the tree, all of which must be stored anew in the database. The EndpointMap abstraction created no fewer than 30 nested stacks, none of which contained any resources but which existed purely for the purpose of abstracting out some intrinsic functions used to calculate the endpoint URLs for the various services. This likely adds several GB to the memory requirements of the undercloud, and can cause things to slow to a crawl since all 30 nested stacks need to be queried whenever we need data from any one of them. This change eliminates the nested stacks and instead generates the endpoint map statically. This can be done offline in less than 250ms, allows the input data to be expressed in an even more human-readable form, and reduces the runtime overhead of the endpoints map by a factor of 31, all with no loss of functionality, compatibility or flexibility. Since we don't run a setup script to generate the tarball, the endpoint_map.yaml output is checked in to source control. The build script offers a --check option that can be used to make sure that the output file is up-to-date with the input data. Change-Id: I2df8f5569d81c1bde417ff5b12b06b7f1e19c336
2016-02-23Introduce update/upgrade workflowJiri Stransky1-0/+1
Change-Id: I7226070aa87416e79f25625647f8e3076c9e2c9a
2016-02-15Merge "Switch to POLL_TEMP_URL for config transport"Jenkins1-0/+1
2015-12-18Add all isolated networks to all nodes.Dan Sneddon1-0/+9
This change allows every overcloud node to optionally participate in any of the isolated networks. The optional networks are not enabled by default, but allow additional flexibility. Since the new networks are not enabled by default, the standared deployment is unchanged. This change was originally requested for OpenDaylight support. There are several use cases for using non-standard networks. For instance, one example might be adding the Internal API network to the Ceph nodes, in order to use that network for administrative functions. Another example would be adding the Storage Management network to the compute nodes, in order to use it for backup. Without this change, any deviation from the standard set of roles that use a network is a custom change to the Heat templates, which makes upgrades much more difficult. Change-Id: Ia386c964aa0ef79e457821d8d96ebb8ac2847231
2015-12-18Add Management Network For System Administration.Dan Sneddon1-0/+6
This change adds a system management network to all overcloud nodes. The purpose of this network is for system administration, for access to infrastructure services like DNS or NTP, or for monitoring. This allows the management network to be placed on a bond for redundancy, or for the system management network to be an out-of-band network with no routing in or out. The management network might also be configured as a default route instead of the provisioning 'ctlplane' network. This change does not enable the management network by default. An environment file named network-management.yaml may be included to enable the network and ports for each role. The included NIC config templates have been updated with a block that may be uncommented when the management network is enabled. This change also contains some minor cleanup to the NIC templates, particularly the multiple nic templates. Change-Id: I0813a13f60a4f797be04b34258a2cffa9ea7e84f
2015-12-18Merge "Allow for usage of pre-allocated IPs for the controller nodes"Jenkins1-3/+7
2015-12-15Allow for usage of pre-allocated IPs for the controller nodesGiulio Fidente1-3/+7
This change adds a new *_from_pool.yaml meant to return an IP from a list instead of allocating a Neutron port, useful to pick an IP from a pre-defined list and making it possible to configure, for example an external balancer in advance (or dns), with the future IPs of the controller nodes. The list of IPs is provided via parameter_defaults (in the ControllerIPs struct) using ControllerIPs param. Also some additional VipPort types are created for the *VirtualIP resources. The VIPs were previously created using the same port resource used by the nodes, but when deploying with an external balancer we want the VIP resource to be nooped instead. Change-Id: Id3d4f12235501ae77200430a2dc022f378dce336
2015-12-14Pacemaker maintenance mode for the duration of Puppet run on updateSteven Hardy1-0/+4
This enables pacemaker maintenantce mode when running Puppet on stack update. Puppet can try to restart some overcloud services, which pacemaker tries to prevent, and this can result in a failed Puppet run. At the end of the puppet run, certain pacemaker resources are restarted in an additional SoftwareDeployment to make sure that any config changes have been fully applied. This is only done on stack updates (when UpdateIdentifier is set to something), because the assumption is that on stack create services already come up with the correct config. (Change I9556085424fa3008d7f596578b58e7c33a336f75 has been squashed into this one.) Change-Id: I4d40358c511fc1f95b78a859e943082aaea17899 Co-Authored-By: Jiri Stransky <jistr@redhat.com> Co-Authored-By: James Slagle <jslagle@redhat.com>
2015-12-12Switch to POLL_TEMP_URL for config transportSteve Baker1-0/+1
This will allow the following: - reduced load on heat for large overclouds - a shorter os-collect-config poll interval without increasing load on the undercloud - the ability to add config deployments outside the stack, allowing workflow tools like mistral, ansible or tripleoclient to directly deploy custom scripts and config to overcloud nodes Change-Id: If028c9d7764210363135c3e7cc16ae1fb897a77c Depends-On: I9c475f0c489c67db5895924050186228403f2773
2015-11-26Merge "Add net_vip_map_external to be used for an external balancer"Jenkins1-0/+1
2015-11-25Enable trust anchor injectionJuan Antonio Osorio Robles1-0/+1
This commit enables the injection of a trust anchor or root certificate into every node in the overcloud. This is in case that the TLS certificates for the controllers are signed with a self-signed CA or if the deployer would like to inject a relevant root certificate for other purposes. In this case the other nodes might need to have the root certificate in their trust chain in order to do proper validation Change-Id: Ia45180fe0bb979cf12d19f039dbfd22e26fb4856
2015-11-24Add net_vip_map_external to be used for an external balancerDan Prince1-0/+1
Changes VipMap into a new NetVipMap resource which defaults to being the same as the 'old' VipMap. An environment file can be used to map NetVipMap instead to the net_vip_map_external.yaml which allows for passing in explicit Virtual IP addresses. It also ensures that references to the Virtual IPs are gathered from the VipMap resource and allows for an empty ControlPlaneIP parameter in the neutron port templates where it can be. Co-Authored-By: Giulio Fidente <gfidente@redhat.com> Change-Id: Ifad32e18f12b9997e3f89e4afe3ebc4c30e14a86
2015-11-23Inject TLS certificate and keys for the OvercloudJuan Antonio Osorio Robles1-0/+1
This is a first implementation of adding TLS termination to the load balancer in the controllers. The implementation was made so that the appropriate certificate/private key in PEM format is copied to the appropriate controller(s) via a software deployment resource. And the path is then referenced on the HAProxy configuration, but this part was left commented out because we need to be able to configure the keystone endpoints in order for this to work properly. Change-Id: I0ba8e38d75a0c628d8132a66dc25a30fc5183c79
2015-11-11Refacter Endpoints into EndpointMapMark Chappell1-0/+4
Because many of the service endpoints URLs use the same patterns for generating the URLs it makes sense to use the same templates to reduce the copy and paste. In the process also adds support for explicitly specifying hostnames for use in the endpoints. Note: DNS must be pre-configured. The Heat templates do not directly configure DNS. Change-Id: Ie3270909beca3d63f2d7e4bcb04c559380ddc54d Co-Authored-By: Juan Antonio Osorio Robles <jaosorior@redhat.com>
2015-10-01Wire in NodeExtraConfig interfaceSteven Hardy1-0/+2
It's become apparent that some actions are required in the pre-deploy phase for all nodes, for example applying common hieradata overrides, or also as a place to hook in logic which must happen for all nodes prior to their removal on scale down (such as unregistration from a satellite server, which currently doesn't work via the *NodesPostDeployment for scale-down usage). So, add a new interface that enables ExtraConfig per-node (inside the scaled unit, vs AllNodes which is used for the cluster-wide config outside of the ResourceGroup) Change-Id: Ic865908e97483753e58bc18e360ebe50557ab93c
2015-09-25Add CephStorageExtraConfigPre resourceGiulio Fidente1-0/+1
This change adds a CephStorageExtraConfigPre which can be used to distribute hooks for the CephStorage nodes. Change-Id: Id0023d8ffddb3ee5e855d5dcc32c76bc41ce4c63
2015-09-22Rename -puppet.yaml templates.Dan Prince1-8/+8
Updates the /puppet directory templates so that we drop the '-puppet' from the filenames. This is redundant because we already have puppet in the directory name and fixes inconsistencies where we aren't using -puppet in all the files within the puppet directory. Depends-On: I71cb07b2f5305aaf9c43ab175cca976e844b8175 Change-Id: I70d6e048a566666f5d6e5c2407f8a6b4fd9f6f87
2015-09-17Add "AllNodes" ExtraConfig interfaceSteven Hardy1-0/+6
Adds hook to enable additional "AllNodes" config to be performed prior to applying puppet - this is useful when you need to build configuration data which requires knowledge of all nodes in a cluster, or of the entire deployment. As an example, there is a sample config template which collects the hostname and mac addresses for all nodes in the deployment then writes the data to all Controller nodes. Something similar to this may be required to enable creation of the nexus_config in https://review.openstack.org/#/c/198754/ There's also another, simpler, example which shows how you could share the output of an OS::Heat::RandomString between nodes. Change-Id: I8342a238f50142d8c7426f2b96f4ef1635775509
2015-09-17Merge "network validation to ping test each interface"Jenkins1-0/+3
2015-09-08Merge "Add NodeAdminUserData interface for "heat-admin" user"Jenkins1-0/+4
2015-09-05Allow 'ctlplane' to be used within Net IP MapsDan Prince1-0/+1
When using network isolation you might want to selective move one of the services back to the default ctlplane network by simply using the ServiceNetMap parameter. This patch adds ctlplane to the output parameters for both the net_ip_map and net_ip_list_map nested stacks so that this is possible. As part of this patch we also split out the NetIpSubnetMap into its own unique nested stack so that the Heat input parameters for this stack are more clearly named. Change-Id: Iaa2dcaebeac896404e87ec0c635688b2a59a9e0f
2015-09-03Add NodeAdminUserData interface for "heat-admin" userSteven Hardy1-0/+4
Reinstates the heat-admin user via template user-data, which replaces the previous boothook injected user provided by the (deprecated now removed) heat instance_user option. This has some advantages over the heat.conf option, e.g it allows for much easier customzation of the user configuration (additional SSH keys, adding groups etc), and also in future if we support deploying more than one overcloud you could specify a different user per deployment. Co-Authored-By: Dan Prince <dprince@redhat.com> Change-Id: I2235b9690c01542d8a28ec1c1a4607de751aea29 Closes-Bug: #1229849
2015-08-03Wire in Compute pre-deployment extraconfigShiva Prasad Rao1-0/+1
This commit provides a way to configure some additional hieradata for compute nodes. This is similar to the earlier added infra for supporting Controller pre-deployment extraconfig. Change-Id: I02dda0685c7df9013693db5eeacb2f47745d05b5
2015-07-24network validation to ping test each interfaceDan Prince1-0/+3
This patches wires in a new "all nodes" validation resource that can be used to add validations that occur early on during the deployment process. This occurs after the nodes have been brought online and the initial networks have been configured but before any "post" (puppet, etc.) sort of configuration has been executed. A initial validation script has been added to ping test network IPs on each network. When using network isolation this will ensure network connectivity (vlans, etc) are working on each node and if not the heat stack will fail early, allowing time to fix the network connections and retry the stack creation via an update. Change-Id: I63cf95b27e8ad2aed48718cf84df5f324780e597 Co-Authored-By: Ian Main <imain@redhat.com> Co-Authored-By: Ryan Hallisey <rhallise@redhat.com>
2015-07-23Set default external port to noop for puppetDan Prince1-1/+1
In 9b89dd20162d962480d3cb84161ed6bfd4fa9de8 we had a regression where the default "external" traffic port was set to a VIP when using puppet. We should not ever specify a VIP to be used for the actual machine IPs (VIPs are only guaranteed to work once the load balancer is running). Also, This doesn't match the non-puppet case. Change-Id: Icd179a70001f2bd7a97e31c7f6445001330674cd
2015-07-22Convert PublicVirtualIP to new port creation methodDan Sneddon1-1/+1
This change brings PublicVirtualIP in line with the rest of the VIPs in how it is created. This allows the network where PublicVirtualIP is instantiated to be on cltplane when network isolation is not used, and on the external network when network isolation is used. This change removes the PublicVirtualNetwork parameter, since it is no longer used. In order to continue to support the PublicVirtualFixedIPs parameter, which is used to provide a specific IP for the PublicVirtualIP, the FixedIP parameter was added to cltplane_vip.yaml, vip.yaml, and noop.yaml. The value of PublicVirtualIP is passed to FixedIP in the VIP templates. This change also moves the default network for keystone public api to the external net (which will fallback to ctlplane if network isolation isn't used). Change-Id: I3f5d35cbe55d3a148e95cf49dfbaad4874df960b
2015-07-06Wire in Controller pre-deployment extraconfigSteven Hardy1-4/+7
The recently added cinder-netapp extraconfig contains some additional hieradata which needs to be applied during the initial pre-deployment phase, e.g in controller-puppet.yaml (before the manifests are applied) so wire in a new OS::TripleO::ControllerExtraConfigPre provider resource which allows passing in a nested stack (empty by default) which contains any required "pre deployment" extraconfig, such as applying this hieradata. Some changes were required to the cinder-netapp extraconfig and environment such that now the hieradata is actually applied, and the parameter_defaults specified will be correctly mapped into the StructuredDeployment. Change-Id: I8838a71db9447466cc84283b0b257bdb70353ffd
2015-06-17Merge "Remove Redis VirtualIP from params and build it from Neutron::Port"Jenkins1-0/+3
2015-06-13Remove Redis VirtualIP from params and build it from Neutron::PortGiulio Fidente1-0/+3
The redis_vip should come from a Neutron Port as its cidr depends on the Neutron Network configuration. This change adds 2 new files and modifies 1 in the network/ports directory: - noop.yaml - Passes through the ctlplane Controller IP (modified) - ctlplane_vip.yaml - Creates a new VIP on the control plane - vip.yaml - Creates a VIP on the named network (for isolated nets) Also, changes to overcloud-without-mergepy.yaml create the Redis Virtual IP. The standard resource registry was modified to use noop.yaml for the new Redis VIP. The Puppet resource registry was modified to use ctlplane_vip.yaml by default, but can be made to use vip.yaml when network isolation is used by using an environment file. vip.yaml will place the VIP according to the ServiceNetMap, which can also be overridden. We use this new VIP port definition to assign a VIP to Redis, but follow-up patches will assign VIPs to the rest of the services in a similar fashion. Co-Authored-By: Dan Sneddon <dsneddon@redhat.com> Change-Id: I2cb44ea7a057c4064d0e1999702623618ee3390c
2015-06-11Remove external bridge from Compute nodesDan Sneddon1-1/+1
This change modifies overcloud-resource-registry-puppet.yaml to use net-config-noop.yaml as the default os-net-config template for compute nodes. The current default of net-config-bridge.yaml will set up a br-ex on the compute nodes. Since we are not using DVR that is not needed. Change-Id: I4e149a4f5a6d19e94e8c0245f52677f92f22d3ec
2015-06-08Merge "Enable NetApp Backends in Cinder"Jenkins1-0/+3
2015-06-08Config & deployments to update overcloud packagesSteve Baker1-0/+1
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
2015-06-05Enable NetApp Backends in CinderRyan Hefner1-0/+3
Enables support for configuring Cinder with a NetApp backend. This change adds all relevant parameters for: - Clustered Data ONTAP (NFS, iSCSI, FC) - Data ONTAP 7-Mode (NFS, iSCSI, FC) - E-Series (iSCSI) Change-Id: If6c6e511ef2d26c4794e3b37c61e5318485ff4db
2015-06-03Add virtual IPs for split out networksDan Prince1-0/+2
This patch adds VIPs for the internal_api, storage, and storage management networks. For puppet these are persisted into a local vip-config hieradata file which is then used by puppet-tripleo's loadbalancer module to apply per-service VIP settings. Change-Id: I909c3bdc9d17a8e15351f4797287769e3f76c849
2015-06-03Make all-nodes Ip networks configurableDan Prince1-0/+1
This patch adds a new NetIpListMap abstraction which we can use to make the all-nodes-config IP list network assignments configurable. Ip address lists for all overcloud services which require IPs were added to all-nodes-config so that puppet manifests can be directly supplied the correct network list for each service. Change-Id: I209f2b4f97a4bb78648c54813dad8615770bcf1a
2015-06-03Wire ServiceNetMap as a top level parameterDan Prince1-24/+0
This patch makes ServiceNetMap a top level parameter. This is helpful to tools like Tuskar which don't support Heat environments that contain both a resource_registry and default_parameters. ServiceNetMap will in fact be utilized at the top level in some of the VIP related patches that follow. Change-Id: I375063dacf5f3fc68e6df93e11c3e88f48aa3c3a
2015-05-28Map Mysql to isolated networksDan Prince1-0/+1
This change adds parameters to specify which networks the MySQL service will use. If the internal_api network exists the MySQL service will bind to the IP address on that network, otherwise the services will default to the IP on the Undercloud 'ctlplane' network. This patch also drop the old 'controller_host' variable from the puppet controller template since it is no longer in use. Change-Id: I4fba2c957f7db47e916bc269fb4bd32ccc99bd4c
2015-05-27Map Horizon, Redis, Rabbit, memcached to isolated netsDan Sneddon1-0/+4
This change adds parameters to select the networks for Horizon, Redis, Rabbit MQ, and memcached services. Horizon is often used for administration from outside the cloud, so if the external network exists, Horizon will bind to that IP, otherwise it will default to the Undercloud 'ctlplane' network. Redis, Rabbit MQ, and memcached will bind to IPs on the internal_api network if it exists, else they will default to the 'ctlplane' network as well. Any of these network assignments can be overridden with an environment file. Change-Id: Ie0aa46b4a3c00d3826866796b4ec3b14f71f987c
2015-05-27Map Swift services to isolated networksDan Sneddon1-0/+2
This change adds paramters to specify which networks the Swift API services will use. If the storage network exists, it will be used for the Swift API, otherwise the Undercloud 'ctlplane' network will be used. If the storage_mgmt network exists, it will be used for the back-end storage services, otherwise the 'ctlplane' will be used by default. Change-Id: I1d5e966a16416c52935c22efe2d4783cd2192c32
2015-05-27Map Nova services to isolated networksDan Sneddon1-0/+2
This change adds parameters to specify which networks the Nova API and metadata services will use. If the internal_api network exists, it will be used for the bind IP for Nova API and metadata servers, otherwise the Undercloud 'ctlplane' IP will be used by default. Change-Id: Ie420274c7fba80abf9cf2b599431acc47e28fc7a
2015-05-27Map Heat services to isolated networksDan Sneddon1-0/+3
This change adds parameters to specify which networks the Heat services will use. If the internal_api network exists, the Heat API, Heat Cloud Formations, and Heat Cloudwatch services will bind to the IP address on that network, otherwise the services will default to the IP on the Undercloud 'ctlplane' network. Change-Id: I5febe1b9071600b43fa76c6cf415db83cad472ab
2015-05-26Map Neutron services to isolated networksDan Sneddon1-0/+1
This change adds parameters to specify which network the Neutron API should use. If the internal_api network exists, Neutron will bind to the IP on that network, otherwise the Undercloud 'ctlplane' network will be used. The network that the Neutron API is bound to can be overridden in an environment file. Change-Id: I11bcebba3a22e8850095250a2ddfaf972339476b