29 Commits

Author SHA1 Message Date
Steven Hardy
a0a09d29aa run docker_puppet_tasks on any role
Currently this assumes all tasks will run on the primary controller
but because of composable roles, that may not be the case.

An example is if you deploy keystone on any role other than the
role tagged primary e.g Controller by default, we don't create
any of the users/endpoints because the tasks aren't written to
the role unless keystone actually runs there.

Closes-Bug: #1792613
Change-Id: Ib6efd03584c95ed4ab997f614aa3178b01877b8c
2019-01-31 18:17:56 +00:00
Thomas Herve
ae2ccb5f41 Remove workflow_tasks
I don't think it's used anymore.

Change-Id: I928b53d7388e460da3b26306b9f3c548808d329e
2019-01-24 11:08:53 +01:00
Oliver Walsh
e0e885b8ca Move cellv2 discovery from control plane services to compute services
If compute nodes are deployed without deploying/updating the controllers then
the computes will not have cellv2 mappings as this is run in the controller
deploy steps (nova-api).
This can happen if the controller nodes are blacklisted during a compute scale
out. It's also likely to be an issue going forward if the deployment is staged
(e.g split control plane).

This change moves the cell_v2 discovery logic to the nova-compute/nova-ironic
deploy step.

Closes-bug: 1786961
Change-Id: I12a02f636f31985bc1b71bff5b744d346286a95f
2018-12-20 11:23:06 +05:30
Jill Rouleau
fc30066a35 Add stack output ansible_group_vars
This change adds a stack output to services/common.yaml that acts
as an interface for Ansible group variables.  Ansible vars provided
via this interface will be consumed by config-download and written
under $config-download-dir/group_vars/ where they can be accessed
by ansible commands.

Part of blueprint ansible-tasks-to-role.

Change-Id: Ib70e7dda13b4a3ed30af88906ba42c25cdc93038
2018-10-17 16:44:50 +00:00
Juan Antonio Osorio Robles
cb3c72f37d Remove references to logging_source
This has been unused for a while, and even deprecation was scheduled
(although the patch never merged [1]). So, in order to stop folks
getting confused with this, it's being removed.

[1] https://review.openstack.org/#/c/543871/

Change-Id: Iada64874432146ef311682f26af5990469790ed2
2018-10-08 13:43:47 +03:00
Juan Antonio Osorio Robles
90234f4f2a Remove references to logging_group
This has been unused for a while, and even deprecation was scheduled
(although the patch never merged [1]). So, in order to stop folks
getting confused with this, it's being removed.

[1] https://review.openstack.org/#/c/543871/

Change-Id: Icc6b51044ccc826f5b629eb1abd3342813ed84c0
2018-08-29 13:43:30 +03:00
Jiri Stransky
6364f2286c Update and upgrade tasks for services deployed via external deploy tasks
Composable service templates can now define external_update_tasks and
external_upgrade_tasks. They are meant for update/upgrade logic of
services deployed via external_deploy_tasks. The external update
playbook first executes external_update_tasks and then
external_deploy_tasks, the procedure for upgrades works
analogously. All happens within a single playbook, so variables or
fact overrides exported from the update/upgrade tasks will be
available to the deploy tasks during the update/upgrade procedure.

Partial-Bug: #1783949
Change-Id: Ib2474e8f69711cd6610a78884d5032ffd19ad249
2018-08-02 15:04:15 +02:00
Giulio Fidente
8a8ad26435 Merge values for same key from multiple services
This should merge multiple and different values for the same key
found in different services.

For example, assuming two services defining a key as follows:

  config_settings:
    mykey:
    - val1

  config_settings:
    mykey:
    - val2
    - val3

the content of the key, as seen by ansible or puppet on the nodes,
will be:

  mykey: ['val1','val2','val3']

Change-Id: I190374e36ad1a2b57611a3a9d0a52ceb1a049aff
2018-05-22 18:20:43 +02:00
Carlos Camacho
44ef2a3ec1 Change template names to rocky
The new master branch should point now to rocky.

So, HOT templates should specify that they might contain features
for rocky release [1]

Also, this submission updates the yaml validation to use only latest
heat_version alias. There are cases in which we will need to set
the version for specific templates i.e. mixed versions, so there
is added a variable to assign specific templates to specific heat_version
aliases, avoiding the introductions of error by bulk replacing the
the old version in new releases.

