[openstack-dev] storlets 2.0.0.0rc1 (rocky)

[no-reply]

Hello everyone,

A new release candidate for storlets for the end of the Rocky
cycle is available!  You can find the source code tarball at:

https://tarballs.openstack.org/storlets/

Unless release-critical issues are found that warrant a release
candidate respin, this candidate will be formally released as the
final Rocky release. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/rocky release
branch at:

http://git.openstack.org/cgit/openstack/storlets/log/?h=stable/rocky

Release notes for storlets can be found at:

http://docs.openstack.org/releasenotes/storlets/




__
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-dev] [storlets] No team meeting today

[Eran Rom]

Hi All,
There will be no team meeting today.
As usual, if you have something please ping at #openstack-storlets

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

Re: [openstack-dev] [storlets][mascot] mascot for the storlets project

[Doron Chen]

I like it too!
Doron



From:   Eran Rom 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   23/04/2017 08:41 PM
Subject:[openstack-dev] [storlets][mascot] mascot for the storlets 
project



Hi All,
Any feedbacks?
Personally I like it.

Thanks,
Eran

Begin forwarded message:

From: Heidi Joy Tretheway 
Subject: Re: mascot for the storlets project
Date: April 22, 2017 at 1:14:27 AM GMT+3
To: Eran Rom 

Hi Eran, 

I took your feedback on the storklet to our illustrators and they came up 
with this revised version. Would you please let me know what your team 
thinks? 


On Feb 28, 2017, at 11:52 AM, Heidi Joy Tretheway  
wrote:

Hi Eran, 

Thank you so much! These are great pictures to give me an idea of what a 
stork let should look like. I?ll share both with our illustration team. 

Best,
Heidi Joy

On Feb 28, 2017, at 11:43 AM, Eran Rom  wrote:

Heidi Hi,
In the PTG our team has chose ?storklet? as a mascot.
I was not aware until recently that there is such a word, and that it is 
the stork chick.

Here is a couple of nice stoklet pictures I have found:
http://www.arkive.org/marabou-stork/leptoptilos-crumeniferus/image-G69355.html 
(A marabou storklet )
http://www.daufuskieislandconservancy.org/index.php?page=wood-stork (A 
wood stork storklet)

Thanks very much!
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

Re: [openstack-dev] [storlets][mascot] mascot for the storlets project

[Matthew Oliver]

Looks cool, I'd stick it on my laptop :)

On Mon, Apr 24, 2017 at 4:43 PM,  wrote:

> +1
>
> Looks so nice to me!
>
> Thanks for the great illustration, Heidi!
>
>
>
>
>
> Thank you,
>
> Takashi
>
>
>
> *From:* Eran Rom [mailto:e...@itsonlyme.name]
> *Sent:* Monday, April 24, 2017 2:35 AM
> *To:* OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> *Subject:* [openstack-dev] [storlets][mascot] mascot for the storlets
> project
>
>
>
> Hi All,
>
> Any feedbacks?
>
> Personally I like it.
>
>
>
> Thanks,
>
> Eran
>
>
>
> Begin forwarded message:
>
>
>
> *From: *Heidi Joy Tretheway 
>
> *Subject: Re: mascot for the storlets project*
>
> *Date: *April 22, 2017 at 1:14:27 AM GMT+3
>
> *To: *Eran Rom 
>
>
>
> Hi Eran,
>
>
>
> I took your feedback on the storklet to our illustrators and they came up
> with this revised version. Would you please let me know what your team
> thinks?
>
>
>
> On Feb 28, 2017, at 11:52 AM, Heidi Joy Tretheway 
> wrote:
>
>
>
> Hi Eran,
>
> Thank you so much! These are great pictures to give me an idea of what a
> stork let should look like. I’ll share both with our illustration team.
>
> Best,
> Heidi Joy
>
>
> On Feb 28, 2017, at 11:43 AM, Eran Rom  wrote:
>
> Heidi Hi,
> In the PTG our team has chose ’storklet’ as a mascot.
> I was not aware until recently that there is such a word, and that it is
> the stork chick.
>
> Here is a couple of nice stoklet pictures I have found:
> http://www.arkive.org/marabou-stork/leptoptilos-
> crumeniferus/image-G69355.html (A marabou storklet )
> http://www.daufuskieislandconservancy.org/index.php?page=wood-stork (A
> wood stork storklet)
>
> Thanks very much!
> 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

