Hi Eran and Kota,
> For temprary, that would work but I thought we could (*not sure*) fix the > issue just replace the order of pipeline, right? (i.e. storlets handler > should be the left of copy middleware) That is because the storlets middlware > have the logic to translate COPY/PUT(X-COPY-FROM) into GET(no storelets > running)/PUT(execute at Proxy). If it happens before the request reaching to > copy middleware, it looks like just PUT or GET at copy middleware itself (so > nothing to oparate there). I agree with Kota, and I think this is the easiest way to fix the problem. On the other hand, it's not efficient that Storlets has its original implementation about COPY inside it, which is very similar to copy middleware. As we discussed at Bristol, we had better make Storlets get rid of its original implementation and reuse ServerSideComyMiddleware or ServerSideCopyWebContext in copy middleware, to reduce that duplicated work, as the next step. # I need a deep dive about copy middleware patch, now. > I believe that for Storlets what would happen is that both PUT and GET > cause a storlet invocation, where in fact we want that invocation to > happen Eithrer in the GET or in the PUT (but not both) I believe that > if we are OK with running the storlet on the put, we can use The > swift_source SSC as an indicator that the get is generated from the > Copy middleware and disregard the X-Run-Storlet header. I also like this idea, if possible. Dealing with COPY only in the one point (in copy middleware) looks better, because it enables us to maintain the functionality more easily. Thanks, Takashi -----Original Message----- From: Kota TSUYUZAKI [mailto:tsuyuzaki.k...@lab.ntt.co.jp] Sent: Monday, May 16, 2016 9:25 AM To: OpenStack Development Mailing List (not for usage questions) <openstack-dev@lists.openstack.org> Subject: Re: [openstack-dev] [Storlets] Swift copy middlleware Hey Eran, This is what I was concerning in Bristol Hackathon :/ > As a quick and temporary resolution I have changes the tox.ini > dependency to be 2.7.0 Instead of master. We still need, however, to > port the code accordingly, For temprary, that would work but I thought we could (*not sure*) fix the issue just replace the order of pipeline, right? (i.e. storlets handler should be the left of copy middleware) That is because the storlets middlware have the logic to translate COPY/PUT(X-COPY-FROM) into GET(no storelets running)/PUT(execute at Proxy). If it happens before the request reaching to copy middleware, it looks like just PUT or GET at copy middleware itself (so nothing to oparate there). I'll start to make sure my thought in this week but thanks to raise a flag to the community :) Thanks, Kota (2016/05/16 3:42), Eran Rom wrote: > Today the Swift team has merged copy middleware - congrats! > For us, however, it breaks the copy code path, which in fact can get > much simpler now. > > As a quick and temporary resolution I have changes the tox.ini > dependency to be 2.7.0 Instead of master. We still need, however, to > port the code accordingly, > > Here is a suggestion: > The copy middleware will process the COPY / PUT & X-Copy-From and will: > 1. Do a GET of the source object > 2. Do a PUT to the target object > > I believe that for Storlets what would happen is that both PUT and GET > cause a storlet invocation, where in fact we want that invocation to > happen Eithrer in the GET or in the PUT (but not both) I believe that > if we are OK with running the storlet on the put, we can use The > swift_source SSC as an indicator that the get is generated from the > Copy middleware and disregard the X-Run-Storlet header. > > Thoughts? > > Thanks, > Eran > > > > > > ______________________________________________________________________ > ____ OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
