Bug 754769 - ConfigServer config not deployed to vsphere guests
Summary: ConfigServer config not deployed to vsphere guests
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: CloudForms Cloud Engine
Classification: Retired
Component: aeolus-configserver
Version: 1.0.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
Assignee: Joe Vlcek
QA Contact: dgao
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-11-17 17:00 UTC by wes hayutin
Modified: 2012-05-15 20:50 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-05-15 20:50:26 UTC


Attachments (Terms of Use)
vsphere_working (147.59 KB, image/png)
2011-11-21 15:18 UTC, dgao
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2012:0585 0 normal SHIPPED_LIVE new packages: aeolus-configserver 2012-05-15 22:31:37 UTC

Description wes hayutin 2011-11-17 17:00:42 UTC
Description of problem:

using the following deployble
<deployable name="Katello Demo">
<script/>
<description>Launch and instance and wire it to katello</description>
<assemblies>
<assembly name="demo" hwp="hwp1">
<image id="7b05da20-22f5-4242-9c8e-334014771c07" build="5282afa5-8a79-4eb5-b9c7-9bec9d8e27eb"/>
<services>
<service name="reg">
<executable url="https://ec2-204-236-247-167.compute-1.amazonaws.com/katello-demo.sh"/>
<parameters>
<parameter name="katello_host" type="scalar">
<value>ec2-204-236-247-167.compute-1.amazonaws.com</value>
</parameter>
<parameter name="katello_user" type="scalar">
<value>admin</value>
</parameter>
<parameter name="katello_pw" type="password">
<value>admin</value>
</parameter>
<parameter name="katello_org" type="scalar">
<value>ACME_Corporation</value>
</parameter>
<parameter name="katello_env" type="scalar">
<value>DEV</value>
</parameter>
</parameters>
</service>
</services>
</assembly>
</assemblies>
</deployable>

on vsphere guest I get

[root@dhcp77-121 ~]# cat /var/log/audrey.log 
[root@dhcp77-121 ~]# rpm -qa | grep audrey
aeolus-audrey-agent-0.4.0-7.el6.noarch
You have new mail in /var/spool/mail/root
[root@dhcp77-121 ~]# cat /etc/rc.local 
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

touch /var/lock/subsys/local

# This conditionally runs Audrey if it exists
[ -f /usr/bin/audrey ] && /usr/bin/audrey


[root@qeblade32 ~]# rpm -qa | grep aeolus
aeolus-conductor-doc-0.6.0-0.20111115223141gita503f01.fc15.noarch
aeolus-configure-2.3.0-0.20111115131840git8f363c4.fc15.noarch
aeolus-all-0.6.0-0.20111115223141gita503f01.fc15.noarch
aeolus-conductor-0.6.0-0.20111115223141gita503f01.fc15.noarch
rubygem-aeolus-cli-0.1.0-3.20111117111046git5ec94c5.fc15.noarch
rubygem-aeolus-image-0.1.0-4.20111024205454git6b2b696.fc15.noarch
aeolus-conductor-daemons-0.6.0-0.20111115223141gita503f01.fc15.noarch

Comment 1 Joe Vlcek 2011-11-17 18:56:38 UTC
The format of the user data is now missing a trailing new line char
which causes the audrey agent to remove the last char of the oAuth
secret assuming it is the new line char.

Using python string.strip()

There was also an error with logging uncovered where the values
supported for logging level by python logging on RHEL are different
than on Fedora. This resulted in an empty log file. Which is only
noticed if things fail and one start to look at the log file.

I am working on the fix.

Comment 3 Greg Blomquist 2011-11-18 16:45:03 UTC
Two issues here:

1)  This seems like a regression.  I've seen this same code fixed before here:  

https://github.com/aeolusproject/audrey/commit/9c9620c9198cd50030f1d74758cee3e03254e5c9

2)  In the case where the user data cannot be parsed (i.e., the base64 decode fails b/c the [:-1] code removes the last base64 encoded char), an error is printed to the logs saying "Failed accessing vSphere user data".  I would not expect the logs to be empty in this case.

Can we get some verification that the user data exists on that guest?  You should be able to cat /media/deltacloud-user-data.txt and see if any data gets printed out.

Comment 4 Joe Vlcek 2011-11-18 18:19:31 UTC
I believe when the oAuth changes were pushed a bad merge may
have overwritten the fix that was applied here:

https://github.com/aeolusproject/audrey/commit/9c9620c9198cd50030f1d74758cee3e03254e5c9