Re: [openstack-dev] [storlets][mascot] mascot for the storlets project

[kajinamit]

+1
Looks so nice to me!
Thanks for the great illustration, Heidi!


Thank you,
Takashi

From: Eran Rom [mailto:e...@itsonlyme.name]
Sent: Monday, April 24, 2017 2:35 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [storlets][mascot] mascot for the storlets project

Hi All,
Any feedbacks?
Personally I like it.

Thanks,
Eran


Begin forwarded message:

From: Heidi Joy Tretheway 
mailto:heidi...@openstack.org>>
Subject: Re: mascot for the storlets project
Date: April 22, 2017 at 1:14:27 AM GMT+3
To: Eran Rom mailto:e...@itsonlyme.name>>

Hi Eran,

I took your feedback on the storklet to our illustrators and they came up with 
this revised version. Would you please let me know what your team thinks?
[cid:image001.png@01D2BD11.8A6D7A90]

On Feb 28, 2017, at 11:52 AM, Heidi Joy Tretheway 
mailto:heidi...@openstack.org>> wrote:

Hi Eran,

Thank you so much! These are great pictures to give me an idea of what a stork 
let should look like. I’ll share both with our illustration team.

Best,
Heidi Joy


On Feb 28, 2017, at 11:43 AM, Eran Rom 
mailto:e...@itsonlyme.name>> wrote:

Heidi Hi,
In the PTG our team has chose ’storklet’ as a mascot.
I was not aware until recently that there is such a word, and that it is the 
stork chick.

Here is a couple of nice stoklet pictures I have found:
http://www.arkive.org/marabou-stork/leptoptilos-crumeniferus/image-G69355.html 
(A marabou storklet )
http://www.daufuskieislandconservancy.org/index.php?page=wood-stork (A wood 
stork storklet)

Thanks very much!
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-dev] [storlets] Proposing a new meeting time for this week

[Eran Rom]

Hi all,
We have not met for quite some time, and unfortunately, I cannot make it this 
week as well.
Any chance Wed April 26th 08:00UTC. works for you as am alternative time.
Otherwise, you can make the meeting without me.

Best,
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-dev] [storlets][mascot] mascot for the storlets project

[Eran Rom]

Hi All,
Any feedbacks?
Personally I like it.

Thanks,
Eran

> Begin forwarded message:
> 
> From: Heidi Joy Tretheway 
> Subject: Re: mascot for the storlets project
> Date: April 22, 2017 at 1:14:27 AM GMT+3
> To: Eran Rom 
> 
> Hi Eran, 
> 
> I took your feedback on the storklet to our illustrators and they came up 
> with this revised version. Would you please let me know what your team 
> thinks? 
> 
> 
>> On Feb 28, 2017, at 11:52 AM, Heidi Joy Tretheway > > wrote:
>> 
>> Hi Eran, 
>> 
>> Thank you so much! These are great pictures to give me an idea of what a 
>> stork let should look like. I’ll share both with our illustration team. 
>> 
>> Best,
>> Heidi Joy
>> 
>>> On Feb 28, 2017, at 11:43 AM, Eran Rom >> > wrote:
>>> 
>>> Heidi Hi,
>>> In the PTG our team has chose ’storklet’ as a mascot.
>>> I was not aware until recently that there is such a word, and that it is 
>>> the stork chick.
>>> 
>>> Here is a couple of nice stoklet pictures I have found:
>>> http://www.arkive.org/marabou-stork/leptoptilos-crumeniferus/image-G69355.html
>>>  
>>> 
>>>  (A marabou storklet )
>>> http://www.daufuskieislandconservancy.org/index.php?page=wood-stork 
>>>  (A 
>>> wood stork storklet)
>>> 
>>> Thanks very much!
>>> 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-dev] [storlets] Storlet meetings today and in the next two weeks

