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