Hide Forgot
Created attachment 572249 [details] Proposed patch to fix the problem Description of problem: API_PROVIDER specified into /etc/sysconfig/deltacloud-core is not considered by /etc/init.d/deltacloud-core. Version-Release number of selected component (if applicable): deltacloud-core-0.5.0-5 Expected results: This variable should be considered and used when starting deltacloud-core service.
As a workaround, try putting 'export API_PROVIDER=foo' into the sysconfig file. It looks like that would do the trick.
From bug 803895 - Luigi Toscano 2012-04-06 10:45:14 EDT The workaround "export API_PROVIDER=foo" do work.
Fixed in deltacloud-core-0.5.0-9: diff --git a/deltacloud-core.init b/deltacloud-core.init old mode 100644 new mode 100755 index c4b5644..f616582 --- a/deltacloud-core.init +++ b/deltacloud-core.init @@ -35,6 +35,8 @@ LOGFILE="${LOGFILE:-/var/log/$prog/$DRIVER.log}" LOCKFILE="${LOCKFILE:-/var/lock/subsys/$prog}" PIDFILE="${PIDFILE:-/var/run/deltacloud/deltacloud-core-$DRIVER.pid}" +[ ! -z "$API_PROVIDER" ] && API_PROVIDER=" -P $API_PROVIDER" + [[ ! -d /var/run/deltacloud ]] && mkdir /var/run/deltacloud chown $DELTACLOUD_USER /var/run/deltacloud [ -r $LOGFILE ] && chown nobody $LOGFILE @@ -45,7 +47,7 @@ start() { USER=${DELTACLOUD_USER} cd / echo -n $"Starting $prog-$DRIVER: " - $exec -i ${DRIVER} -e ${API_ENV} --user ${DELTACLOUD_USER} --daemon --pid ${PIDFILE} --port ${PORT} --host ${HOST} + $exec -i ${DRIVER}${API_PROVIDER} -e ${API_ENV} --user ${DELTACLOUD_USER} --daemon --pid ${PIDFILE} --port ${PORT} --host ${HOST} retval=$? if [ $retval -eq 0 ] && touch $LOCKFILE ; then
Tested rpms: >> rpm -qa |grep deltacloud deltacloud-core-rhevm-0.5.0-9.el6_3.noarch deltacloud-core-vsphere-0.5.0-9.el6_3.noarch deltacloud-core-ec2-0.5.0-9.el6_3.noarch deltacloud-core-0.5.0-9.el6_3.noarch rubygem-deltacloud-client-0.5.0-2.el6.noarch which are now available in: brewroot/repos/ce-rhel-6-build/latest/x86_64/pkglist Modified /etc/sysconfig/deltacloud-core as follows: DRIVER="vsphere" PORT=3003 HOST="localhost" DELTACLOUD_USER="nobody" LOGFILE="/var/log/deltacloud-core/$DRIVER.log" API_PROVIDER=<QE vsphere server ip address> Then executed: >> service deltacloud-core start >> curl -X GET --user '<username>:<password>' "http://localhost:3003/api/images?format=xml" returns images available on specified QE vsphere server: <?xml version='1.0' encoding='utf-8' ?> <images> <image href='http://localhost:3003/api/images/AutoImageImport-DoNotDelete' id='AutoImageImport-DoNotDelete'> <name>AutoImageImport-DoNotDelete</name> <owner_id>Axxxxx</owner_id> <description>Other Linux (64-bit)</description> <architecture>x86_64</architecture> <state>AVAILABLE</state> <actions> <link href='http://localhost:3003/api/instances;image_id=AutoImageImport-DoNotDelete' method='post' rel='create_instance' /> </actions> </image> ......... so the /etc/init.d/deltacloud-core looks to be reading API_PROVIDER specified in /etc/sysconfig/deltacloud-core
Moving BZ back to MODIFIED - awaiting ok for final z-stream verification ... as per chat comments copied below <dajo> rlandy, we need to see that rpm in a zstream build before moving to verified
Reran the verification steps in Comment 7 above using the versions of the deltacloud rpms installed with cloudForm 1.1: >> rpm -qa |grep deltacloud rubygem-deltacloud-client-0.5.0-2.el6.noarch deltacloud-core-vsphere-0.5.0-10.el6_2.noarch deltacloud-core-rhevm-0.5.0-10.el6_2.noarch deltacloud-core-ec2-0.5.0-10.el6_2.noarch deltacloud-core-0.5.0-10.el6_2.noarch Was able to reproduce the same expected results: >> curl -X GET --user 'un:pw' "http://localhost:3003/api/images?format=xml" <?xml version='1.0' encoding='utf-8' ?> <images> <image href='http://localhost:3003/api/images/AutoImageImport-DoNotDelete' id='AutoImageImport-DoNotDelete'> <name>AutoImageImport-DoNotDelete</name> <owner_id>x</owner_id> <description>Other Linux (64-bit)</description> <architecture>x86_64</architecture> <state>AVAILABLE</state> <actions> <link href='http://localhost:3003/api/instances;image_id=AutoImageImport-DoNotDelete' method='post' rel='create_instance' /> </actions> </image> <image href='http://localhost:3003/api/images/factory-image-1b225ff0-b86f-4f8a-a870-5277d48f9bae' id='factory-image-1b225ff0-b86f-4f8a-a870-5277d48f9bae'> <name>factory-image-1b225ff0-b86f-4f8a-a870-5277d48f9bae</name> <owner_id>x</owner_id> <description>Other Linux (64-bit)</description> <architecture>x86_64</architecture> <state>AVAILABLE</state> <actions> <link href='http://localhost:3003/api/instances;image_id=factory-image-1b225ff0-b86f-4f8a-a870-5277d48f9bae' method='post' rel='create_instance' /> </actions> </image> ......
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-1516.html