[Eran Rom]

Hi All,
As these are holidays in Israel i will not be able to make it today and in the 
next two weeks.
Feel free to hold the meetings without me. Just coordinate via the mailing list 
so that others can join.

If there is anything you would like to discuss. please ping on IRC in 
#openstack-storlets which I will be monitoring.
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

Re: [openstack-dev] [storlets] Mascot request

[Eran Rom]

Heidi,
Thanks very much for the draft.
The mascot is awesome. I guess I am struggling with how to distinguish a stork 
from a storklet: The mascot looks more like a stork.
I think that what distinguishes a stork chick from other similar chicks (of 
e.g. herons / gannets / ) is the long and thick beak, and not necessarily the 
legs.

Just playing with an idea: How about adding an egg like in the below picture 
replacing the chick with something that has a long neck and thick long beak as 
in the original mascot? or as in one of the original photos 
(http://www.arkive.org/marabou-stork/leptoptilos-crumeniferus/image-G69355.html 
)

Thoughts?
Thanks very much,
Eran



 


> On Mar 10, 2017, at 6:32 PM, Heidi Joy Tretheway  
> wrote:
> 
> Hi Storlets team, 
> 
> Your team selected a storklet as a project mascot, and our illustrators 
> developed this draft. While you sent us a picture of a nesting storklet 
> (where we couldn’t see the legs), the illustrator thought showing the legs 
> would best help distinguish this as a storklet from other birds. Feel free to 
> send feedback my way!
> 
> 
> 
>
> __
> 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-dev] [storlets] Mascot request

[Heidi Joy Tretheway]

Hi Storlets team, 

Your team selected a storklet as a project mascot, and our illustrators 
developed this draft. While you sent us a picture of a nesting storklet (where 
we couldn’t see the legs), the illustrator thought showing the legs would best 
help distinguish this as a storklet from other birds. Feel free to send 
feedback my way!



   __
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-dev] [storlets] PTG summary

[Eran Rom]

Hi,
I have wrote a summary for the discussions we had in the Etherpad [1]
there is a summary section under each of the topics.

Otherwise, I will not be able to attend the meeting this Tuesday
as I will be on a flight back from the US.

Thanks,
Eran

[1] https://etherpad.openstack.org/p/storlets-pike-design-summit

__
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

Re: [openstack-dev] [storlets][swift][mascot] Storlets mascot

[Doron Chen]

Hi,
Of these five options, I like sloth the best.
Please also consider the stork -- the closest-sounding animal.
Storklets...
Doron



From:   Eran Rom 
To: "OpenStack Development Mailing List (not for usage questions)" 

Date:   16/02/2017 11:11 AM
Subject:[openstack-dev] [storlets][swift][mascot] Storlets mascot



So the hard work getting into the big-tent was worth it!

While the storlets team should have the final word, I will be very happy 
if the Swift community helped us in the process.

Below are few options I have thought about.
Comments / other suggestions are mostly welcome!

Thanks very much,
Eran

1. Hummingbird. Works hard to stay put in the air. Storlets make the CPU 
to work so that data stays in place (and its a bird) Is that a conflict 
with the go-lang effort?
2. Sloth. Does not move much. Storlets aim at not moving the data
3. Thinking Monkey (as e.g. here: 
https://philosaccounting.com/a/humor/thinkers-anonymous/). We all want to 
look smart.
4. Bat upside down. Bring the compute to the data rather then the other 
way around.
5. pied stilt (see e.g. http://nzbirdsonline.org.nz/species/pied-stilt). 
For its elegance :-) (and for being a bird)
__
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-dev] [storlets][swift][mascot] Storlets mascot

[Eran Rom]

So the hard work getting into the big-tent was worth it!

While the storlets team should have the final word, I will be very happy if the 
Swift community helped us in the process.

Below are few options I have thought about.
Comments / other suggestions are mostly welcome!

Thanks very much,
Eran

