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 <m...@redhat.com
<mailto:m...@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
        <m...@redhat.com <mailto:m...@redhat.com>
        <mailto:m...@redhat.com <mailto:m...@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@lists.openstack.____org
             <mailto:OpenStack-dev@lists.__openstack.org
        <mailto:OpenStack-dev@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@lists.openstack.__org
        <mailto:OpenStack-dev@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@lists.openstack.__org
    <mailto:OpenStack-dev@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@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

Reply via email to