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

Reply via email to