OpenStack Support in Conductor (Revisited)

marios@redhat.com mandreou at redhat.com
Wed Dec 5 08:37:44 UTC 2012


Hi Guys - comment inline may be helpful:

On 04/12/12 18:26, Matt Wagner wrote:
> On Mon, Dec 03, 2012 at 04:26:53PM +0000, Gavin Adams wrote:
>> Hi,
>>
>> I'm going though the most recent testing version Aeolus attempting to get a connection to our OpenStack cloud platform. I've installed aeolus-all from the testing repo, along with the deltacloud packages. I can use irb to connect to the launched daemon and successfully get responses back from our platform.
> 
> Hi Gavin,
> 
> Thanks for trying Aeolus! :)
> 
> OpenStack support is actually something we're working on implementing
> now. I had looked into this a few months ago, but it was largely blocked
> on us not being able to build/push/import images to OpenStack.
> 
> Recently, Image Factory 2.0 was released, which added OpenStack support.
> We're actively integrating support for this into Conductor (through a
> new component, Tim[1]). I'm secretly hoping this will all be working by
> the end of the month. Once that starts to firm up into something usable,
> I'd be more than happy to work with you to test this in the wild.
> 
>> However, once configuring aeolus (ec2,mock) and tring to add a new provider, I get the same error mentioned back in a July thread:
>>
>> Cannot add the provider.
>> 1 error prohibited this Provider from being saved
>> Url translation missing: en.activerecord.errors.models.provider.attributes.url.invalid_framework
> 
> As Firefox says when it starts after an unclean exit, "Well, this is
> embarrassing." Conductor hit an error ("translation missing") trying to
> show you the error it encountered. The invalid_framework error, though,
> comes up when it hits an unexpected exception talking to Deltacloud.
> 
>> The deltacloudd logs the standard 401 message (this is before credentials are created):
>>
>> 127.0.0.1 - - [03/Dec/2012 10:52:52] "GET /api HTTP/1.1" 401 - 0.0073
> 
> I'm a little confused by this one, though this isn't an area of the code
> I work on, so it's slightly unfamiliar territory for me. The fact that
> it occurs before you're able to save the Provider is a little
> confounding, since I didn't think any credentials were required at this
> point.

Deltacloud Openstack driver requires credentials for accessing the entry
point @ /api - i.e. requires credentials for any request. The reason
this was done is because for Openstack, we need to check which services
the given Openstack provider has deployed so we can expose the
appropriate collections for Deltacloud. That is, if swift is deployed,
we expose /buckets at the /api entry point, if cinder/volume service
deployed we expose the storage_volumes collection etc. The only way to
do this is to make the authenticated request for the Openstack service
catalog and check. You can see where/when this was implemented here
https://issues.apache.org/jira/browse/DTACLOUD-316

The 'openstack driver requires credentials for any request' was picked
up by one of the Aeolus team back in September - the issue report is at
https://issues.apache.org/jira/browse/DTACLOUD-330 - I'm not sure if
this is what you're seeing here. I had thought we resolved this to the
point that it can be picked up on Aeolus side - but not sure - let us
know what you need to be done if this is not the case


hope that at least helps clarify/move this along, marios


> 
> Restarting deltacloudd with the --verbose flag may get you some more
> useful information here. Though I must confess that if you clear this
> hurdle you'll likely soon run into the bits we're still working on.
> 
>> I followed the recommendations to get aeolus updated, but still getting this error. Here's the list of current packages installed:
>>
>> [gadams at cloudmgr nodes]$ rpm -qa | grep 'aeolus\|delta'|sort
>> aeolus-all-0.10.6-1.fc17.noarch
>> aeolus-conductor-0.10.6-1.fc17.noarch
>> aeolus-conductor-daemons-0.10.6-1.fc17.noarch
>> aeolus-conductor-doc-0.10.6-1.fc17.noarch
>> aeolus-configure-2.6.1-1.fc17.noarch
>> deltacloud-core-1.0.5-1.fc17.noarch
>> deltacloud-core-ec2-1.0.5-1.fc17.noarch
>> deltacloud-core-openstack-1.0.5-1.fc17.noarch
>> deltacloud-core-rhevm-1.0.5-1.fc17.noarch
>> deltacloud-core-vsphere-1.0.5-1.fc17.noarch
>> deltarpm-3.6-0.7.20110223git.fc17.x86_64
>> python-deltarpm-3.6-0.7.20110223git.fc17.x86_64
>> rubygem-aeolus-cli-0.5.0-1.fc17.noarch
>> rubygem-aeolus-image-0.5.0-1.fc17.noarch
>> rubygem-deltacloud-client-1.0.4-1.fc17.noarch
>>
>> I am completely new to aeolus, so didn't want to open a ticket if there is a configuration issue I'm missing vs. a functionality issue.
> 
> While I'm not sure about the specific error you're encountering, there
> is indeed an overall functionality issue here as we work to finish up
> proper OpenStack support. I'm hoping it's something that will be in
> place relatively soon, though -- a few of us are working now on getting
> Tim and Image Factory 2.0 working with Conductor, and then it should
> (knock on wood!) be as simple as knocking out a couple of the bumps in
> the road I noted in my ancient blog post[2] on the matter.
> 
> If the present incompleteness isn't too repulsive, I'd be happy to keep
> you in the loop as we work on this. It would certainly be beneficial to
> be able to test this on a 'real' OpenStack setup, versus me testing it
> against a single OpenStack box on my LAN.
> 
> -- Matt
> 
> 
> [1] https://github.com/aeolus-incubator/tim
> [2] http://ma.ttwagner.com/aeolus-and-openstack-todays-status/
> 



More information about the aeolus-devel mailing list