openstack/kolla-ansible
Code Issues Proposed changes
0761285f90
kolla-ansible/ansible/roles/ironic/tasks/deploy.yml

35 lines
1.0 KiB
YAML
Raw Normal View History

Allow ironic role to pull images Change-Id: Ib3c71d89f8e20d58d44034a215140a35c6874a2b Partially-Implements: blueprint pre-pull-images
2016-01-05 17:57:55 +00:00
---
Performance: use import_tasks for register and bootstrap Including tasks has a performance penalty when compared with importing tasks. If the include has a condition associated with it, then the overhead of the include may be lower than the overhead of skipping all imported tasks. In the case of the register.yml and bootstrap.yml includes, all of the tasks in the included file use run_once: True. The run_once flag improves performance at scale drastically, so importing these tasks unconditionally will have a lower overhead than a conditional include task. It therefore makes sense to switch to use import_tasks there. See [1] for benchmarks of run_once. [1] https://github.com/stackhpc/ansible-scaling/blob/master/doc/run-once.md Change-Id: Ic67631ca3ea3fb2081a6f8978e85b1522522d40d Partially-Implements: blueprint performance-improvements
2020-07-07 17:14:37 +01:00
- import_tasks: register.yml
ironic: Follow up for ironic_enable_keystone_integration Follow up for I0c7e9a28876a1d4278fb2ed8555c2b08472864b9 which added a ironic_enable_keystone_integration variable to support Ironic in multi-region environments. This change skips Keystone service registration based on ironic_enable_keystone_integration rather than enable_keystone. It also updates the ironic-inspector.conf template to use the new variable. Change-Id: I2ecba4999e194766258ac5beed62877d43829313
2021-08-10 09:16:59 +01:00
when: ironic_enable_keystone_integration | bool
Allow ironic role to pull images Change-Id: Ib3c71d89f8e20d58d44034a215140a35c6874a2b Partially-Implements: blueprint pre-pull-images
2016-01-05 17:57:55 +00:00
Performance: replace unconditional include_tasks with import_tasks Including tasks has a performance penalty when compared with importing tasks. If the include has a condition associated with it, then the overhead of the include may be lower than the overhead of skipping all imported tasks. For unconditionally included tasks, switching to import_tasks provides a clear benefit. Benchmarking of include vs. import is available at [1]. This change switches from include_tasks to import_tasks where there is no condition applied to the include. [1] https://github.com/stackhpc/ansible-scaling/blob/master/doc/include-and-import.md#task-include-and-import Partially-Implements: blueprint performance-improvements Change-Id: Ia45af4a198e422773d9f009c7f7b2e32ce9e3b97
2020-06-29 15:06:53 +01:00
- import_tasks: config-host.yml
Separate per-service host configuration tasks Currently there are a few services that perform host configuration tasks. This is done in config.yml. This means that these changes are performed during 'kolla-ansible genconfig', when we might expect not to be making any changes to the remote system. This change separates out these host configuration tasks into a config-host.yml file, which is included directly from deploy.yml. One change in behaviour is that this prevents these tasks from running during an upgrade or genconfig. This is probably what we want, but we should be careful when any of these host configuration tasks are changed, to ensure they are applied during an upgrade if necessary. Change-Id: I001defc75d1f1e6caa9b1e11246abc6ce17c775b Closes-Bug: #1860161
2020-01-17 17:00:21 +00:00
Performance: replace unconditional include_tasks with import_tasks Including tasks has a performance penalty when compared with importing tasks. If the include has a condition associated with it, then the overhead of the include may be lower than the overhead of skipping all imported tasks. For unconditionally included tasks, switching to import_tasks provides a clear benefit. Benchmarking of include vs. import is available at [1]. This change switches from include_tasks to import_tasks where there is no condition applied to the include. [1] https://github.com/stackhpc/ansible-scaling/blob/master/doc/include-and-import.md#task-include-and-import Partially-Implements: blueprint performance-improvements Change-Id: Ia45af4a198e422773d9f009c7f7b2e32ce9e3b97
2020-06-29 15:06:53 +01:00
- import_tasks: config.yml
Allow ironic role to pull images Change-Id: Ib3c71d89f8e20d58d44034a215140a35c6874a2b Partially-Implements: blueprint pre-pull-images
2016-01-05 17:57:55 +00:00
Performance: optimize genconfig Config plays do not need to check containers. This avoids skipping tasks during the genconfig action. Ironic and Glance rolling upgrades are handled specially. Swift and Bifrost do not use the handlers at all. Partially-Implements: blueprint performance-improvements Change-Id: I140bf71d62e8f0932c96270d1f08940a5ba4542a
2020-07-30 14:36:15 +02:00
- import_tasks: check-containers.yml
Use include_tasks instead of include include is marked as deprecated since ansible 2.4[0] [0] https://docs.ansible.com/ansible/2.4/include_module.html#deprecated Co-Authored-By: confi-surya <singh.surya64mnnit@gmail.com> Change-Id: Ic9d71e1865d1c728890625aeddf424a5734c0a8a
2018-07-23 12:58:02 +08:00
- include_tasks: clone.yml
dev mode: Add support for ironic Allows users to develop on ironic using Kolla. Partially implements: blueprint mount-sources Change-Id: I74540f5bcbf723f097f3dea96dcaf067834c493a
2018-05-28 15:03:18 +00:00
when: ironic_dev_mode | bool
Performance: use import_tasks for register and bootstrap Including tasks has a performance penalty when compared with importing tasks. If the include has a condition associated with it, then the overhead of the include may be lower than the overhead of skipping all imported tasks. In the case of the register.yml and bootstrap.yml includes, all of the tasks in the included file use run_once: True. The run_once flag improves performance at scale drastically, so importing these tasks unconditionally will have a lower overhead than a conditional include task. It therefore makes sense to switch to use import_tasks there. See [1] for benchmarks of run_once. [1] https://github.com/stackhpc/ansible-scaling/blob/master/doc/run-once.md Change-Id: Ic67631ca3ea3fb2081a6f8978e85b1522522d40d Partially-Implements: blueprint performance-improvements
2020-07-07 17:14:37 +01:00
- import_tasks: bootstrap.yml
Optimize reconfiguration for ironic Change-Id: I29f4d999c711f11f2db4e2d68b3ff194f0ab032b Partially-implements: blueprint better-reconfigure Co-Authored-By: Mark Goddard <mark@stackhpc.com> Co-Authored-By: wu.chunyang <wu.chunyang@99cloud.net>
2017-01-23 12:14:50 +08:00
- name: Flush handlers
meta: flush_handlers
Use ironic inspector 'dnsmasq' PXE filter by default With Docker CE, the daemon sets the default policy of the iptables FORWARD chain to DROP. This causes problems for provisioning bare metal servers when ironic inspector is used with the 'iptables' PXE filter. It's not entirely clear why these two things interact in this way, but switching to the 'dnsmasq' filter works around the issue, and is probably a good move anyway because it is more efficient. We have added a migration task here to flush and remove the ironic-inspector iptables chain since inspector does not do this itself currently. Change-Id: Iceed5a096819203eb2b92466d39575d3adf8e218 Closes-Bug: #1823044
2019-04-03 17:33:04 +01:00
# NOTE(mgoddard): If inspector was previously configured to use the iptables
# PXE filter, it may leave rules in place that block inspection. Clean them up.
# The iptables Ansible module is not idempotent - it fails if the chain does
# not exist, so use a command instead.
- name: Flush and delete ironic-inspector iptables chain
become: true
command: iptables --{{ item }} ironic-inspector
register: ironic_inspector_chain
with_items:
- flush
- delete-chain
when: ironic_inspector_pxe_filter != 'iptables'
changed_when: ironic_inspector_chain.rc == 0
failed_when:
- ironic_inspector_chain.rc != 0
- "'No chain/target/match by that name' not in ironic_inspector_chain.stderr"
Copy Permalink