1. Hummingbird. Works hard to stay put in the air. Storlets make the CPU to 
work so that data stays in place (and its a bird) Is that a conflict with the 
go-lang effort?
2. Sloth. Does not move much. Storlets aim at not moving the data
3. Thinking Monkey (as e.g. here: 
https://philosaccounting.com/a/humor/thinkers-anonymous/). We all want to look 
smart.
4. Bat upside down. Bring the compute to the data rather then the other way 
around.
5. pied stilt (see e.g. http://nzbirdsonline.org.nz/species/pied-stilt). For 
its elegance :-) (and for being a bird)
__
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

Re: [openstack-dev] [storlets] ocata branch

[Eran Rom]

Apologies for the date confusion in the below mail.
This should happen on the week of the 13th, and clearly we need to base our 
branch on Swift’s Ocata branch.

> On Feb 1, 2017, at 10:37 AM, Eran Rom  wrote:
> 
> Hi all,
> I will create the stable/ocata branch tomorrow my end of day.
> Would be great if we can land the python functional tests.
> 
> 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-dev] [storlets] Boston OpenStack Summit presentation

[Eran Rom]

Dear storleters,
As the deadline approaches I was thinking about the following idea:

End-to-End deep learning with OpenStack Storlets

Imagine that you have a huge dataset from which you could extract  
information using machine learning algorithms. The problem is that  
datasets usually need to go through a long and tedious curing and  
pre-processing before they can be 'presented' to machine learning  
algorithm. With large dataset this can get really painful. In this  
talk we present how storlets can be used to do an end-to-end  
supervised deep learning, thus processing all the data 'in-place'  
saving huge amounts of BW. As an example We show face recognition that  
starts with off-the-camera jpegs. This involves the following steps:


1. find the face bounding box
2. extract the face part
3. resize to a pre-defined resolution
4. change to greyscale
5. transform into a matrix that can be presented to a learning algorithm
6. train the algorithm over a large training set

We show that all steps can be done using storlets from within a  
Jupyter notebook.



Anyone who is interested in taking part please let me know.
Also, this is just an initial suggestion, feel free to suggest other  
examples or ideas.


Best,
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-dev] [storlets]

[Eran Rom]

Hi all,
I will create the stable/ocata branch tomorrow my end of day.
Would be great if we can land the python functional tests.

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-dev] [storlets][ptl] PTL candidacy

[Eran Rom]

Hi All,

I have been leading the Storlets project from its infancy days as
a research project in IBM to its infancy days as a big-tent project :-)
This would not have been possible without the small yet top and seasoned
developers in our community.

There is still very much I would like to do:
Reach out to more users and hence to developers.
Expand on our use cases portfolio by developing a
rich echo system.
Continuously work on the project's maturity so that
it can be picked up by deployers, and last but not least
enjoy the spirit of open source while at it.

I believe that I can help driving the project to achieve all these
goals, and would be very happy to serve as the project's first PTL.

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-dev] [storlets] No IRC meeting today

[eran]

Dear Storleters,
First of all, happy new year!

I apologise by this late notice, but I got totally confused about the  
times and did not show up.

Since things have been slow in the past couple of weeks, I hope no harm done.

Please ping on IRC if you want to discuss anything.

Apologies!
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-dev] [storlets] End of year IRC team meetings

[eran]

Unless there is some objection we will skip next week's meeting and  
meet again on Tuesday January 3rd in the usual place and time.


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-dev] [storlets] Wrapping up big tent work

[eran]

Hi,
We need to go back to the TC.
As you can see in our big tent etherpad  
(https://etherpad.openstack.org/p/storlets-big-tent)

we basically need to merge the below patches:

https://review.openstack.org/409116 Fixing headers across all files
https://review.openstack.org/#/c/394168/ Kestone auth version to v3
https://review.openstack.org/#/c/394437/ Replacing nosetest with test

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-dev] [storlets] IRC meeting today

[eran]

Hi,
We will skip this week's meeting due to majority of members who cannot join.
Apologies for the late notice.

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

Re: [openstack-dev] [storlets] Towards becoming an official project team

[Doron Chen]

Hi All,
I support Eran's proposal to be PTL.
Good luck to us all in turning storlets into an official project.
Doron



