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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev