aboutsummaryrefslogtreecommitdiffstats
path: root/puppet/services/README.rst
AgeCommit message (Collapse)AuthorFilesLines
2017-02-28Put service stop at step1 and quiesce at step2.Sofer Athlan-Guyot1-3/+16
In the previous release[1], the services were stopped before the pacemaker services, so that they get a chance to send last message to the database/rabbitmq queue: Let's do the upgrade in the same order. [1] https://github.com/openstack/tripleo-heat-templates/blob/stable/newton/extraconfig/tasks/major_upgrade_controller_pacemaker_2.sh#L13-L71 Change-Id: I1c4045e8b9167396c9dfa4da99973102f1af1218
2017-02-24Upgrade nova-api/scheduler/conductor packages at step3 not step2.Sofer Athlan-Guyot1-1/+3
The nova-api, nova-scheduler nova-conductor packages are updated during step2. The package upgrade trigger a restart of the service which fails and is constantly retried by systemd: Feb 24 12:34:24 centos-7-2-node-rax-iad-7463943-440549 systemd[1]: Failed to start OpenStack Nova Scheduler Server. Feb 24 12:34:24 centos-7-2-node-rax-iad-7463943-440549 systemd[1]: Unit openstack-nova-scheduler.service entered failed state. Feb 24 12:34:24 centos-7-2-node-rax-iad-7463943-440549 systemd[1]: openstack-nova-scheduler.service failed. Feb 24 12:34:24 centos-7-2-node-rax-iad-7463943-440549 systemd[1]: openstack-nova-scheduler.service holdoff time over, scheduling restart. We eventually reach timeout. We use https://github.com/openstack/tripleo-heat-templates/blob/master/puppet/services/tripleo-packages.yaml#L44-L46 to upgrade existing packages. Add a note to the README.rst to make people aware of the general upgrade done at step3 and limit its usage to new package for individual service. Change-Id: I13b51bcfe0c98034944613f7e1c3f0168cd4de76 Closes-Bug: #1667728
2017-02-21Improve the README for the _setting keysMichele Baldessari1-2/+15
It is not entirely clear to someone writing their own templates how to distribute hiera keys to different roles. Let's clear this up with a more extensive description. Change-Id: I02224389c2de90bc5534bce764e5e9d3bb23538f
2017-02-03Reduce number of steps for upgradesSteven Hardy1-7/+11
We don't need all the steps currently enabled for either batched or concurrent updates, so decrease them. In future we can perhaps introspect the task tags during plan creation and set these dynamically. Change-Id: I0358886a332dfbecd03bc4a67086b08d25756c22 Partially-Implements: blueprint overcloud-upgrades-per-service
2017-01-25Add support for batched upgrades to composable upgradesSteven Hardy1-0/+22
Some services (e.g ceph mon) require upgrading in batches (the old upgrade architecture did the ceph mon upgrade one controller at a time). This interface enables doing the same, and over time we can probably move more services into this interface (e.g when services support rolling upgrades) to reduce downtime. Change-Id: If581f301a5493ef33ac1386bdc22f9fca4f2544e Partially-Implements: blueprint overcloud-upgrades-per-service
2016-12-22Add hook to generate metadata from service profilesJuan Antonio Osorio Robles1-0/+14
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
2016-12-01Initial support for composable upgrades with Heat+AnsibleSteven Hardy1-2/+28
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
2016-11-25Fix puppet/services/README.rst step descriptionSteven Hardy1-6/+0
We removed Step 6 in Iae33149e4a03cd64c5831e689be8189ad0cf034b but forgot to update the README. Similarly we made all roles use the same steps in Ia2ea559e8eeb64763908f75705e3728ee90b5744 so the comment is no longer true. Change-Id: If5482ebd22a2547ed2165199992840a0dcacb04c
2016-08-26Add global_config_settings to services' outputGiulio Fidente1-0/+2
The new global_config_settings output is meant to contain additional hieradata distributed by the services to all role types. Change-Id: I1beff8f7b12a4178e6081de6134cd8e67794d710
2016-05-31Configure ObjectStorage services via resource chainsSteven Hardy1-0/+4
Similar to the https://review.openstack.org/#/c/259568 which added support for the composable services StepConfig and ServiceConfigSettings parameters so that the Controller role supports composable services, this adds those interfaces for the ObjectStorage role. Note that at this time the ObjectStorage post config only supports steps 2, 3 and 4, not all those in services/README.rst Partially-Implements: blueprint composable-services-within-roles Change-Id: I22ffaa68a6ccd4be29d51674871268179bcddcbc
2016-03-31Configure ControllerServices via resource chainsDan Prince1-0/+50
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