Description of problem:
This is related to Bug 1226990 and Bug 1241256.

If GROWPART=true d-s-s option is specified but growpart is not installed or fails, then d-s-s should report the error and exit non-zero w/o continuing.  It is incorrect behaviour (IMHO) to continue attempting to configure storage since an explicit option was specified and should be assumed as desired.

Version-Release number of selected component (if applicable):
docker-1.7.1-108

How reproducible:
reliably since docker-1.6.x

Steps to Reproduce:
1. Make sure cloud-utils-growpart is NOT installed (or /usr/bin/growpart is missing or will fail)
2. Add GROWPART=true option to /etc/sysconfig/docker-storage-setup
4. Start docker.service

Actual results:
On docker.service start, d-s-s runs the first time automatically.  It does not extend any partitions, does not report any errors in logs, and continues to create thinpool LV.  Docker service starts successfully, using an undesired storage configuration.

Expected results:
On docker.service start, d-s-s prints & logs an error that GROWPART=true was specified but /bin/growpart binary could not be found or failed.  No further operations are performed and non-zero exit status is returned resulting in docker.service startup failure.

Additional info:
Problem is reproducible on RHEL and Atomic (if first remove/move growpart binary or cause it to fail).  Also, it would be good to document optional /usr/bin/growpart dependency for the GROWPART option.