I was able to confirm the user data was correct in:
/media/deltacloud-user-data.txt 

The issues is that it seemes, depending on what version of the
Deltacloud bits one uses, sometimes a /n is appended to the user
data and sometimes not. The [:-1] will always remove the last
char regardless of what it is. The .split() is smart enough to
only remove the trailing '/n' if found.

I also fixed the issue with the empty logs.

See lines 1198-> 1219 here:
https://github.com/aeolusproject/audrey/commit/c30b9f52c90ecc2dd1ad70803cd3bdc4ccbeea93

Comment 5 dgao 2011-11-21 15:18:43 UTC
Created attachment 534801 [details]
vsphere_working

Comment 6 dgao 2011-11-21 15:20:31 UTC
Verified..

[root@intel-s3ea2-03 ~]# rpm -qa | egrep "aeolus|deltacloud"
deltacloud-core-ec2-0.4.1-8.el6.noarch
rubygem-ZenTest-4.3.3-2.aeolus.el6.noarch
aeolus-conductor-doc-0.6.0-3.el6.noarch
aeolus-all-0.6.0-3.el6.noarch
rubygem-deltacloud-client-0.4.0-3.el6.noarch
rubygem-rack-mount-0.7.1-3.aeolus.el6.noarch
rubygem-arel-2.0.10-0.aeolus.el6.noarch
deltacloud-core-vsphere-0.4.1-8.el6.noarch
rubygem-aeolus-cli-0.1.0-4.el6.noarch
deltacloud-core-0.4.1-8.el6.noarch
rubygem-aeolus-image-0.1.0-6.el6.noarch
aeolus-configure-2.3.0-1.el6.noarch
aeolus-conductor-daemons-0.6.0-3.el6.noarch
aeolus-conductor-0.6.0-3.el6.noarch
deltacloud-core-rhevm-0.4.1-8.el6.noarch


Deployable.xml used:

<!-- a deployable represents a set of instances to launch and configure at the
     same time -->
<deployable name="application_stack">
  <description>Deployable For JBoss Application Stack</description>
  <assemblies>
    <!-- when a deployable is launched, each assembly defition in this file
         will map to a launched instance -->
    <assembly name="Proxy_Server" hwp="hwp1">
      <!-- this image element references an image that exists in the image
           warehouse
           images get into the image warehouse either by building the
           image from a template XML file, or by importing from an
           external source (such as an Amazon AMI) -->
      <image id="6fe45c28-8557-47e2-ab95-1ee3d85ee0e8"/>
      <services>
        <service name="proxy1">
          <!-- - this is a URL that the Audrey Configuration Server must be
               able to access, and points to a script that is meant to
               setup the proxy
               - the user will be responsible for authoring and providing
               this script -->
          <executable url="https://www.aeolusproject.org/redmine/attachments/download/169/start_simple"/>
          <!-- - the parameters that are fed into the "proxy_setup_script"
               above are identified here in the "services" section
               - this is a bit clunky and will likely change -->
          <parameters>
            <!-- only scalar parameter types are going to be supported
                 initially -->
            <parameter name="proxy_server_1_param_1" type="scalar"/>
            <parameter name="proxy_server_1_param_2" type="scalar"/>
            <parameter name="proxy_server_1_param_3" type="scalar">
            </parameter>
          </parameters>
        </service>
        <service name="proxy2">
          <!-- - this is a URL that the Audrey Configuration Server must be
               able to access, and points to a script that is meant to
               setup the proxy
               - the user will be responsible for authoring and providing
               this script -->
          <executable url="https://www.aeolusproject.org/redmine/attachments/download/169/start_simple"/>
          <!-- - the parameters that are fed into the "proxy_setup_script"
               above are identified here in the "services" section
               - this is a bit clunky and will likely change -->
        </service>
      </services>
      <!-- the items listed under the "returns" element are values that
           are collected by the launched guest and returned to the
           configuration server
           the values that are returned to the configuration server can be
           shared with other launched instances in this deployable -->
      <returns>
        <return name="hostname"/>
      </returns>
    </assembly>
  </assemblies>
</deployable>

Comment 7 wes hayutin 2011-11-28 01:16:20 UTC
removing bugs from ce-sprint from the tracker.. you can find these bugs by querying the "qa whiteboard" for ce-sprint-60

Comment 9 errata-xmlrpc 2012-05-15 20:50:26 UTC
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-0585.html


Note You need to log in before you can comment on or make changes to this bug.