Open Stack

1.) Your name:  Mark T. Voelker and Xiangfei Zhu
2.) Your email: mvoelker at vmware.com and xiangfeiz at vmware.com
3.) Reporting on behalf of Company/Organization:   VMware, Inc
4.) Name and version (if applicable) of the product you tested: VMware Integrated OpenStack 3.0
5.) Version of OpenStack the product uses:  Mitaka
6.) Link to RefStack results for this product: https://refstack.openstack.org/#/results/681eca53-cc28-4d04-8a43-2d6059b694da 
7.) Workload 1: LAMP Stack with Ansible (
http://git.openstack.org/cgit/openstack/osops-tools-contrib/tree/ansible/lampstack
)
  A.) Did the workload run successfully? Yes (with the trivial patch submitted here: https://review.openstack.org/#/c/383923/ )

  B.) If not, did you encounter any end-user visible error messages?  Please copy/paste them here and provide any context you think would help us understand what happened.

TASK [database : command] ******************************************************
fatal: [192.168.112.201]: FAILED! => {"changed": true, "cmd": "parted -s \"/dev/sdb\" mklabel msdos", "delta": "0:00:00.025755", "end": "2016-10-07 20:40:29.295529", "failed": true, "rc": 1, "start": "2016-10-07 20:40:29.269774", "stderr": "", "stdout": "Error: Could not stat device /dev/sdb - No such file or directory.", "stdout_lines": ["Error: Could not stat device /dev/sdb - No such file or directory."], "warnings": []}
 
  C.) Were you able to determine why the workload failed on this product?  If so, please describe.  Examples: the product is missing a feature that the workload assumes is available, the product limits an action by policy that the workload requires, the workload assumes a particular image type or processor architecture, etc. 

The Ubuntu 14.04 image I was using was configured with an lsiLogic SCSI adapter by default.  When a volume is attached to an instance booted from the image and later a Cinder volume is attached, the lsiLogic adapter needs to be rescanned before the newly-attached Cinder volume is recognized (this may not be needed for all paravirt adapter types).  Rescanning the bus is quite simple to do: you simply run the rescan-scsi-bus script included in the scsitools package.  Rescanning the bus should also be harmless on all other adapter types I’ve encountered, so I submitted a four-line patch to the Ansible playbooks to ensure scsitools is installed and run the rescan-scsi-bus tool.

  D.) (optional) In your estimation, how hard would it be to modify this workload to get it running on this product?  Can you describe what would need to be done?

Trivial…I’ve already posted a ~4 line patch to make it work better across adapter/OS/hypervisor types at:  https://review.openstack.org/#/c/383923

At Your Service,

Mark T. Voelker