[1]: https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#rocky
Change-Id: Ib17526d9cc453516d99d4659ee5fa51a5aa7fb4b
2018-05-09 08:28:42 +02:00
Jiri Stransky
ae085825e2 Add pre_upgrade_rolling_tasks
The resultin pre_upgrade_rolling_steps_playbook will be executed in a
node-by-node rolling fashion at the beginning of major upgrade
workflow (before upgrade_steps_playbook).

The current intended use case is special handling of L3 agent upgrade
when moving Neutron services into containers. Special care needs to be
taken in this case to preserve L3 connectivity of instances (with
regard to dnsmasq and keepalived sub-processes of L3 agent).

The playbook can be run before the main upgrade like this:

openstack overcloud upgrade run --roles overcloud --playbook pre_upgrade_rolling_steps_playbook.yaml

Partial-Bug: #1738768
Change-Id: Icb830f8500bb80fd15036e88fcd314bf2c54445d
Implements: blueprint major-upgrade-workflow
2018-03-16 12:37:19 +01:00
Lukas Bezdicka
26c55d15cd FFU: Introduce post FFU steps and use them for qeens switch
In last step of FFU we need to swich repos before running upgrade.
We do so by introducing post FFU steps and running the switch in
them. We also update heat agents and os-collect-config on nodes.

Change-Id: I649afc6fa384ae21edc5bc917f8bb586350e5d47
2018-03-15 14:33:19 +01:00
Janki Chhatbar
98faacad44 Minor update steps for ODL
Updating OpenStack (within release) means updating ODL from v1 to v1.1.
This is done by "openstack overcloud update" which collects
update_tasks. ODL needs 2 different steps to achieve this
minor update. These are called Level1 and Level2. L1 is
simple - stop ODL, update, start. This is taken care by paunch
and no separate implementation is needed. L2 has extra steps
which are implemented in update_tasks and post_update_tasks.

Updating ODL within the same major release (1->1.1) consists of either
L1 or L2 steps. These steps are decided from ODLUpdateLevel parameter
specified in environments/services-docker/update-odl.yaml.

Upgrading ODL to the next major release (1.1->2) requires
only the L2 steps. These are implemented as upgrade_tasks and
post_upgrade_tasks in https://review.openstack.org/489201.

Steps involved in level 2 update are
 1. Block OVS instances to connect to ODL
 2. Set ODL upgrade flag to True
 3. Start ODL
 4. Start Neutron re-sync and wait for it to finish
 5. Delete OVS groups and ports
 6. Stop OVS
 7. Unblock OVS ports
 8. Start OVS
 9. Unset ODL upgrade flag

These steps are exactly same as upgrade_tasks.
The logic implemented is:
follow upgrade_tasks; when update_level == 2

Change-Id: Ie532800663dd24313a7350b5583a5080ddb796e7
2018-03-08 17:20:47 +05:30
Lee Yarwood
acb2475e4c ffu: Add fast-forward upgrade outputs to RoleConfig
As outlined in the spec, fast-forward upgrades aim to take an
environment from an initial release of N to a release of N>=2, beyond
that of the traditionally supported N+1 upgrade path provided today by
many OpenStack projects.

For TripleO the first phase of this upgrade will be to move the
environment to the release prior to the target release. This will be
achieved by disabling all OpenStack control plane services and then
preforming the minimum number of steps required to upgrade each service
through each release until finally reaching the target release.

This change introduces the framework for this phase of the fast-forward
upgrades by adding playbooks and task files as outputs to RoleConfig.

- fast_forward_upgrade_playbook.yaml

This is the top level play and acts as the outer loop of the process,
iterating through the required releases as set by the
FastForwardUpgradeReleases parameter for the fast-forward section of the
upgrade. This currently defaults to Ocata and Pike for Queens.

Note that this play is run against the overcloud host group and it is
currently assumed that the inventory used to run this play is provided
by the tripleo-ansible-inventory command.

- fast_forward_upgrade_release_tasks.yaml

This output simply imports the top level prep and bootstrap task files.

- fast_forward_upgrade_prep_tasks.yaml
- fast_forward_upgrade_bootstrap_tasks.yaml

