When using lioadm / targetcli to serve LVM volumes to instances
the former saves target configuration under /etc/target.
If cinder_volume container is upgraded / replaced then all targets
are gone and instances cannot connect to their volumes any longer.

This fix introduces target_config volume where corresponding
information is persisted.

Change-Id: I919bbe00853266037dd5c015810cc13c25e2e033
Closes-Bug: #1783569

freezer's deploy.yml do not have when condition,here to add it.

Change-Id: Id275a5eb746783694248a6db5b7f3ee7b8b3b8c5

- Change to openstack CLI
- Change the way to run demo from "sh" to "./" for
matching with README.rst in tacker demo folder.

Change-Id: I17b755cd8d52f594785ef13634bfa233e63841a7

Partially-Implements: blueprint networking-baremetal

Change-Id: I92b9505843f12692aef96764a314e5db49001a9b

Fixes a typo introduced in I93e53bad9727beb786b00bd7fcd6d78785c619c2.

Change-Id: I9fd6587913cccd5a29b3fc012b4ddeac8859a0ff
Related-Bug: #1782799
TrivialFix

Without these jobs, a compute node that is rebooted or powered off may
violently kill off the VMs running inside of it. This has been kept
separate from the main portion of kolla-ansible since no current role
modifies the systemd jobs of the system.

Change-Id: I0a4424f97b5ad872ff0398258c1dc42d31d0ef07

Enables setting rp_filter mode on Neutron L3 agent and Nova compute
hosts whilst maintaining the default that it is disabled.

Closes-Bug: #1782799
Change-Id: I93e53bad9727beb786b00bd7fcd6d78785c619c2

While it is possible to implement countermeasures against some attacks
on TLS, migrating to a later version of TLS (TLS 1.2 is strongly
encouraged) is the only reliable method to protect against
the current protocol vulnerabilities.[1]

[1] https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

Change-Id: I44f67e3a49bb00fea069d29c46b3e86404c7df0b

It is possible to have an accessible swift API that is not managed by
kolla-ansible -- for example, ceph exposes a swift API, and using that
requires setting swift as the glance backend.

So, we should loosen the requirement that using the swift backend for
glance requires swift be enabled in kolla-ansible.

Co-Authored-By: Adam Harwell <flux.adam@gmail.com>

Change-Id: I17076d5412d2b1e1f13bb0badceaca85a5cee108

The word "action" is now an Ansible reserved word, and things have
transitioned to "kolla_action", but looks like this was missed.

Change-Id: Ie07a2a7d8b153a6d39b91129256727157f8dfa34

In this patch, the glance-registry service was disabled:
https://review.openstack.org/#/c/566804/

However, the config task still tries to copy files for it, which will
break due to path errors.

Change-Id: If39bb12bf830e6559342037ae2a2b99a784ee503

The rsync prior to v3.1.0 the uid/gid parameter have no effect at
all if it runs as normal(non-root) user.

Since v3.1.0 these parameter are problematic for normal user
because now rsync, regardless of root or non-root, if the
parameters are given then it just tries to call setgroups() which
is not possible for normal user so errors may occur.

    swift-object-replicator: @ERROR: setgroups failed\u0000
    swift-object-replicator: rsync error: error starting
    client-server protocol (code 5) at main.c(1648)
    [sender=3.1.2]\u0000

Either way, these parameters are not needed for swift-rsync
container.

Change-Id: Ia7fe9f06d7a21a55f52b90c2cc1b2498300e6532
Signed-off-by: Minho Ban <mhban@samsung.com>

Co-Authored-By: caowei <cao.wei@99cloud.net>
Co-Authored-By: yuqian <yu.qian@99cloud.net>

Change-Id: If8143b720203fe75cf586248f1fa1d3fde34c750
blueprint: onos-support

This patchset apply Ironic rolling upgrade logic [1][2]
[1] https://docs.openstack.org/ironic/latest/contributor/rolling-upgrades.html
[2] https://docs.openstack.org/ironic/latest/admin/upgrade-guide.html#rolling-upgrades

Depends-On: https://review.openstack.org/#/c/575594/

Co-author: Ha Manh Dong <donghm@vn.fujitsu.com>
Change-Id: Id68244951dc66d5c3423ef44324bd72058f4ba67
Implements: blueprint apply-service-upgrade-procedure

This service is only required if you want to support cold migration.
In some instances that is not a needed feature, and avoiding having
another key to manage is an advantage.

Co-Authored-By: Adam Harwell <flux.adam@gmail.com>

Change-Id: I0a55a91673d9178933f134832df4bd849ddf5af4

For large installations it makes sense to use a higher number of forks
than the default.

Change-Id: I34cdc146a4ed2185fb36fbb34ab72916ec98bee5