Open Stack

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> 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>> 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
> > >
> >
> >
> > _______________________________________________
> > 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/20140124/905ecf52/attachment.html>