Open Stack

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 <matt at redhat.com
> <mailto:matt at redhat.com>> 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
>         <matt at redhat.com <mailto:matt at redhat.com>
>         <mailto:matt at redhat.com <mailto:matt at redhat.com>>> 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
>              OpenStack-dev at lists.openstack.____org
>              <mailto:OpenStack-dev at lists.__openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>>
>         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
>         OpenStack-dev at lists.openstack.__org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
>         <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>