07:59:40 <eranrom> #startmeeting storlets
07:59:41 <openstack> Meeting started Tue Mar  7 07:59:40 2017 UTC and is due to finish in 60 minutes.  The chair is eranrom. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:59:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:59:44 <openstack> The meeting name has been set to 'storlets'
07:59:50 <eranrom> Hi
08:00:11 <kota_> hi
08:00:20 <eranrom> kota_: hey
08:00:44 <eranrom> akihito: Hi
08:00:58 <akihito> Hi!
08:01:20 <eranrom> Agenda: https://wiki.openstack.org/wiki/Meetings/Storlets
08:01:37 <eranrom> Our first topic is:
08:01:49 <eranrom> #topic Release status
08:02:17 <akihito> Ok.
08:02:30 * kota_ is looking at agenda
08:03:15 <eranrom> sagara: Hi. agenda: https://wiki.openstack.org/wiki/Meetings/Storlets
08:03:23 <eranrom> we are at the first topic
08:03:26 <kota_> sagara: o/
08:03:32 <sagara> eranrom: Hi
08:03:51 <eranrom> ok, so release status update:
08:04:12 <eranrom> There were several issues ranging from project templates to openstack ci permissions
08:04:41 <eranrom> Hopefully all is resolved now, and the final patch for the release passes Jenkins, and awaits the release team to approve.
08:05:17 <eranrom> Once this is done, we should have a PiPy package and should appear in the openstack releases.
08:05:58 <kota_> eranrom: sounds great that we can look at the release there :-D
08:06:39 <kota_> eranrom: btw, do we have to make release note from something... reno?
08:06:40 <eranrom> The release is still independent. I still need to look at the right model for us (milestones or intermediary)
08:07:44 <eranrom> kota_: I guess we are, but this would be part of doing more official releases. I still need to learn the process...
08:08:52 <eranrom> questions or next topic?
08:09:56 <akihito> I have no question.
08:10:04 <sagara> I have no question, please next
08:10:04 <eranrom> akihito: pls go ahead.
08:10:14 <eranrom> akihito: sorry, read to fast :-)
08:10:21 <eranrom> ok.
08:10:30 <eranrom> #topic Pike community goals
08:11:53 <kota_> sorry, my network seems freaky connect/disconnect
08:12:03 <eranrom> As I have mentioned in the wiki, since we are highly dependent on Swift which still has a lot of work towards py35, the best we can do is a unit test env
08:12:06 <eranrom> kota_: np
08:12:29 <eranrom> We used to have a py35 test evn set up by Kota, but I think it is broken now...
08:12:49 <eranrom> Once fixed we can add a gate job for it, and show progress
08:12:56 <kota_> eranrom: ah, really? what's broken?
08:13:10 <eranrom> kota_: I was not able to run it. Could it be my env?
08:13:38 <kota_> ah
08:14:28 <kota_> I'm surprised at we don't have py35 gate job :/
08:14:47 <eranrom> kota_: Any chance it is missing a "basepython = python3.5" in tox.ini?
08:15:23 <eranrom> Once I get it to work, I will add the gate.
08:15:29 <eranrom> that is add to the gate
08:15:54 <kota_> eranrom: did it work? i mean basepython-ish
08:16:06 <eranrom> kota_: did not try yet...
08:16:26 <eranrom> kota_: are you running this?
08:16:27 <kota_> ok, I also will try it. Definately it's a first step to support py3
08:16:35 <kota_> creating the gate job
08:16:38 <kota_> i mean
08:16:59 <eranrom> kota_: sure.
08:18:08 <eranrom> #topic Review prioritization
08:18:28 <eranrom> https://etherpad.openstack.org/p/storlets-review-priorities
08:19:19 <eranrom> First, I suggest that you add your patches to the pad.
08:19:56 <eranrom> kota_: I would LOVE to land your test concurrency patch
08:20:21 <akihito> sorry. I have WIP patch only..
08:20:39 <kota_> eranrom: sounds good
08:20:53 <eranrom> akihito: no problem.
08:20:59 <kota_> eranrom: but as you know, it depends on unique container patch
08:21:39 <eranrom> kota_: right. But its also very close to completion - roght?
08:21:50 <eranrom> s/roght/right
08:22:08 <eranrom> I will be happy to land them both :-)
08:22:11 <kota_> lemme check
08:25:36 <kota_> it seems like, I was missing to push my patch, I found the diff in my local
08:25:39 <kota_> let's push it
08:26:06 <eranrom> kota_: ok cool.
08:26:14 <kota_> oh?
08:26:27 <kota_> the git review calls nothing changed...
08:27:08 <kota_> er, the new patch set already there, https://review.openstack.org/#/c/437976/4
08:27:20 <kota_> but the 2 concurrency patch just sitting on patch set 3
08:28:02 <eranrom> kota_: I see.
08:28:04 <kota_> i think the patch set 4 is ready for reviews, which includes the unique container cleanup for you, eranrom
08:28:33 <eranrom> kota_: great! I ,ust have missed that, sorry. Let me review. If all is well, should we land?
08:28:49 <kota_> eranrom: i hope :)
08:29:07 <eranrom> kota_: ok great.
08:30:02 <eranrom> kota_: btw - I have added PUT, COPY support to the ipython patch
08:30:39 <eranrom> anything else on the reviews topic?
08:31:26 <akihito> Can I raise the priority of 'Create base server listening on sbus' and 'Use argparse to parse command line options'?
08:31:29 <kota_> eranrom: will look at the pach
08:31:31 <kota_> patch
08:31:33 <akihito> because my WIP patch depend on these patches.
08:32:39 <eranrom> kota_: thanks
08:32:56 <kota_> akihito: is it ready for review?
08:33:10 <akihito> yes!
08:33:18 <akihito> https://review.openstack.org/#/c/406620/
08:33:22 <akihito> https://review.openstack.org/#/c/419027/
08:33:49 <eranrom> akihito: I have already +2 406620
08:34:14 <akihito> Thank you Eran! :-)
08:34:56 <eranrom> akihito: will looked once at 419027, will review the updates.
08:35:12 <kota_> me too (will do)
08:35:23 <kota_> and set those into Priority: High
08:35:37 <kota_> in the etherpad
08:35:48 <eranrom> akihito: I got confused... I have +2 027 in the past, will review the updates...
08:35:50 <akihito> Thank you!! I confirm the etherpad.
08:37:02 <eranrom> OK, anything else on reviews?
08:37:21 <kota_> akihito: is the difference from only rebased? for 027 eranrom reviewed
08:38:06 <akihito> I confirm. just moment please.
08:40:39 <akihito> sorry.. At that time, this patch was in charge by Kasinami.
08:40:55 <akihito> s/Kasinami/Takashi/
08:41:14 <eranrom> akihito: right. I think that Takashi made some changes since I have reviewed this.
08:41:28 <kota_> k, got it
08:41:34 <kota_> akihito: thx for confirmation
08:42:05 <akihito> Please review again one more time...
08:42:25 <eranrom> akihito: sure, will do.
08:42:36 <eranrom> I think this covers all I had in mind.
08:42:42 <akihito> eranrom: Thank you!
08:42:47 <eranrom> Any other topics for today?
08:42:50 <eranrom> akihito: welcome
08:44:08 <sagara> Now I'm thinking resource limiting feature for storlets.
08:44:10 <akihito> I have no topic today.
08:45:13 <eranrom> sagara: If you have anything to share (thoughts, design, anything) I will be more then happy to review / help.
08:47:04 <sagara> sorry, no document, there is just only note
08:47:43 <sagara> I think storlets resource limiting has two point of view.
08:47:51 <sagara> 1. account limiting
08:47:56 <sagara> 2. remains host stable from the high load of storlets applications
08:48:11 <sagara> Item 1, it's similar like swift rate limiting. limit number of storlet request per second for account.
08:48:28 <sagara> #link: https://docs.openstack.org/developer/swift/ratelimit.html
08:48:48 <sagara> Item 2, now I'm thinking. I will limit CPU core, memory, Disk I/O which are used by container,
08:49:10 <sagara> I think it is difficult that how to limit Disk I/O,
08:49:28 <sagara> it seems to have two design.
08:49:59 <sagara> 2-1, we use docker resource constraint
08:50:07 <sagara> #link: https://docs.docker.com/engine/reference/run/#runtime-constraints-on-resources
08:50:38 <sagara> but docker constraint I/O feature are like '--device-write-bps', it is cap, so storlets application cannot use host resource effectively.
08:51:06 <sagara> so I'm thinking another approach.
08:51:37 <sagara> 2-2, we use priority, like nice, ionice command with docker run.
08:53:09 <eranrom> sagara: Thanks for sharing your thoughts. I guess I have one comment:
08:53:11 <sagara> It's still on the way, so I need to address that requirement, problem, and design it.
08:53:45 <eranrom> sagara: sure.
08:54:45 <sagara> I glad to receive some comment.
08:55:23 <eranrom> the comment is that we have a container per account, hence any resources being limited in #2 (be it 2-1 or 2-2) this can be employed per account
08:57:00 <eranrom> Also, I am not sure there is a fundamental difference between limiting IO and limiting memory and CPU where you also cap the amount that can be used by storlet apps
08:57:08 <kota_> perhaps, we could want to limit via application level
08:57:36 <eranrom> kota_: you mean different storlet apps get different resources?
08:57:50 <kota_> to do that, perhaps, we could think of `ulimit`ing per storelt-daemon?
08:57:57 <kota_> eranrom: might be
08:58:20 <eranrom> we need to finish here. Do you want to continue in #openstack-storlets?
08:58:27 <kota_> sure
08:58:52 <eranrom> ok, so I am ending the meeting and switching to #openstack-storlets
08:58:57 <sagara> ok, sorry.
08:58:58 <eranrom> #endmeeting