These outputs act as the inner loop for the fast-forward upgrade phase,
iterating over step values while importing their associated role tasks.

As prep tasks are carried out first for each release we loop over step
values starting at 0 and ending at the defined
fast_forward_upgrade_prep_steps_max, currently 3.

Following this we then complete the bootstrap tasks for each release,
looping over steps values starting at
fast_forward_upgrade_prep_steps_max + 1 , currently 4 and ending at
fast_forward_upgrade_steps_max,currently 9.

- fast_forward_upgrade_prep_role_tasks.yaml
- fast_forward_upgrade_bootstrap_role_tasks.yaml

These outputs then finally import the fast_forward_upgrade_tasks files
generated by the FastForwardUpgradeTasks YAQL query for each role. For
prep tasks these are always included when on an Ansible host of a given
role. This differs from bootstrap tasks that are only included for the
first host associated with a given role.

This will result in the following order of task imports with their
associated value of release and step:

fast_forward_upgrade_playbook
\_fast_forward_upgrade_release_tasks
  \_fast_forward_upgrade_prep_tasks              - release=ocata
     \_fast_forward_upgrade_prep_role_tasks      - release=ocata
       \_$roleA/fast_forward_upgrade_tasks       - release=ocata, step=0
       \_$roleB/fast_forward_upgrade_tasks       - release=ocata, step=0
       \_$roleA/fast_forward_upgrade_tasks       - release=ocata, step=1
       \_$roleB/fast_forward_upgrade_tasks       - release=ocata, step=1
       \_$roleA/fast_forward_upgrade_tasks       - release=ocata, step=2
       \_$roleB/fast_forward_upgrade_tasks       - release=ocata, step=2
       \_$roleA/fast_forward_upgrade_tasks       - release=ocata, step=3
       \_$roleB/fast_forward_upgrade_tasks       - release=ocata, step=3
  \_fast_forward_upgrade_bootstrap_tasks         - release=ocata
     \_fast_forward_upgrade_bootstrap_role_tasks - release=ocata
       \_$roleA/fast_forward_upgrade_tasks       - release=ocata, step=4
       \_$roleB/fast_forward_upgrade_tasks       - release=ocata, step=4
       \_$roleA/fast_forward_upgrade_tasks       - release=ocata, step=5
       \_$roleB/fast_forward_upgrade_tasks       - release=ocata, step=5
       \_$roleA/fast_forward_upgrade_tasks       - release=ocata, step=N
       \_$roleB/fast_forward_upgrade_tasks       - release=ocata, step=N
\_fast_forward_upgrade_release_tasks
  \_fast_forward_upgrade_prep_tasks              - release=pike
     \_fast_forward_upgrade_prep_role_tasks      - release=pike
       \_$roleA/fast_forward_upgrade_tasks       - release=pike, step=0
       \_$roleB/fast_forward_upgrade_tasks       - release=pike, step=0
       \_$roleA/fast_forward_upgrade_tasks       - release=pike, step=1
       \_$roleB/fast_forward_upgrade_tasks       - release=pike, step=1
       \_$roleA/fast_forward_upgrade_tasks       - release=pike, step=2
       \_$roleB/fast_forward_upgrade_tasks       - release=pike, step=2
       \_$roleA/fast_forward_upgrade_tasks       - release=pike, step=3
       \_$roleB/fast_forward_upgrade_tasks       - release=pike, step=3
   \_fast_forward_upgrade_bootstrap_tasks        - release=pike
     \_fast_forward_upgrade_bootstrap_role_tasks - release=pike
       \_$roleA/fast_forward_upgrade_tasks       - release=pike, step=4
       \_$roleB/fast_forward_upgrade_tasks       - release=pike, step=4
       \_$roleA/fast_forward_upgrade_tasks       - release=pike, step=5
       \_$roleB/fast_forward_upgrade_tasks       - release=pike, step=5
       \_$roleA/fast_forward_upgrade_tasks       - release=pike, step=N
       \_$roleB/fast_forward_upgrade_tasks       - release=pike, step=N

bp fast-forward-upgrades
Change-Id: Ie2683fd7b81167abe724a7b9245bf85a0a87ad1d
2018-02-09 17:13:31 +01:00
Steven Hardy
bb9fd2c61a Reinstate common overcloud manifest for all roles
This was lost in the translation to ansible, but it's needed to
enable existing interfaces such as hiera includes via *ExtraConfig.