From:   e...@itsonlyme.name
To: openstack-dev@lists.openstack.org
Date:   05/08/2016 03:32 PM
Subject:[openstack-dev] [storlets] Towards becoming an official 
project team



Hi All,
Before making the motion we need to pick a PTL.
I would like to propose myself for the coming period, that is
until the October Summit and for the cycle that begins in October.
If there are any objections / other volunteers please speak up :-)

Otherwise,
1. We now have an independent release (stable/mitaka) currently 
aligned with tag 0.2.0.
2. I have added some initial info to the wiki in: 
https://wiki.openstack.org/wiki/Storlets
and would like to use it for design thoughts. I will add there the 
security design as
soon as I am done with the Spark work.
4. I have updated the storlets driver team in Launchpad: 
https://launchpad.net/~storlets-drivers
3. The actual request for becoming an official team is to propose a 
patch to: 
https://github.com/openstack/governance/blob/master/reference/projects.yaml

please find below an initial suggestion for the patch. 
Comments/Suggestions are
mostly welcome!

Thanks!
Eran

storlets:
   ptl:
 name: Eran Rom
 irc: eranrom
 email: e...@itsonlyme.name
   irc-channel: openstack-storlets
   mission: >
 To enable a user friendly, cost effective scalable and secure way for
 executing storage centric user defined functions near the data within
 Openstack Swift
   url: https://wiki.openstack.org/wiki/Storlets
   tags:
 - team:diverse-affiliation
   deliverables:
 storlets:
   repos:
 - openstack/storlets
   tags:
 - release:independent
 - type: service-extension   <--- Not sure there is such a type...




__
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-dev] [storlets] Towards becoming an official project team

[eran]

Hi All,
Before making the motion we need to pick a PTL.
I would like to propose myself for the coming period, that is
until the October Summit and for the cycle that begins in October.
If there are any objections / other volunteers please speak up :-)

Otherwise,
1. We now have an independent release (stable/mitaka) currently  
aligned with tag 0.2.0.
2. I have added some initial info to the wiki in:  
https://wiki.openstack.org/wiki/Storlets
   and would like to use it for design thoughts. I will add there the  
security design as

   soon as I am done with the Spark work.
4. I have updated the storlets driver team in Launchpad:  
https://launchpad.net/~storlets-drivers
3. The actual request for becoming an official team is to propose a  
patch to:   
https://github.com/openstack/governance/blob/master/reference/projects.yaml
   please find below an initial suggestion for the patch.  
Comments/Suggestions are

   mostly welcome!

Thanks!
Eran

storlets:
  ptl:
name: Eran Rom
irc: eranrom
email: e...@itsonlyme.name
  irc-channel: openstack-storlets
  mission: >
To enable a user friendly, cost effective scalable and secure way for
executing storage centric user defined functions near the data within
Openstack Swift
  url: https://wiki.openstack.org/wiki/Storlets
  tags:
- team:diverse-affiliation
  deliverables:
storlets:
  repos:
- openstack/storlets
  tags:
- release:independent
- type: service-extension   <--- Not sure there is such a type...




__
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

Re: [openstack-dev] [storlets] IRC meeting times

[kajinamit]

Hi Eran,

08:00 UTC is good for me.
I'm ok with Tuesday.

Thank you,
Takashi

-Original Message-
From: e...@itsonlyme.name [mailto:e...@itsonlyme.name] 
Sent: Wednesday, July 20, 2016 2:28 AM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [storlets] IRC meeting times

Sure.
How about an hour later?
That is:
08:00 UTC
17:00 JST
11:00 IST

Also, are you ok with Tuesdays?

Quoting kajina...@nttdata.co.jp:

> Hi Eran,
>
>
> Thanks for your suggestion.
>
> Is it possible to make the meeting time one hour earlier (08:00 UTC) 
> or one hour later (09:00 UTC)?
>
> Thank you,
> Takashi
>
> -Original Message-
> From: e...@itsonlyme.name [mailto:e...@itsonlyme.name]
> Sent: Wednesday, July 13, 2016 10:35 PM
> To: openstack-dev@lists.openstack.org
> Subject: [openstack-dev] [storlets] IRC meeting times
>
> Hi,
> I would like to change the IRC meeting times to Tuesdays at 07:00AM 
> UTC
> That's:
> 16:00 JST
> 10:00 IST
>
> Any objections?
> 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
__
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

