Open Stack

Matt, thanks for catching this.

BTW That's an interesting idea of supporting different tenants.


On Fri, Jan 24, 2014 at 11:04 PM, Matthew Farrellee <matt at redhat.com> wrote:

> thanks for all the feedback folks.. i've registered a bp for this...
>
> https://blueprints.launchpad.net/savanna/+spec/swift-url-proto-cleanup
>
>
> On 01/24/2014 11:30 AM, Sergey Lukjanov wrote:
>
>> Looks like we need to review prefixes and cleanup them. After the first
>> look I'd like the idea of using common prefix for swift data.
>>
>>
>> On Fri, Jan 24, 2014 at 7:05 PM, Trevor McKay <tmckay at redhat.com
>> <mailto:tmckay at redhat.com>> wrote:
>>
>>     Matt et al,
>>
>>        Yes, "swift-internal" was meant as a marker to distinguish it from
>>     "swift-external" someday. I agree, this could be indicated by setting
>>     other fields.
>>
>>     Little bit of implementation detail for scope:
>>
>>        In the current EDP implementation, SWIFT_INTERNAL_PREFIX shows up
>> in
>>     essentially two places.  One is validation (pretty easy to change).
>>
>>        The other is in Savanna's binary_retrievers module where, as others
>>     suggested, the auth url (proto, host, port, api) and admin tenant from
>>     the savanna configuration are used with the user/passw to make a
>>     connection through the swift client.
>>
>>        Handling of different types of job binaries is done in
>>     binary_retrievers/dispatch.py, where the URL determines the treatment.
>>     This could easily be extended to look at other indicators.
>>
>>     Best,
>>
>>     Trev
>>
>>     On Fri, 2014-01-24 at 07:50 -0500, Matthew Farrellee 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
>>     <matt at redhat.com <mailto:matt at redhat.com>
>>      > > <mailto: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>>
>>      > >         <mailto: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.
>>     <mailto:OpenStack-dev at lists.>__openstack.org <http://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
>>     <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
>>     <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
>>      > >
>>      >
>>      >
>>      > _______________________________________________
>>      > 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
>>
>>
>>
>>     _______________________________________________
>>     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
>>
>>
>>
>>
>> --
>> Sincerely yours,
>> Sergey Lukjanov
>> Savanna Technical Lead
>> Mirantis Inc.
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> 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
>



-- 
Sincerely yours,
Sergey Lukjanov
Savanna Technical Lead
Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140128/55605268/attachment.html>