X-Git-Url: https://gerrit.opnfv.org/gerrit/gitweb?a=blobdiff_plain;f=puppet%2Fservices%2FREADME.rst;h=6e4e9c1d66f16e370e582eaa61896bf6866905c9;hb=1ed5fbf6184fa5ffe35cee6f81128b8999458ac6;hp=3accff3687331fee47343d507af55be34f9aefcb;hpb=9f595c80121158bf12f6827233bd62c32a8d8464;p=apex-tripleo-heat-templates.git diff --git a/puppet/services/README.rst b/puppet/services/README.rst index 3accff36..6e4e9c1d 100644 --- a/puppet/services/README.rst +++ b/puppet/services/README.rst @@ -22,8 +22,8 @@ Config Settings Each service may define a config_settings output variable which returns Hiera settings to be configured. -Steps ------ +Deployment Steps +---------------- Each service may define an output variable which returns a puppet manifest snippet that will run at each of the following steps. Earlier manifests @@ -48,3 +48,43 @@ are re-asserted when applying latter ones. 4) General OpenStack Services 5) Service activation (Pacemaker) + +Upgrade Steps +------------- + +Each service template may optionally define a `upgrade_tasks` key, which is a +list of ansible tasks to be performed during the upgrade process. + +Similar to the step_config, we allow a series of steps for the per-service +upgrade sequence, defined as ansible tasks with a tag e.g "step1" for the first +step, "step2" for the second, etc. + + Steps/tages correlate to the following: + + 1) Quiesce the control-plane, e.g disable LoadBalancer, stop pacemaker cluster + + 2) Stop all control-plane services, ready for upgrade + + 3) Perform a package update, (either specific packages or the whole system) + + 4) Start services needed for migration tasks (e.g DB) + + 5) Perform any migration tasks, e.g DB sync commands + + 6) Start control-plane services + + 7) Any additional online migration tasks (e.g data migrations) + +Nova Server Metadata Settings +----------------------------- + +One can use the hook of type `OS::TripleO::ServiceServerMetadataHook` to pass +entries to the nova instances' metadata. It is, however, disabled by default. +In order to overwrite it one needs to define it in the resource registry. An +implementation of this hook needs to conform to the following: + +* It needs to define an input called `RoleData` of json type. This gets as + input the contents of the `role_data` for each role's ServiceChain. + +* This needs to define an output called `metadata` which will be given to the + Nova Server resource as the instance's metadata.