On screenshot is an instance in state 'NEW'. If the instance was really running, this most probably means that dbomatic daemon was not running (this daemon updates instance status, ip address and other). Could you please retry again and check if dbomatic is running?

Tried again today , Ip address wasn't populated .
Can be checked at : https://snowstorm.lab.eng.pnq.redhat.com/conductor/

service conductor-dbomatic status
dbomatic (pid  14278) is running..

From /var/log/deltacloud-ec2-us-west-1/ec2.log

I, [2011-06-30T19:05:56.426563 #14452]  INFO -- : New Aws::Ec2 using per_thread-connection mode
I, [2011-06-30T19:05:56.427161 #14452]  INFO -- : Opening new HTTPS connection to ec2.us-west-1.amazonaws.com:443
W, [2011-06-30T19:05:57.800454 #14452]  WARN -- : ##### Aws::Ec2 returned an error: 403 Forbidden
<?xml version="1.0" encoding="UTF-8"?>
<Response><Errors><Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.</Message></Error></Errors><RequestID>8a118190-048d-4521-8ddb-00c3fcc10eef</RequestID></Response> #####
W, [2011-06-30T19:05:57.800552 #14452]  WARN -- : ##### Aws::Ec2 request: ec2.us-west-1.amazonaws.com:443/?AWSAccessKeyId=AKIAJRCPNVJYQBHCOBEA&Action=DescribeInstances&SignatureMethod=HmacSHA256&SignatureVersion=2&Timestamp=2011-06-30T13%3A35%3A56.000Z&Version=2010-08-31&Signature=n65WmvzSUP%2FqhtmtW7eLYzSHNseYaHoJxn6yul6dP%2B4%3D ####
!! Unexpected error while processing request: undefined method `details' for #<Deltacloud::ExceptionHandler::ProviderError:0x7fa35f190ed8>
undefined method `details' for #<Deltacloud::ExceptionHandler::ProviderError:0x7fa35f190ed8>
        ././views/errors/502.xml.haml:7:in `__tilt_70169826188520'
        ././views/errors/502.xml.haml:-6:in `instance_eval'
        ././views/errors/502.xml.haml:-6:in `__tilt_70169826188520'
        /usr/lib/ruby/gems/1.8/gems/tilt-1.3.2/lib/tilt/template.rb:140:in `call'
        /usr/lib/ruby/gems/1.8/gems/tilt-1.3.2/lib/tilt/template.rb:140:in `cached_evaluate'
        /usr/lib/ruby/gems/1.8/gems/tilt-1.3.2/lib/tilt/template.rb:127:in `evaluate'
        /usr/lib/ruby/gems/1.8/gems/tilt-1.3.2/lib/tilt/haml.rb:24:in `evaluate'
        /usr/lib/ruby/gems/1.8/gems/tilt-1.3.2/lib/tilt/template.rb:76:in `render'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:343:in `render_without_format'
        ././lib/sinatra/respond_to.rb:129:in `render'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:311:in `haml'
        ././lib/deltacloud/helpers/application_helper.rb:112:in `report_error'
        ././lib/sinatra/respond_to.rb:242:in `call'
        ././lib/sinatra/respond_to.rb:242:in `respond_to'
        ././lib/deltacloud/helpers/application_helper.rb:111:in `report_error'
        ././server.rb:61
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:641:in `instance_eval'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:641:in `error_block!'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:636:in `each'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:636:in `error_block!'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:630:in `handle_exception!'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:605:in `dispatch!'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:411:in `call!'
        /usr/lib/ruby/gems/1.8/gems/sinatra-1.0/lib/sinatra/base.rb:566:in `instance_eval'

condor related bug, passing to Chris. Problem is that for some reason DeltacloudPublicNetworkAddresses is not filled in (empty string) in EventLog even if it's set in condor - 'condor_q -long' output prints this value properly.

Yeah, I see the problem now.  Basically what was happening was that we were setting the state to JobRunning() before re-probing the job.  This means that we would emit the ULOG_EXECUTE event, then update the job state to include the IP addresses.  Of course, by that time it was too late, but that's why it would show up in condor_q but not in the EventLog.  The following patch seems to fix it for me:

diff --git a/src/condor_gridmanager/dcloudjob.cpp b/src/condor_gridmanager/dclou
index 1556541..3532b00 100644
--- a/src/condor_gridmanager/dcloudjob.cpp
+++ b/src/condor_gridmanager/dcloudjob.cpp
@@ -1048,10 +1052,16 @@ void DCloudJob::ProcessInstanceAttrs( StringList &attrs 
        if ( new_status ) {
                // Now that we have everything in the classad, do the job
                // status update.
                StatusUpdate( new_status );
+               if ( strcasecmp( new_status, DCLOUD_VM_STATE_RUNNING ) == 0 ) {
+                       JobRunning();
+               }
        }
 
        if ( attrs.isEmpty() ) {
                StatusUpdate( DCLOUD_VM_STATE_FINISH );
        }
 }
@@ -1065,9 +1075,10 @@ void DCloudJob::StatusUpdate( const char *new_status )
                SetEvaluateState();
        } else if ( SetRemoteJobStatus( new_status ) ) {
                // TODO Should 'shutting-down' be treated as running?
-               if ( strcasecmp( new_status, DCLOUD_VM_STATE_RUNNING ) == 0 ) {
-                       JobRunning();
-               }
                remoteJobState = new_status;
                probeNow = true;
                SetEvaluateState();

I'll work on getting that into a condor build.

Chris Lalancette

The IP address is displayed now .
Verified

rpm -qa|grep aeolus
aeolus-configure-2.0.1-0.el6.20110628141215gitb8aaf85.noarch
aeolus-conductor-daemons-0.3.0-0.el6.20110701204941gitd66e27c.noarch
aeolus-all-0.3.0-0.el6.20110701204941gitd66e27c.noarch
aeolus-conductor-0.3.0-0.el6.20110701204941gitd66e27c.noarch
aeolus-conductor-doc-0.3.0-0.el6.20110701204941gitd66e27c.noarch
rubygem-aeolus-cli-0.0.1-1.el6.20110701204941gitd66e27c.noarch

removing ce-p2-beta

second attempt to remove ce-p2-beta

release pending...

release pending...

closing out old bugs

perm close