Open Stack

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
>