Open Stack

Thoughts, rapidfire :)

In short, I think we should plan on backward compat unless some stubborn
technical problem gets in our way ....

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.

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.

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.

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

Best,

Trev


On Thu, 2014-08-14 at 22:20 -0400, Michael McCune wrote:
> hello Sahara folks,
> 
> I am working to get the revamped spec[1] finalized and I'd like to know the group's thoughts on the idea of backward compatibility. It is possible to implement the new authentication method and remain backward compatible, but we will need to keep the username and password inputs in the Swift data forms.
> 
> Having the backward compatibility would also give Sahara a way to react in situations where the proxy domain is not available or the administrator doesn't wish to use it. I'm not sure this is the behavior we want, but I don't know if it is proper for Sahara to exit if no proxy domain can be found.
> 
> If we choose not to remain backward compatible then we are requiring Sahara operators to create the new proxy domain needed, and they must update all virtual machine images.
> 
> Thoughts?
> 
> regards,
> mike
> 
> [1]: https://review.openstack.org/#/c/113591/
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev