<div dir="ltr">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.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 24, 2014 at 7:05 PM, Trevor McKay <span dir="ltr"><<a href="mailto:tmckay@redhat.com" target="_blank">tmckay@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Matt et al,<br>
<br>
Yes, "swift-internal" was meant as a marker to distinguish it from<br>
"swift-external" someday. I agree, this could be indicated by setting<br>
other fields.<br>
<br>
Little bit of implementation detail for scope:<br>
<br>
In the current EDP implementation, SWIFT_INTERNAL_PREFIX shows up in<br>
essentially two places. One is validation (pretty easy to change).<br>
<br>
The other is in Savanna's binary_retrievers module where, as others<br>
suggested, the auth url (proto, host, port, api) and admin tenant from<br>
the savanna configuration are used with the user/passw to make a<br>
connection through the swift client.<br>
<br>
Handling of different types of job binaries is done in<br>
binary_retrievers/dispatch.py, where the URL determines the treatment.<br>
This could easily be extended to look at other indicators.<br>
<br>
Best,<br>
<br>
Trev<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, 2014-01-24 at 07:50 -0500, Matthew Farrellee wrote:<br>
> andrew,<br>
><br>
> what about having swift:// which defaults to the configured tenant and<br>
> auth url for what we now call swift-internal, and we allow for user<br>
> input to change tenant and auth url for what would be swift-external?<br>
><br>
> in fact, we may need to add the tenant selection in icehouse. it's a<br>
> pretty big limitation to only allow a single tenant.<br>
><br>
> best,<br>
><br>
><br>
> matt<br>
><br>
> On 01/23/2014 11:15 PM, Andrew Lazarev wrote:<br>
> > Matt,<br>
> ><br>
> > For swift-internal we are using the same keystone (and identity protocol<br>
> > version) as for savanna. Also savanna admin tenant is used.<br>
> ><br>
> > Thanks,<br>
> > Andrew.<br>
> ><br>
> ><br>
> > On Thu, Jan 23, 2014 at 6:17 PM, Matthew Farrellee <<a href="mailto:matt@redhat.com">matt@redhat.com</a><br>
> > <mailto:<a href="mailto:matt@redhat.com">matt@redhat.com</a>>> wrote:<br>
> ><br>
> > what makes it internal vs external?<br>
> ><br>
> > swift-internal needs user & pass<br>
> ><br>
> > swift-external needs user & pass & ?auth url?<br>
> ><br>
> > best,<br>
> ><br>
> ><br>
> > matt<br>
> ><br>
> > On 01/23/2014 08:43 PM, Andrew Lazarev wrote:<br>
> ><br>
> > Matt,<br>
> ><br>
> > I can easily imagine situation when job binaries are stored in<br>
> > external<br>
> > HDFS or external SWIFT (like data sources). Internal and<br>
> > external swifts<br>
> > are different since we need additional credentials.<br>
> ><br>
> > Thanks,<br>
> > Andrew.<br>
> ><br>
> ><br>
> > On Thu, Jan 23, 2014 at 5:30 PM, Matthew Farrellee<br>
> > <<a href="mailto:matt@redhat.com">matt@redhat.com</a> <mailto:<a href="mailto:matt@redhat.com">matt@redhat.com</a>><br>
> > <mailto:<a href="mailto:matt@redhat.com">matt@redhat.com</a> <mailto:<a href="mailto:matt@redhat.com">matt@redhat.com</a>>>> wrote:<br>
> ><br>
> > trevor,<br>
> ><br>
> > job binaries are stored in swift or an internal savanna db,<br>
> > represented by swift-internal:// and savanna-db://<br>
> > respectively.<br>
> ><br>
> > why swift-internal:// and not just swift://?<br>
> ><br>
> > fyi, i see mention of a potential future version of savanna w/<br>
> > swift-external://<br>
> ><br>
> > best,<br>
> ><br>
> ><br>
> > matt<br>
> ><br>
> > ___________________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.____org<br>
> > <mailto:<a href="mailto:OpenStack-dev@lists.">OpenStack-dev@lists.</a>__<a href="http://openstack.org" target="_blank">openstack.org</a><br>
> > <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>>><br>
> > <a href="http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-dev" target="_blank">http://lists.openstack.org/____cgi-bin/mailman/listinfo/____openstack-dev</a><br>
> > <<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev</a>><br>
> > <<a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev</a><br>
> > <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>>><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _________________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.__org<br>
> > <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> > <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev</a><br>
> > <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
> ><br>
> ><br>
> ><br>
> > _________________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.__org<br>
> > <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>><br>
> > <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
> ><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>Sincerely yours,</div><div>Sergey Lukjanov</div><div>Savanna Technical Lead</div><div>Mirantis Inc.</div></div>
</div>