Move cinder-volumes onto bare metal host

[Bjoern]

Move cinder-volumes onto bare metal host since the isolation does not bring any benefit.
The containerization is probably causing more iscsi/tgtd issues then necessary. At least I still have a cinder secure delete (dd) issue open which is insanely slow inside a container unless you do a vgs on the actual host.

[Bjoern (bjoern-t)]

One thing to keep in mind is that we create cinder_volumes container on infra nodes in case we use the netapp back-end.

[Kevin Carter (kevin-carter)]

@Apsu-2 to spike on this issue and determine if there are any benefits to running cinder on a host instead of within the container. While this is already configurable we are looking to see if the `is_metal` flag should be set as a default.

[Kevin Carter (kevin-carter)]

adding "is_metal: true" to the rpc/openstack_environment.yml file for the cinder `cinder_volumes_container` entry will enable cinder volume to be run on a physical host instead of running it on the container. I have created two patches that have been attached to this issue with how that would be done.

[Kevin Carter (kevin-carter)]

juno cinder is metal patch

[Kevin Carter (kevin-carter)]

kilo cinder is metal patch

[Kevin Carter (kevin-carter)]

Being that this is a deployment decision, I'm of the opinion that this is not something that we should "fix". If we want this to be the default I'm fine with it however, this is not a pressing issue.

[Andy McCrae (andrew-mccrae)]

My biggest concern is for existing deploys that have cinder on containers already - the change itself is pretty simple and I think we can make that the default, it seems sensible, but we can't just ignore existing deployments.

[Bjoern (bjoern-t)]

Let's close this bug since it seems pretty trivial to deploy cinder-volumes into the bare metal host by setting the is_metal property.

[Andy McCrae (andrew-mccrae)]

I've added a patch in - I think the default should be on_metal, and we can address moves from juno-> kilo/master individually/in an unassociated upgrade script (in my opinion).

I also wanted to move scheduler service into its own container because I don't believe it should ever have lived on the "volumes" container to begin with. The new default will be for it to go on the storage_infra hosts. (assuming my pr is merged)

[Kevin Carter (kevin-carter)]

potential backport for the 11.1.0 release.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: kilo
Review: https://review.openstack.org/195181

[Andy McCrae (andrew-mccrae)]

Updated and put a backport in for kilo.

I've added documentation to say that if you're not using lvm you may want to keep cinder-volumes in a container.

[Kevin Carter (kevin-carter)]

Kilo backport https://review.openstack.org/195181

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/195181
Committed: https://git.openstack.org/cgit/stackforge/os-ansible-deployment/commit/?id=c34a80a4d66e68961bb14af57d34231c16c094b1
Submitter: Jenkins
Branch: kilo

commit c34a80a4d66e68961bb14af57d34231c16c094b1
Author: Andy McCrae <email address hidden>
Date: Mon Jun 22 15:49:00 2015 +0100

    Move Cinder-volumes to "on metal"

    Cinder-volumes is tightly coupled to the storage host and doesn't
    gain from the benefits of containerization. This patch moves the default
    location for cinder-scheduler into it's own container on the
    "storage-infra_hosts", and the default location for cinder-volumes to be
    "on metal" in the openstack_environment cinder.yml file.

    Added documentation to suggest that you may want to remove "is_metal:
    true" from cinder-volumes service when not using lvm.

    Change-Id: I1879b1aa6dbe69a5a7e769a43b849441a38feeb8
    Closes-Bug: #1433240
    (cherry picked from commit 91bd96b9e1f59a650bfb8db5f414b3aae7bdea07)

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/openstack-ansible 11.2.11 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/openstack-ansible 11.2.12 release.

[Davanum Srinivas (DIMS) (dims-v)]

This issue was fixed in the openstack/openstack-ansible 11.2.14 release.