For reference this problem was introduced in:
I674a4d9d2c77d1f6fbdb0996f6c9321848e32662 and this fix only considers
returning the behaviour prior to that patch (for the baremetal puppet
apply), further discussion is required on if/how this could be applied
to the new container architecture.

Change-Id: I0384edb23eed336b95ffe6293fe7d4248447e849
Partial-Bug: #1742663
2018-01-11 18:42:45 +00:00
Steven Hardy
0524c86353 Add deploy_steps_tasks interface
This allows per-step ansible tasks to be run on the nodes when using
the config download mechanism, e.g adding the following to a service
template will create /tmp/testperstep populated for every step.

     deploy_steps_tasks:
        - name: Test something happens each step
          lineinfile:
            path: /tmp/testperstep
            create: true
            line: "{{step}} step happened"

Change-Id: Ic34f5c48736b6340a1cfcea614b05e33e2fce040
2017-12-05 08:47:48 +02:00
Carlos Camacho
927495fe3d Change template names to queens
The new master branch should point now to queens instead of pike.

So, HOT templates should specify that they might contain features
for queens release [1]

[1]: https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#queens

Change-Id: I7654d1c59db0c4508a9d7045f452612d22493004
2017-11-23 10:15:32 +01:00
Steven Hardy
9ce86956ff Add external_post_deploy_tasks interface
This adds another interface like external_deploy_tasks, but instead
of running on each deploy step, the tasks are run after the deploy
is completed, so it's useful for per-service bootstrapping such
as is under development for octavia in:

https://review.openstack.org/#/c/508195
https://review.openstack.org/#/c/515402/

These reviews could potentially be reworked to use this interface,
which would avoid the issue where the configuration needs to happen
after all the openstack services are deployed and configured.

As an example, here is how you could create a temp file post deploy:

    external_post_deploy_tasks:
        - name: Test something happens post-deploy
          copy:
            dest: /tmp/debugpostdeploy
            content: "done"

Change-Id: Iff3190a7d5a238c8647a4ac474821aeda5f2b1f8
2017-11-22 18:39:05 +00:00
Oliver Walsh
61fcfca045 Refactor cellv2 host discovery logic to avoid races
The compute service list is polled until all expected hosts are reported or a
timeout occurs (600s).

Adds a cellv2_discovery flag to puppet services. Used to generate a list of
hosts that should have cellv2 host mappings.

Adds a canonical fqdn and that should match the fqdn reported by a host.

Adds the ability to upload a config script for docker config instead of using
complex bash on-liners.

Closes-bug: 1720821
Change-Id: I33e2f296526c957cb5f96dff19682a4e60c6a0f0
2017-11-08 23:20:46 +00:00
Jiri Stransky
80eff5f4d7 Add external deployment tasks executed on undercloud
Services can define external_deploy_tasks, which are meant to be
executed on the undercloud node. They are step-based as the other
Ansible tasks we have, and they get executed during each deployment
step before the puppet and docker tasks.

These tasks can be used to perform complex actions from the
undercloud, such as executing nested installers like kubespray or
ceph-ansible. This should allow deploying overcloud with a single
Ansible playbook, and without creating Ansible->Mistral->Ansible loop.

Implements: blueprint ansible-config-download
Change-Id: I3dcafb96f5cea5fdcebe2b2012b61a38b0568834
Depends-On: I8491540edf78711f3229eabeda22a17cd55e99c8
2017-10-13 17:24:54 +02:00
Jenkins
52e1a0c943 Merge "Adds post_upgrade_tasks for any service post-upgrade ansible tasks" 2017-09-20 11:16:26 +00:00
Giulio Fidente
09137304b9 Rename service_workflow_tasks into workflow_tasks
Using the service_ prefix seems incoherent with its use in
service_config_settings (vs config_settings).

Change-Id: Ia39f181415bee0071409dabddfa0c5c312915e1f
2017-09-13 17:15:17 +02:00
marios
2e182bffee Adds post_upgrade_tasks for any service post-upgrade ansible tasks
This adds a new config/deployment per role that will come after any
post deploy steps. It drives the same ansible config as the
upgrade_tasks but instead collects the post_upgrade_tasks for any
service in the given role.

