[openstack-dev] [Sahara] Swift authentication and backwards compatibility

mike mccune mimccune at redhat.com
Fri Aug 15 14:04:29 UTC 2014

thanks for the thoughts Trevor,

On 08/15/2014 09:32 AM, Trevor McKay wrote:
> I think backward compatibility is a good idea.  We can make the
> user/pass inputs for data objects optional (they are required
> currently), maybe even gray them out in the UI with a checkbox to turn
> them on, or something like that.

This is similar to what I was thinking. We would allow the username and 
password inputs to accept a blank input.

I also like the idea of giving some sort of visual reference, like 
graying out the fields.

> Sahara can detect whether or not the proxy domain is there, and whether
> or not it can be created.  If Sahara ends up in a situation where it
> thinks user/pass are required, but the data objects don't have them,
> we can return a meaningful error.

I think it sounds like we are going to avoid having Sahara attempt to 
create a domain. It will be the duty of a stack administrator to create 
the domain and give it's name in the sahara.conf file.

Agreed about meaning errors.

> The job manager can key off of the values supplied for the data source
> objects (no user/pass? must be proxy) and/or cluster configs (for
> instance, a new cluster config could be added -- if it's absent we
> assume "old" cluster and therefore old hadoop swfit plugin).  Workflow
> can be generated accordingly.

This sounds good. If there is some way to determine the version of the 
hadoop-swiftfs on the cluster that would be ideal.

> The hadoop swift plugin can look at the config values provided, as you
> noted yesterday, and get auth tokens in either manor.



More information about the OpenStack-dev mailing list