>what about having swift:// which defaults to the configured tenant and auth url for what we now call swift-internal, and we allow for user input to change tenant and auth url for what would be swift-external?
I like the proposal. Andrew. On Fri, Jan 24, 2014 at 4:50 AM, Matthew Farrellee <[email protected]> wrote: > andrew, > > what about having swift:// which defaults to the configured tenant and > auth url for what we now call swift-internal, and we allow for user input > to change tenant and auth url for what would be swift-external? > > in fact, we may need to add the tenant selection in icehouse. it's a > pretty big limitation to only allow a single tenant. > > best, > > > matt > > On 01/23/2014 11:15 PM, Andrew Lazarev wrote: > >> Matt, >> >> For swift-internal we are using the same keystone (and identity protocol >> version) as for savanna. Also savanna admin tenant is used. >> >> Thanks, >> Andrew. >> >> >> On Thu, Jan 23, 2014 at 6:17 PM, Matthew Farrellee <[email protected] >> <mailto:[email protected]>> wrote: >> >> what makes it internal vs external? >> >> swift-internal needs user & pass >> >> swift-external needs user & pass & ?auth url? >> >> best, >> >> >> matt >> >> On 01/23/2014 08:43 PM, Andrew Lazarev wrote: >> >> Matt, >> >> I can easily imagine situation when job binaries are stored in >> external >> HDFS or external SWIFT (like data sources). Internal and >> external swifts >> are different since we need additional credentials. >> >> Thanks, >> Andrew. >> >> >> On Thu, Jan 23, 2014 at 5:30 PM, Matthew Farrellee >> <[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> wrote: >> >> trevor, >> >> job binaries are stored in swift or an internal savanna db, >> represented by swift-internal:// and savanna-db:// >> respectively. >> >> why swift-internal:// and not just swift://? >> >> fyi, i see mention of a potential future version of savanna >> w/ >> swift-external:// >> >> best, >> >> >> matt >> >> ___________________________________________________ >> OpenStack-dev mailing list >> [email protected].____org >> <mailto:OpenStack-dev@lists.__openstack.org >> <mailto:[email protected]>> >> http://lists.openstack.org/____cgi-bin/mailman/listinfo/____ >> openstack-dev >> <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__ >> openstack-dev> >> <http://lists.openstack.org/__cgi-bin/mailman/listinfo/__ >> openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/ >> openstack-dev>> >> >> >> >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__ >> openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/ >> openstack-dev> >> >> >> >> _________________________________________________ >> OpenStack-dev mailing list >> [email protected].__org >> <mailto:[email protected]> >> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev< >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