The workflow is upgrade_tasks, then post deploy steps (either
puppet/ or docker/ depending on the env) and then the
post_upgrade_tasks added here.

This is added to the pacemaker/cinder-volume.yaml service for now
see the bug below for more info

Change-Id: Iced34fecf02ebddc91df9302de54d2f4c2cab680
Closes-Bug: 1706951
2017-09-12 18:43:16 +03:00
Steven Hardy
1801565a75 Add support for update_tasks
These work the same way as upgrade_tasks *but* they use a step variable
instead of tags, so we can iterate over a count/sequence which isn't
possibly via a wrapper playbook with tags (we may want to align upgrade
tasks with the same approach if this works out well).

Note the tasks can be run via ansible-playbook on the undercloud, like:

openstack overcloud config download --config-dir tmpconfig
cd tmpconfig/tripleo-HCrDA6-config
ansible-playbook -b -i /usr/bin/tripleo-ansible-inventory update_steps_playbook.yaml --limit controller

The above will do a rolling update for the Controller role (note the inconsistent
capitalization, we probably need to fix the group naming in tripleo-ansible-inventory)
because we specify serial: 1 in the playbook.

You can also trigger an update explicitly on one node like this, which is useful for debugging:

ansible-playbook -vvv -b -i /usr/bin/tripleo-ansible-inventory update_steps_playbook.yaml --limit overcloud-controller-0

Change-Id: I20bb3e26ab9d9cadf1a31fd304de8a014a901aa9
2017-08-12 10:40:48 +00:00
Ben Nemec
4502b7cba6 Make RoleParameters and key_name descriptions consistent
The key_name default is ignored because the parameter is used in
some mutually exclusive environments where the default doesn't
need to be the same.

Change-Id: I77c1a1159fae38d03b0e59b80ae6bee491d734d7
Partial-Bug: 1700664
2017-08-02 16:18:25 -05:00
Steven Hardy
0a44085af6 Move docker_puppet_tasks calculation into services.yaml
This makes the RolesData output more accurate, and we can rework
things so docker-puppet only gets run when there is a non-empty
file calculated (e.g there are tasks to run).

Change-Id: I8cdab3c857977c80fe2e359ab9e05740a838d66b
2017-07-24 14:02:44 +03:00
Steven Hardy
d364d9cca2 Move services.yaml output calculation into Value resources
This stores the result of the yaql queries etc for easier debugging, and
also so there's no risk we constantly re-evaluate the expensive query
which can happen with some heat versions and configurations.

This also gives a nicer error when things go wrong as when a query fails
you know which resource had an error, and also the validation on resources
is currently stricter due to bug #1599114.  We also get some additional
type validation from each OS::Heat::Value resource, e.g it checks if the
calculated value is a valid map or list.

The final advantage (and the original motivation for doing this) is that
we can easily filter null values for any outputs where this isn't already
done, which makes the config data written via openstack overcloud config
download cleaner.

Change-Id: Ia6697cf2e47f3f7b727d620536e0873a985c98c4
2017-07-24 14:02:44 +03:00
Steven Hardy
2ff922b0dc Move step_config/docker_config calculation into services.yaml
Moving these means we get a more accurate output from the overcloud
RoleData output, which more closely reflects what is actually
deployed.

Change-Id: I154f36c1597cf4abe29ca0bfe15a54f507433fb1
2017-07-21 11:05:46 +01:00
Giulio Fidente
baf6eee501 Adds network/cidr mapping into a new service property
Makes it possible to resolve network subnets within a service
template; the data is transported into a new property ServiceData
wired into every service which hopefully is generic enough to
be extended in the future and transport more data.

Data can be consumed in service templates to set config values
which need to know what is the subnet where a deamon operates (for
example the Ceph Public vs Cluster network).

Change-Id: I28e21c46f1ef609517175f7e7ee19e28d1c0cba2
2017-07-14 13:44:04 +02:00
Steven Hardy
a6d2704468 Move services.yaml to common directory
This new directory has now been added to the RDO packaging so we
can move things common to both puppet/container architecture here,
starting with the recently combined services.yaml

Change-Id: If2ce27188c4c15002b3ad830e8d6eb9504d2f3d2
2017-07-13 13:41:19 +01:00