Re: [openstack-dev] [storlets] IRC meeting times

[eran]

Sure.
How about an hour later?
That is:
08:00 UTC
17:00 JST
11:00 IST

Also, are you ok with Tuesdays?

Quoting kajina...@nttdata.co.jp:


Hi Eran,


Thanks for your suggestion.

Is it possible to make the meeting time one hour earlier (08:00 UTC)  
or one hour later (09:00 UTC)?


Thank you,
Takashi

-Original Message-
From: e...@itsonlyme.name [mailto:e...@itsonlyme.name]
Sent: Wednesday, July 13, 2016 10:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [storlets] IRC meeting times

Hi,
I would like to change the IRC meeting times to Tuesdays at 07:00AM UTC
That's:
16:00 JST
10:00 IST

Any objections?
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

Re: [openstack-dev] [storlets] IRC meeting times

[kajinamit]

Hi Eran,


Thanks for your suggestion.

Is it possible to make the meeting time one hour earlier (08:00 UTC) or one 
hour later (09:00 UTC)?

Thank you,
Takashi

-Original Message-
From: e...@itsonlyme.name [mailto:e...@itsonlyme.name] 
Sent: Wednesday, July 13, 2016 10:35 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [storlets] IRC meeting times

Hi,
I would like to change the IRC meeting times to Tuesdays at 07:00AM UTC
That's:
16:00 JST
10:00 IST

Any objections?
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-dev] [storlets] IRC meeting times

[eran]

Hi,
I would like to change the IRC meeting times to Tuesdays at 07:00AM UTC
That's:
16:00 JST
10:00 IST

Any objections?
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-dev] [storlets] Starting storlets releases

[eran]

Hi,
Its high time we started to have storlet releases.
For one thing it will help us resolve the problem we face with the new  
COPY middleware: fixing this on master is not backward compatible.


Some random thoughts:
1. The releases will - at first - follow those of openstack, and the  
first release will be mitaka

2. A release will be a branch.
3. Future releases may include artifacts such as the common jar  
required for writing storlet, and perhaps a docker image on docker hub  
with s2aio allowing to test the storlet.


Here is the initial plan:
1. land the single range to run locally on object server
2. land the storlet request refactoring work done by Takashi.
3. update the install scripts and docs to use keystone v3.
4. create the mitaka branch.

Any comments/additions are mostly welcome.
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-dev] [storlets] changes to .functests

[eran]

Hi all,
patch https://review.openstack.org/#/c/334878/
introduces a (bonus) change to the functests.
The functests script need to get a flavour: jenkins | dev
the dev flavour skips slow tests such as 1GB PUT.
When invoked from tox it uses the jenkins flavour which executes everything.
this is implemented using python's unit test attributes.

Comments are welcome.
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

Re: [openstack-dev] [storlets] Docker images re-structuring

[kajinamit]

Hi Eran,


Thank you for bringing up a great idea.

> 1. Much easier to upgrade.
> 2. Less time from fix to test.
That's a big problem I experienced in my testing.
Storlet agent should be managed by infra operator side,
not by application developer side, as a part of infra software.

It's a little bit strange and hard work for system operators,
to ask all application developers to upgrade their container
when infra software is updated.

Your idea seems to show the appropriate way to go.

As I discussed with you in the last irc meeting(yesterday),
We should be careful about the runtime on which storlets stuff
works. (jre and python)
IMO, they should also be managed by infra side, and placed outside
docker container.

We have to consider some more things to realize the idea,
but anyway it makes much sense to me!

Thank you,
Takashi

-Original Message-
From: e...@itsonlyme.name [mailto:e...@itsonlyme.name] 
Sent: Tuesday, June 28, 2016 6:05 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [storlets] Docker images re-structuring

Currently, our Docker images are built form the following layers:
1. Ubuntu 14.04
2. JRE 8
3. Storlets stuff
4. Dummy layer having the tenant id as a name.

