Please pick up my OpenStack task!

Jason Guiditta jguiditt at redhat.com
Thu Sep 27 14:21:40 UTC 2012


On 27/09/12 10:53 +0200, Jan Provazník wrote:
>On 09/24/2012 05:04 PM, Jan Provaznik wrote:
>>On 09/21/2012 11:00 PM, Matt Wagner wrote:
>>>Hi folks,
>>>
>>
<snip>
>
>One more  bad news which I missed before because I was still on 
>deltacloud-1.0.3:
>new Deltacloud (>1.0.3) requires account credentials when doing any 
>openstack connect. This means that openstack provider can't be added 
>because test connection, which we do to make sure that a provider is 
>accessible, always fails because of msising credentials.
>
>I've filled a dc-bug for this:
>https://issues.apache.org/jira/browse/DTACLOUD-330
>
>I hope Dc guys could change the behavour, if not we would have to 
>probably disable connection checking for openstack.
>
>Jan

I am pretty sure michal or marios said this is an openstack
requirement, not deltacloud.  IOW, going to just '/api' of openstack
requires a password.  This led to an irc discussion of how conductor
should handle this.  The 2 ideas I recall (probably because I thought
they were among better options) were:

1) When adding a new provider, include in that form an account form as
well.  This could optionally be required only if a given provider is
an 'auth-only' kind of api (which would probably be some field on
providerType).

2) Show validation status in provider list, but do not fail conductor
object creation.  Add a validated boolean field, and possibly a
provider_message or similar field, where any error returned from dc
can be placed.  This would tell the user that, for instance
'validation failed due to auth required by provider'.

I am unsure if deltacloud provides a way to ask if a given driver
requires auth for all of the api, or if they expect the caller to just
attempt to contact some endpoint and determine auth needed based on
the challenge/auth fail error.  Either could be used really, just a
matter of preference and seeing what is available.

-j



More information about the aeolus-devel mailing list