reviewing all the storage related bugs for forman, we released that we cannot install cinder lvm backend. 
There are several bugs opened with different system configurations all mounting to one outcome: cinder does not install and configure lvm backend for cinder the way that packstack does today. 
I asked Yogev to open this bug and link all related bugs to it.

I have installed and tested the LVM Block Storage group many times on a different server than the cloud controller. It works fine provided you create the cinder-volumes VG manually before adding the server to the host group. This is consistent with Packstack. I have tested both with a local loopback device and with an external iSCSI LUN.

(In reply to jliberma from comment #2)
> I have installed and tested the LVM Block Storage group many times on a
> different server than the cloud controller. It works fine provided you
> create the cinder-volumes VG manually before adding the server to the host
> group. 

This is not consistent with packstack which creates the vg. 
There is no user manual intervention at all with packstack - you simply give packstack the type of storage and paramaters for it and it creates and configures it for you. 

This is consistent with Packstack. I have tested both with a local
> loopback device and with an external iSCSI LUN.

Is the missing VG the basis for this bug?

It would be trivial to add the logic to create a loopback device backed VG if no cinder-volumes group exists, but that is an RFE, not an urgent bug.

1. please see all related bugs linked on this bug for lvm type storage. 
2. This is not an RFE but a bug since packstack deploys and creates the vg so if we are moving to deployment and configuration through foreman we need to make sure that all the functionality that we had in packstack remains consistent in foreman. 
An RFE for example (which I did not open yet but will) would be asking foreman to deploy cinder with a netapp backend (something not done by packstack today). 
3. I'm glad that its trivial to add the vg - does it means that this can be an easy fix and we can have this functionality merged soon?

I seem to recall that packstack will use an existing cinder-volume VG if it exists, although you can explicitly tell it to create a POC VG on a loopback device. o in this way it is similar to packstack already.

I have been told many times that while feature parity with packstack is a goal, it is not the most important concern. Packstack has several features (such as SSL) that we don't have in Foreman. That is what I was told by the Foreman developers when I asked for cinder-volume on the controller node and NFS-backed Cinder.

I was also told that if I needed the features before the developers could get to them then I should write them in myself and submit them to astapor. (Which I have been doing.) So feel free to add it and submit it upstream whenever you are ready.

Personally I think its better to ask the customers to make their own VG so long as this step is well documented. This method gives customers a lot of flexibility to chose their backend storage method -- whether it be an iSCSI LUN, a local disk, or a loopback device. This is also what I have heard from the field deployment engineers who interact with customers.

I am going to go off and test the LVM Block Storage group today to make sure it is still working. I will let you know if its broken.

So I just tested the LVM Block Storage group and it all works fine. I'm happy to provide instructions if you need help getting it working. Thanks, Jacob

[root@rhos1 bz1064889(refarch_member)]# cinder list
+--------------------------------------+--------+----------------------------------+------+-------------+----------+--------------------------------------+
|                  ID                  | Status |           Display Name           | Size | Volume Type | Bootable |             Attached to              |
+--------------------------------------+--------+----------------------------------+------+-------------+----------+--------------------------------------+
| 358b0d5f-fe43-4e6e-b037-2d6448853220 | in-use | full1-cinder_volume-zlgx3ysbw7nw |  5   |     None    |  false   | 48ae8f01-b5e4-453d-8eb5-7775bb848b14 |
+--------------------------------------+--------+----------------------------------+------+-------------+----------+--------------------------------------+
[root@rhos1 bz1064889(refarch_member)]# source /root/keystonerc_admin 
[root@rhos1 bz1064889(admin)]# cinder service-list
+------------------+------------------------------------+------+---------+-------+----------------------------+
|      Binary      |                Host                | Zone |  Status | State |         Updated_at         |
+------------------+------------------------------------+------+---------+-------+----------------------------+
| cinder-scheduler | rhos1.cloud.lab.eng.bos.redhat.com | nova | enabled |   up  | 2014-02-13T21:27:53.000000 |
|  cinder-volume   | rhos7.cloud.lab.eng.bos.redhat.com | nova | enabled |   up  | 2014-02-13T21:27:52.000000 |
+------------------+------------------------------------+------+---------+-------+----------------------------+

[root@osp4-foreman bz1064889]# curl -s -u admin:changeme -k -H "Accept: application/json, version=2", -H "Content-Type: application/json" https://osp4-foreman/api/hostgroups?search=environment=production  | jgrep -s "hostgroup.id & hostgroup.label"
[
  {
    "hostgroup.id": 1,
    "hostgroup.label": "Controller (Nova Network)"
  },
  {
    "hostgroup.id": 2,
    "hostgroup.label": "Compute (Nova Network)"
  },
  {
    "hostgroup.id": 3,
    "hostgroup.label": "Controller (Neutron)"
  },
  {
    "hostgroup.id": 4,
    "hostgroup.label": "Compute (Neutron)"
  },
  {
    "hostgroup.id": 5,
    "hostgroup.label": "Neutron Networker"
  },
  {
    "hostgroup.id": 6,
    "hostgroup.label": "LVM Block Storage"
  },
  {
    "hostgroup.id": 7,
    "hostgroup.label": "Load Balancer"
  },
  {
    "hostgroup.id": 8,
    "hostgroup.label": "HA Mysql Node"
  },
  {
    "hostgroup.id": 9,
    "hostgroup.label": "Swift Storage Node"
  }
]

[root@osp4-foreman bz1064889]# curl -s -u admin:changeme -k -H "Accept: application/json, version=2", -H "Content-Type: application/json" https://osp4-foreman/api/hosts | jgrep -s "host.name & host.hostgroup_id"
[
  {
    "host.name": "osp4-foreman.cloud.lab.eng.bos.redhat.com"
  },
  {
    "host.hostgroup_id": 3,
    "host.name": "rhos1.cloud.lab.eng.bos.redhat.com"
  },
  {
    "host.hostgroup_id": 4,
    "host.name": "rhos4.cloud.lab.eng.bos.redhat.com"
  },
  {
    "host.hostgroup_id": 4,
    "host.name": "rhos5.cloud.lab.eng.bos.redhat.com"
  },
  {
    "host.hostgroup_id": 5,
    "host.name": "rhos6.cloud.lab.eng.bos.redhat.com"
  },
  {
    "host.hostgroup_id": 6,
    "host.name": "rhos7.cloud.lab.eng.bos.redhat.com"
  }
]

Jacob is right about the feature parity thing.  While it is reasonable as a goal in many (but definitely not all) cases, it is not our first priority.  The foreman deployment for RHOS4 is meant to be a reference architecture that a customer can choose to use, or roll their own hostgroups if they have something else they desire.  This of course will grow and become more and more flexible, but the initial goals of this release were to extend what was in the foreman installer for RHOS 3.  Top goals were things like adding support for neutron, starting to bring in ssl, and beginning to support an HA setup.  Packstack has a different goal and different target audience.  In this particular case, it is the opinion of people in the field that customers would not mind setting up their VG for anything production, and in fact may rather control that versus having something magical happen under the covers, which is more appropriate for a testing/PoC kind of environment.  It is my opinion that _if_ this were agreed to by product management as a feature for Foreman manifests to implement, we can consider it. Otherwise, this works as designed, though we perhaps need clearer steps (which Jacob has now provided) of how this is expected to be set up.

I hear what you are saying about helping novice users and it is a good point. 

The pilot customers and field engineers tell us they prefer to create their own volume group. They don't want an automated installer mucking with their storage. Of course, these are mostly large, experienced customers.

We already assume that customers can perform basic functions such as installing the OS, setting IP addresses, adding packages, and managing iptables. They must do those things to use Foreman. Volume group creation is another basic function we should expect novices to handle.

A well documented procedure should help novice customers get started. If they can't handle VG creation on their own they probably should buy consulting service.

Here are steps to create a cinder-volumes VG on a local partition, an iSCSI target, or a loopback device. I hope this helps with your testing.

# local partition (requires an unused disk or partition)
	pvcreate -yv -ff /dev/sdb
        vgcreate cinder-volumes /dev/sdb

# iSCSI target (requires an initiator and target)
	iscsiadm -m discovery -t st -p 172.31.143.200
        iscsiadm -m node -l
        partprobe -s
        pvcreate -yv -ff /dev/sdb
        vgcreate cinder-volumes /dev/sdb

# loopback device (poc only, requires free space)
	truncate --size 5G /root/cinder-volumes
        losetup -fv /root/cinder-volumes

I have added those examples to the rdo doc here:
http://openstack.redhat.com/Deploying_RDO_using_Foreman#Quick_volume_group_creation_for_testing

If i understand the problem correctly, the BZ is not about LVM backend not working, but the problem is that if the machine doesn't already contain cinder-volumes VG, Foreman won't create a PoC/testing VG (VG backed by a loopback file, like the one Packstack creates). I'll change the BZ title so that it's more descriptive.


By the way for testing and PoC VG creation we have a script which does the same thing as Packstack does, so that people don't have to figure it out by themselves (i remember i pointed someone to it a while ago):

https://github.com/redhat-openstack/astapor/blob/master/bin/cinder-testing-volume.sh

You can wget the script to a machine and run it like:

bash cinder-testing-volume.sh 5G

to create a 5 gigabyte cinder-volumes VG for PoC/testing.

This is covered in rhel-osp-installer