Only yesterday (after more then 2 years...), it occurred to me that the 3rd 
layer is a bit of a (understatement) mistake. Why not place the storlets stuff 
(daemon_factory, SDaemon, SCommon, etc.) in a read only mountable volume?

Pros:
1. Much easier to upgrade.
2. Less time from fix to test.
3. Less disk space that is wasted on Docker images as upgrades accumulate.

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-dev] [storlets] Docker images re-structuring

[eran]

Currently, our Docker images are built form the following layers:
1. Ubuntu 14.04
2. JRE 8
3. Storlets stuff
4. Dummy layer having the tenant id as a name.

Only yesterday (after more then 2 years...), it occurred to me that  
the 3rd layer is a bit of a (understatement) mistake. Why not place  
the storlets stuff (daemon_factory, SDaemon, SCommon, etc.) in a read  
only mountable volume?


Pros:
1. Much easier to upgrade.
2. Less time from fix to test.
3. Less disk space that is wasted on Docker images as upgrades accumulate.

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-dev] [storlets]Brand new documentation

[eran]

Brand new documentation for storlets is now available.
Compiled HTML format can be found here:
http://storlets.readthedocs.io/en/latest/

Major new sections are:
1. A use cases section
2. A detailed dev env installation instructions (a-la SAIO), as well  
as deployment instructions.


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

Re: [openstack-dev] [Storlets] Swift copy middlleware

[Eran Rom]

 wrote on 16/05/2016 04:32:58 AM:

> From: 
> To: 
> Date: 16/05/2016 04:36 AM
> Subject: Re: [openstack-dev] [Storlets] Swift copy middlleware
> 
> > I agree with Kota, and I think this is the easiest way to fix the 
problem.
> I noticed that placing storlets_middleware outside copy may require 
> some changes about slo handling,
> because now it is assumed that storlets_middleware is placed 
> "inside" slo, right?
> (I noticed this just after sending my previous e-mail :-( )
> 
> I think we had better make sure about what should be fixed in each 
> solutions, at this time.
>
Agree.
Here is what I see at a high level:
Option 1: Putting the storlet middleware at the left of the
copy middleware:
- Minimal code changes. We do need to take care of the utility
  Functions check_copy_from_header and check_destination_header
  I think are now private to the copy middleware.
- Have some duplicate with the copy middleware, unless we can
  use it as "an API"

Option 2: Leave the middleware where it is, and make sure we do
not execute the storlet in both the get and the put.
- Relies on internal perhaps not documented and not backwards
  Compatible way to determine that the GET/PUT are copy middleware
  generated.

Personally, I prefer option 2, but need to better understand what
We are relying on for knowing the GET/PUT are generated by the copy
Middleware.


__
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

Re: [openstack-dev] [Storlets] Swift copy middlleware

[kajinamit]

> I agree with Kota, and I think this is the easiest way to fix the problem.
I noticed that placing storlets_middleware outside copy may require some 
changes about slo handling,
because now it is assumed that storlets_middleware is placed "inside" slo, 
right?
(I noticed this just after sending my previous e-mail :-( )

I think we had better make sure about what should be fixed in each solutions, 
at this time.

Thanks,
Takashi


-Original Message-
From: kajina...@nttdata.co.jp [mailto:kajina...@nttdata.co.jp] 
Sent: Monday, May 16, 2016 10:20 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Storlets] Swift copy middlleware

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) 

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

Re: [openstack-dev] [Storlets] Swift copy middlleware

[kajinamit]

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) 

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

Re: [openstack-dev] [Storlets] Swift copy middlleware

[Kota TSUYUZAKI]

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-dev] [Storlets] Swift copy middlleware

[Eran Rom]

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-dev] [storlets] Review requests suggestion

[Eran Rom]

Hi All,
I suggest that until we have functional tests in place, each commit 
message should specify that:
(1) For a code change - the system tests were executed successfully with 
the change - 
(2) For installation related change that the installation was tested with 
this.

I further suggest that if the commit message does not have this the 
reviewer can assume that the committer forgot to do these and -1
Opinions?__
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