Thursday, 2013-07-18

*** sarob_ has quit IRC00:01
*** tanisdl has quit IRC00:02
*** megan_w has joined #openstack-meeting-alt00:02
*** megan_w has quit IRC00:03
*** megan_w has joined #openstack-meeting-alt00:04
*** megan_w has quit IRC00:09
*** akuznetsov has quit IRC00:40
*** esp has quit IRC00:44
*** lastidiot has joined #openstack-meeting-alt00:49
*** yidclare has quit IRC01:07
*** arborism has quit IRC01:12
*** IlyaE has quit IRC01:13
*** esp has joined #openstack-meeting-alt01:15
*** IlyaE has joined #openstack-meeting-alt01:15
*** esp has quit IRC01:16
*** IlyaE has quit IRC01:30
*** jergerber has joined #openstack-meeting-alt01:38
*** IlyaE has joined #openstack-meeting-alt01:45
*** IlyaE has quit IRC01:50
*** qwerty_nor has quit IRC01:52
*** IlyaE has joined #openstack-meeting-alt02:00
*** IlyaE has quit IRC02:14
*** sarob has joined #openstack-meeting-alt02:28
*** jergerber has quit IRC02:30
*** jergerber has joined #openstack-meeting-alt02:32
*** sarob has quit IRC02:37
*** sarob has joined #openstack-meeting-alt02:38
*** sarob has quit IRC02:42
*** sarob has joined #openstack-meeting-alt02:46
*** vkmc has quit IRC02:48
*** qwerty_nor has joined #openstack-meeting-alt03:04
*** jrodom has joined #openstack-meeting-alt03:09
*** jergerber has quit IRC03:11
*** dosaboy has quit IRC03:19
*** dosaboy has joined #openstack-meeting-alt03:21
*** sarob has quit IRC03:22
*** sarob has joined #openstack-meeting-alt03:22
*** bdpayne has quit IRC03:23
*** sarob has quit IRC03:26
*** HenryG has quit IRC03:28
*** IlyaE has joined #openstack-meeting-alt03:56
*** SergeyLukjanov has joined #openstack-meeting-alt04:05
*** ekarlso has quit IRC04:07
*** ekarlso has joined #openstack-meeting-alt04:07
*** yidclare has joined #openstack-meeting-alt04:11
*** dosaboy_ has joined #openstack-meeting-alt04:21
*** dosaboy has quit IRC04:24
*** IlyaE has quit IRC04:27
*** yamahata has quit IRC04:27
*** IlyaE has joined #openstack-meeting-alt04:28
*** jrodom has quit IRC04:30
*** vipul is now known as vipul-away04:30
*** IlyaE has quit IRC04:30
*** yamahata has joined #openstack-meeting-alt04:32
*** sarob has joined #openstack-meeting-alt04:33
*** sarob has quit IRC04:38
*** dosaboy has joined #openstack-meeting-alt04:45
*** dosaboy_ has quit IRC04:46
*** IlyaE has joined #openstack-meeting-alt04:48
*** vipul-away is now known as vipul04:55
*** lastidiot has quit IRC04:57
*** IlyaE has quit IRC05:00
*** IlyaE has joined #openstack-meeting-alt05:03
*** IlyaE has quit IRC05:04
*** sarob has joined #openstack-meeting-alt05:22
*** abaron has joined #openstack-meeting-alt05:54
*** SergeyLukjanov has quit IRC05:57
*** IlyaE has joined #openstack-meeting-alt06:03
*** IlyaE has quit IRC06:04
*** SergeyLukjanov has joined #openstack-meeting-alt06:06
*** SergeyLukjanov has quit IRC06:10
*** IlyaE has joined #openstack-meeting-alt06:16
*** sarob has quit IRC06:16
*** sarob has joined #openstack-meeting-alt06:17
*** IlyaE has quit IRC06:20
*** sarob has quit IRC06:21
*** SergeyLukjanov has joined #openstack-meeting-alt06:41
*** sarob has joined #openstack-meeting-alt07:28
*** sarob has quit IRC07:32
*** koudaddy_ has joined #openstack-meeting-alt08:37
*** demorris has joined #openstack-meeting-alt10:25
*** SergeyLukjanov has quit IRC10:46
*** SergeyLukjanov has joined #openstack-meeting-alt10:47
*** demorris has quit IRC11:02
*** SergeyLukjanov has quit IRC11:16
*** SergeyLukjanov has joined #openstack-meeting-alt11:17
*** SergeyLukjanov has quit IRC11:20
*** pcm_ has joined #openstack-meeting-alt11:21
*** SergeyLukjanov has joined #openstack-meeting-alt11:24
*** HenryG has joined #openstack-meeting-alt11:38
*** vkmc has joined #openstack-meeting-alt11:55
*** vkmc has joined #openstack-meeting-alt11:55
*** sballe has joined #openstack-meeting-alt13:05
*** SergeyLukjanov has quit IRC13:08
*** SergeyLukjanov has joined #openstack-meeting-alt13:11
*** SergeyLukjanov has quit IRC13:23
*** jrodom has joined #openstack-meeting-alt13:35
*** demorris has joined #openstack-meeting-alt13:35
*** pdmars has joined #openstack-meeting-alt13:39
*** jcru has joined #openstack-meeting-alt13:39
*** SergeyLukjanov has joined #openstack-meeting-alt13:45
*** flaper87 has joined #openstack-meeting-alt13:47
*** ben_duyujie has joined #openstack-meeting-alt13:50
*** djohnstone has joined #openstack-meeting-alt13:52
*** markwash has joined #openstack-meeting-alt13:53
*** zhiyan has joined #openstack-meeting-alt13:58
markwasho/14:03
flaper87\o/14:03
zhiyanhey14:03
markwash#startmeeting glance14:03
openstackMeeting started Thu Jul 18 14:03:38 2013 UTC.  The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot.14:03
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.14:03
*** openstack changes topic to " (Meeting topic: glance)"14:03
openstackThe meeting name has been set to 'glance'14:03
zhiyan\o/14:03
flaper87\o/14:03
zhiyan:)14:03
markwash#topic agenda14:03
*** openstack changes topic to "agenda (Meeting topic: glance)"14:03
markwashhi folks14:04
zhiyanhi markwash14:04
flaper87Hi markwash14:04
flaper87lol14:04
markwashat the end of next meeting, I wanna have a pretty good idea of what we're trying to deliver over havana-314:04
zhiyanbtw, thank you all, for review and landing my patch to H214:04
markwashbut is there other stuff folks want to talk about today?14:04
flaper87zhiyan: thank you for working on that14:05
zhiyanhttps://etherpad.openstack.org/glance-havana3-blueprints14:05
zhiyanflaper87: :-D, thanks you!14:05
markwashyes, thanks to zhiyan and all the reviewers. . I think ttx was impressed that we didn't have to drop anything in the last two weeks of h214:05
zhiyancoool!14:05
zhiyanmarkwash: could you pls take a look above link? do you think they are make your sense?14:06
markwashlooking14:07
*** SergeyLukjanov has quit IRC14:07
markwashI think those are all good, but I'm still a little unclear about "global state management"14:07
markwashthat sounds kind of like something nova does that is problematic14:07
zhiyanmaybe i can create BPs for that (except Enable task, others are all I added)14:07
flaper87markwash: following our former plan to get Glance "Out There" - reading, making it a public service - I'd love to see async workers move forward14:08
markwash#topic havana 3 blueprints14:08
*** openstack changes topic to "havana 3 blueprints (Meeting topic: glance)"14:08
markwashflaper87: +114:08
flaper87This is the patch for that14:08
flaper87#link https://blueprints.launchpad.net/glance/+spec/async-glance-workers14:08
flaper87blueprint*14:08
markwashI think we might have a critical mass at this point14:08
zhiyanmarkwash's draft : https://review.openstack.org/#/c/31874/214:08
zhiyanflaper87: +114:08
markwashI have a better idea how I think it should work (my draft is not up to date)14:08
flaper87since the registry stuff is ready, I can focus on that and help you with that blueprint14:09
zhiyanmarkwash: yes, i'd like post our discussing summary (IRC) to a etherpad page, if you like14:09
flaper87also, I think this is important - still sticking to our former plan - to have some quotas in glance. IMHO, we should track this down as well14:10
flaper87#link https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas14:10
*** cp16net is now known as cp16net|away14:10
zhiyanflaper87: could you pls add them to that etherpad page also?14:11
markwashyeah, I think that is just looking for workers at this point14:11
markwashs/workers/developers14:12
zhiyan:)14:12
markwashnot to be confused with image workers / async processing14:12
flaper87markwash: I know John was looking at it (re quotas)14:12
zhiyanmaybe that's truth, 'developer' = 'worker' :)14:12
*** ben_duyujie has quit IRC14:12
markwashwe could implement async just as a mechanical turk with glance developers manually doing image conversions on their laptops14:13
flaper87markwash: LOOOOL14:13
*** flwang has joined #openstack-meeting-alt14:13
markwashthat might cause a security problem I guess :-)14:13
zhiyanhttps://etherpad.openstack.org/glance-async-task-discussing14:13
markwashzhiyan thanks14:14
markwashflwang: o/14:15
flwangmarkwash:o/14:15
markwashzhiyan: can you describe the scrubber changes in some more detail?14:16
markwashI'm interested in refactoring it as well, principally to make testing it less brittle and slow14:16
zhiyanmarkwash: ok, for now, the biggest issue for it is about 'multiple-locations' supporting IMO14:17
*** flaper87 has quit IRC14:17
*** flaper87 has joined #openstack-meeting-alt14:17
*** SergeyLukjanov has joined #openstack-meeting-alt14:18
markwashzhiyan: okay cool, makes sense14:18
zhiyancurrently scrubber not support that at all, actually if image has more then one location there, and glance configured using scrubber to remove image, the glance-api will raise exception when use delete image.14:18
zhiyans/use/user14:19
flaper87zhiyan: I think I lost the first message, re scrubber. Sorry. Can you re-send it ?14:19
zhiyanand other code also need be refactoring14:19
zhiyanok, for now, the biggest issue for it is about 'multiple-locations' supporting IMO14:19
flaper87zhiyan: +114:19
markwashI'm also a bit confused about its architecture, not to complicate the discussion, but. . .14:20
markwashit tends to use a local process consuming a file-backed queue of locations to delete14:20
zhiyanflaper87: actually, i checked scrubber code, IMO it's not so clear...14:20
markwashthough it can also periodically query the database and shove images into the local queue for processing14:21
markwashits very scatter brained14:21
markwashand yet, its only a small LOC14:21
markwashmeaning to say, its not that hard to replace14:21
zhiyanmarkwash: yes, but i'm not followed your last point ..14:22
markwashwhen I was looking at it for testing purposes, I thought the best thing would be a rewrite14:22
zhiyanmarkwash: are you meaning scrubber can be removing? or some change14:22
markwashI don't think we can remove it, because we need something to handle pending deletes14:23
zhiyanmarkwash: ok, for change what?14:23
zhiyanmarkwash: yes, i think so. but not clear what you want to rewrite..sorry14:23
markwashzhiyan: I was just thinking of completely rewriting the component that handles pending_deletes14:24
markwashso probably completely replace glance-scrubber14:24
zhiyanmarkwash: using async-task?14:24
zhiyanor just internal refactoring?14:24
markwashjust internal refactoring14:24
zhiyanfor glance-scrubber .. ok14:24
zhiyani will check it when i do that, and I'd like / we can discussing details.14:25
flaper87I haven't looked at scrubber that much14:25
*** lastidiot has joined #openstack-meeting-alt14:25
zhiyanflaper87: it's easy, small14:25
zhiyanbut as markwash said, currently it read delete 'task/request' from file14:26
markwashso, I mention that only as a green light to folks if they want to be a bit drastic with it14:26
flaper87zhiyan: yeah, I wonder if we'll be ever be able to get rid of it, perhaps using async-workers14:26
zhiyanmarkwash: aha, thanks.14:27
markwashzhiyan: are those blueprints in the etherpad that you added all things you plan to work on?14:27
markwashor are some of them just general suggestions of things you think need to be done14:27
*** IlyaE has joined #openstack-meeting-alt14:28
zhiyanflaper87: yes, async-task will be good. asynchronous delete image. but there is a issue for async-task, it need support reliable persistent task queue supporing.14:28
zhiyanmarkwash: i'd like create them, but i'm not sure i have enough bandwidth do all of them, you know.14:29
flaper87zhiyan: agreed14:29
flaper87markwash: btw, I remembered another blueprint that I think is important for H-314:29
markwashzhiyan: makes sense, can you put your name by the ones you *definitely* want to work on, including teh ones already in progress?14:29
flaper87markwash: store credentials being saved in the DB14:29
markwashflaper87: ah good point, I think iccha has some current work on that14:29
* flaper87 is trying to find the blueprint14:29
markwashunfortunately the rackspace folks cannot be here today, they have a corporate thing, not just protesting us :-)14:30
zhiyanmarkwash: sure, will do.14:30
flaper87markwash: yeah, she mentioned it, we should sync with her about that14:30
flaper87markwash: LOL14:30
flwangmarkwash: do we want plan the task bp into h-3?14:30
markwashflwang: I think we do14:31
zhiyanhttps://review.openstack.org/#/c/34801/ ?14:31
markwashflwang: it is very important and there are several interested folks14:31
flaper87markwash: and this one: https://blueprints.launchpad.net/glance/+spec/glance-cache-path14:31
flwangmarkwash: yep, but obviously, we need more discussion14:31
flaper87I think the cache one is pretyt important as well.14:31
flwangflaper87: agree +114:32
flwangI'd like to see the cache management is improved14:32
markwashyeah, there have been some definite requests around that14:32
*** demorris has quit IRC14:33
zhiyanflaper87: markwash: i really think we should write them down to etherpad page14:33
markwash+114:33
markwashI just added the cache path one14:33
* flaper87 gets the other ones14:33
zhiyanthanks14:33
*** mclarenst has joined #openstack-meeting-alt14:34
*** rnirmal has joined #openstack-meeting-alt14:34
zhiyanbtw, i just know iccha is a lady...since flaper87 use 'she'..14:34
markwashflwang: you're planning on working on the task / async stuff during h3, correct?14:34
flwangyep14:35
flaper87zhiyan: she is and she rocks! :D14:35
flwangbut I think I need you guys support14:35
flwangto make sure the design is correct :)14:35
markwashflwang: sure thing14:35
flaper87flwang: +114:35
flaper87flwang: where are you based?14:35
markwashalso there are some other folks for whom async processing is very important, and we need to make sure they are in the discussion14:35
flwangflaper87, Beijing, China14:35
flaper87flwang: cool!14:36
markwashcurrently nikhil is assigned on the blueprint, but I know he's been very busy with some other work as well and would welcome your work14:36
*** bourke has joined #openstack-meeting-alt14:36
flwangmarkwash: yep, we have started some discussion since yesterday14:36
flwangflaper87: where are you based?14:37
zhiyanflwang: paste again for you, a summary we discussed yesterday. https://etherpad.openstack.org/glance-async-task-discussing14:37
*** mclarenst is now known as mclaren14:37
flwangzhiyan: great, thanks14:37
flaper87flwang: I'll take the cache management one, hopefully, the common oslo cache will land soon as well and we can pull that in14:37
flaper87flwang: Como, Italy14:37
flaper87flwang: pull me in into the async workers discussions, pls :)14:38
markwashflaper87: have you seen https://blueprints.launchpad.net/glance/+spec/refactoring-move-caching-out-of-middleware ?14:38
flwangflaper87: nice, I love pizza14:38
zhiyanflwang: markwash: and me pls14:38
flwangflaper87: sure thing14:38
flwangzhiyan: sure14:39
*** lastidiot has quit IRC14:40
markwashflaper87: I'd be interested in seeing if we can address that refactoring during the process, or if its too much to take on14:40
flaper87markwash: mmh, I think I did and forgot. That makes more sense than having a cache service as we discussed once14:40
markwashI'm pretty sad about the way the cache lives at the wsgi middleware layer and thus has to duplicate all the formatting logic14:40
flaper87markwash: I think we can do it and it makes sense14:40
flwangmarkwash: +114:41
flaper87also, multiple-location landed already, that will help us on addressing john's comments as well14:41
markwashI think we've got good initial coverage of our h3 blueprints, I'll try to update the pages this week and follow up with questions for folks14:42
zhiyanmarkwash: flaper87: the BP make sense to me, but i don't think jbresnah's thoughts is right (in whiteboard) maybe i not followed his comments well14:42
flaper87zhiyan: that came from another discussion about having some kind of service for it, IIRC. I'm pretty sure we have to discuss that a bit further14:42
flaper87perhaps in our next meeting14:43
markwashzhiyan: I think the idea is that for admins, cache could be managed as another location on the image14:43
markwashI'd like to open up the dicussion in case folks have general issues they want to bring up14:43
flaper87markwash: o/14:43
markwash#topic open discussion14:43
zhiyanmarkwash: i'd like to know them all14:43
*** openstack changes topic to "open discussion (Meeting topic: glance)"14:43
flaper87o/14:43
markwashflaper87: go for it14:44
zhiyanmarkwash: do you think it's time to take a look again on https://blueprints.launchpad.net/nova/+spec/image-multiple-location14:44
zhiyanit's for nova side, but related with glance14:44
flaper87I'm pretty concerned about the client and it's support for glance's v2, I know iccha and esheffield are working on it14:44
zhiyanthanks for you earlier input for that btw.14:44
flaper87so, I was planning to take less bps for H-3 and dedicate some more time to the client14:45
zhiyanflaper87: oh, yes, cinder guy ping me again for it, in yesterday cinder weekly meeting14:45
flaper87but, the client needs some review-help14:45
markwashflaper87: that would make me crazy happy14:45
zhiyanflaper87: just because glanceclient has gay on v2 client, causes cinder has some limitation14:45
zhiyanmarkwash know that14:46
zhiyana defect14:46
flaper87markwash: cool, so, I'll sync with iccha and esheffield and dedicate more time to it14:46
markwashflaper87: noted, I'll double down my efforts to review client patches14:46
markwashshould be easy to do, after all 2 * 0 = 0 :-)14:47
flaper87markwash: question: How are client releases planned? I know those are just tags but when do they happen?14:47
markwashit essentially has its own roadmap14:47
markwashfor now, the roadmap issues are v2 support and deprecating legacy I believe14:47
flaper87markwash: ok, so it's feature based14:47
flaper87once those are covered, we can release a new version14:48
markwashyeah, it is not tied into the general openstack release14:48
flaper87oke-doke!14:48
markwashI'm still really interested in someone basically taking on the client as pseudo-ptl, honestly14:48
markwashbecause I keep accidentally ignoring it to focus on the server side14:48
flaper87markwash: I raised my hand the last time :D14:48
*** tanisdl has joined #openstack-meeting-alt14:49
markwashI think you'd be a good fit, but we probably have to sync up more to make the transition14:49
zhiyanmarkwash: flaper87: can you take a look on https://review.openstack.org/#/c/37616/ ?14:49
zhiyanfor resolve this: https://bugs.launchpad.net/glance/+bug/120239114:49
markwashzhiyan: yes, thanks for that14:49
flaper87markwash: yup, we should also ask iccha!14:50
zhiyan+2 pls, if you ok, just don't like other guys say my patch block something. :)14:50
flwangis it time to call for reviewer ? :)14:50
flaper87oke, that was my point for the open discussion14:50
flaper87:D14:50
bourkewas wondering did anyone have any thoughts on the topic of unicode in exceptions...14:51
flaper87bourke: ?14:51
zhiyanbourke: https://review.openstack.org/#/c/37421/ ?14:51
bourkeflaper87: both yourself and zhiyan have a nice fairly similar solution there14:51
flaper87zhiyan: https://review.openstack.org/#/c/36658/14:52
flaper87:D14:52
zhiyanyes, i lean from flaper87 :)14:52
bourkeflaper87: but was wondering what about other exceptions. is it something that could be wrapped in a function and used in multiple places?14:52
zhiyanaha, since you give me a comment, so i checked your patch, and got it14:52
flwangmarkwash: flaper87: may I get your comments about this https://review.openstack.org/#/c/37511/   ?14:52
zhiyanbourke: can we take care that be case by case? defect driven maybe more easy14:53
flaper87zhiyan: +!14:53
flaper87zhiyan: +114:53
bourkesure thing14:53
*** tanisdl has quit IRC14:53
zhiyanbourke: thanks you for you raise this up, i just forget it...14:54
*** tanisdl has joined #openstack-meeting-alt14:54
markwashflwang: I like that you are getting the latest oslo.rpc code, but I'd still slightly prefer to see it in another patch14:54
markwashflwang: maybe you can ask the other submitter to update their patch with the latest code?14:54
zhiyanmarkwash: yes https://review.openstack.org/#/c/37184/14:54
flaper87flwang: have you looked at the new oslo.messaging?14:55
flaper87I wonder whether it is worth to pull oslo's rpc code into glance instead of waiting 'til new oslo.messaging is ready14:55
zhiyan5 mins left14:55
*** pdmars has quit IRC14:56
flwangflaper87: nope, what's up?14:56
markwashflaper87: I think the goal here is to use notifier, which depends on rpc14:56
flwangmarkwash: yes14:56
*** pdmars has joined #openstack-meeting-alt14:56
flaper87markwash: indeed, that notifier will depend on oslo.messaging by the end of H-314:56
markwashflaper87: well, that's pretty nice14:57
bourkeoh, one other thing, if someone could take a look at https://review.openstack.org/#/c/35286/ that would be much appreciated14:57
flaper87is it worth to pull all that in instead of waiting for that migration to happen ?14:57
flwangflaper87: any blueprint or bug to track that?14:57
flaper87flwang: erm, let me check14:57
markwashbourke: looks like an easy +2 approve, will check immediately after mtg14:57
bourkemarkwash: thanks!14:57
markwashflaper87: do you know if its like "early h3" for being ready? or last minute?14:58
zhiyanand https://review.openstack.org/#/c/36884/  and https://review.openstack.org/#/c/37222/14:58
flwangflaper87: it oslo.messaging is the direction, it would be nice to do that14:58
flaper87markwash: I'd say last minute14:58
*** akuznetsov has joined #openstack-meeting-alt14:58
markwashany other folks have last minute notices or announcements?14:59
flwangmarkwash: so I still can't get approve for my fix ? O:-)14:59
flwangflaper87: any comments?14:59
flaper87flwang: TBH, I'd wait for that before pulling oslo's notification in14:59
flaper87because oslo.rpc has some config parameters that might change when oslo.messaging is complete15:00
zhiyanmarkwash: just notice, pls review https://review.openstack.org/#/c/37616/ for fix https://bugs.launchpad.net/glance/+bug/120239115:00
flaper87among other things15:00
markwashflaper87: that makes sense15:00
*** pdmars has quit IRC15:01
flwangmarkwash: how do you think? IMO, I think we can do the refactoring for notifier and follow up the change of oslo.messaging15:01
*** demorris has joined #openstack-meeting-alt15:01
*** megan_w has joined #openstack-meeting-alt15:01
markwashwe can, but it increases the operational burden15:01
markwashI think we have to clear out now folks15:01
markwashthanks errbody15:02
flaper87kk, good meeting! Thanks to all!!15:02
markwash#endmeeting15:02
flwangback to our channel15:02
*** openstack changes topic to "OpenStack meetings (alternate)"15:02
zhiyanthanks15:02
openstackMeeting ended Thu Jul 18 15:02:11 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:02
openstackMinutes:        http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-07-18-14.03.html15:02
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-07-18-14.03.txt15:02
openstackLog:            http://eavesdrop.openstack.org/meetings/glance/2013/glance.2013-07-18-14.03.log.html15:02
*** mclaren has quit IRC15:02
*** flaper87 has left #openstack-meeting-alt15:02
*** jrodom has quit IRC15:02
*** sballe has quit IRC15:03
*** jrodom has joined #openstack-meeting-alt15:03
markwashbourke: btw I reviewed your patch, one note in there I'd like you to check out15:04
bourkemarkwash: thanks, will check that out now15:05
*** lastidiot has joined #openstack-meeting-alt15:11
*** vipul is now known as vipul-away15:13
*** bdpayne has joined #openstack-meeting-alt15:20
*** lastidiot has quit IRC15:21
*** markwash has quit IRC15:23
*** lastidiot has joined #openstack-meeting-alt15:24
*** sarob has joined #openstack-meeting-alt15:33
*** sarob has quit IRC15:36
*** sarob has joined #openstack-meeting-alt15:36
*** SergeyLukjanov has quit IRC15:40
*** sarob has quit IRC15:40
*** SergeyLukjanov has joined #openstack-meeting-alt15:43
*** sarob has joined #openstack-meeting-alt15:44
*** vipul-away is now known as vipul15:52
*** pdmars has joined #openstack-meeting-alt15:55
*** yidclare has left #openstack-meeting-alt16:02
*** yidclare has joined #openstack-meeting-alt16:05
*** yidclare has left #openstack-meeting-alt16:05
*** yidclare has joined #openstack-meeting-alt16:05
*** yidclare has left #openstack-meeting-alt16:06
*** SergeyLukjanov has quit IRC16:06
*** hub_cap has left #openstack-meeting-alt16:07
*** demorris has quit IRC16:07
*** qwerty_nor has quit IRC16:14
*** zhiyan has quit IRC16:20
*** SergeyLukjanov has joined #openstack-meeting-alt16:30
*** jrodom has quit IRC16:36
*** jcru is now known as jcru|away16:43
*** esp has joined #openstack-meeting-alt16:43
*** esp has left #openstack-meeting-alt16:43
*** mattf has joined #openstack-meeting-alt16:46
*** jrodom has joined #openstack-meeting-alt16:46
*** jrodom has quit IRC16:49
*** sarob_ has joined #openstack-meeting-alt16:53
*** sarob has quit IRC16:57
*** pdmars has quit IRC16:57
*** markwash has joined #openstack-meeting-alt16:58
*** pdmars has joined #openstack-meeting-alt16:58
*** sarob_ has quit IRC16:58
*** sarob has joined #openstack-meeting-alt16:59
*** jergerber has joined #openstack-meeting-alt16:59
*** pdmars has quit IRC17:02
*** markwash_ has joined #openstack-meeting-alt17:05
*** markwash has quit IRC17:06
*** markwash_ is now known as markwash17:06
*** akuznetsov has quit IRC17:28
*** akuznetsov has joined #openstack-meeting-alt17:39
*** Riddhi has joined #openstack-meeting-alt17:42
*** Riddhi has quit IRC17:44
*** Riddhi has joined #openstack-meeting-alt17:45
*** demorris has joined #openstack-meeting-alt17:46
*** Riddhi has quit IRC17:48
*** Riddhi has joined #openstack-meeting-alt17:49
*** Nadya has joined #openstack-meeting-alt17:52
*** ruhe has joined #openstack-meeting-alt17:58
SergeyLukjanovSavanna team meeting will be here in 5 minutes17:58
*** crobertsrh has joined #openstack-meeting-alt18:00
*** jcru|away is now known as jcru18:00
*** dmitryme has joined #openstack-meeting-alt18:00
*** marcos_sb has joined #openstack-meeting-alt18:02
*** nkonovalov__ has joined #openstack-meeting-alt18:02
*** pdmars has joined #openstack-meeting-alt18:03
SergeyLukjanovhi everyone!18:04
SergeyLukjanovwhere is a savanna team? :)18:04
ruheo/18:04
*** jmaron has joined #openstack-meeting-alt18:05
SergeyLukjanovok, I think we should start18:06
SergeyLukjanov#startmeeting savanna18:07
openstackMeeting started Thu Jul 18 18:07:08 2013 UTC.  The chair is SergeyLukjanov. Information about MeetBot at http://wiki.debian.org/MeetBot.18:07
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.18:07
*** openstack changes topic to " (Meeting topic: savanna)"18:07
openstackThe meeting name has been set to 'savanna'18:07
SergeyLukjanov#topic Agenda18:07
SergeyLukjanov#info General news18:07
SergeyLukjanov#info Other updates18:07
SergeyLukjanov#info Action items from the last meeting18:07
SergeyLukjanov#info Next gen architecture18:07
*** openstack changes topic to "Agenda (Meeting topic: savanna)"18:07
SergeyLukjanov#info EDP discusion18:07
SergeyLukjanov#info General discussion18:07
SergeyLukjanov#topic General news18:08
*** openstack changes topic to "General news (Meeting topic: savanna)"18:08
SergeyLukjanov#info Savanna 0.2 has been successfully released!18:08
SergeyLukjanovboth savanna and savanna-dashboard available at pypi and tarballs.openstack.org18:09
SergeyLukjanov#info Docs has been updated before release18:09
SergeyLukjanovTons of docs has been written and now I think our docs looks pretty good18:10
SergeyLukjanovthere are user guide, dev guide and quick start in docs18:10
SergeyLukjanov#link https://savanna.readthedocs.org/en/0.2/18:11
SergeyLukjanov#info HDP plugin has been merged and targeted to be released in 0.2.1 version18:11
*** cp16net|away is now known as cp16net18:11
SergeyLukjanovThanks for Hortonworks team!18:11
*** Riddhi has quit IRC18:11
SergeyLukjanovare there anybody from Hortonworks here?18:11
SergeyLukjanovok, let's move on18:12
SergeyLukjanov#info Instances deletion has been implemented for cluster scaling18:12
jmaronyes - I'm here18:12
SergeyLukjanovjmaron, hi, my congratulations!18:12
*** Riddhi has joined #openstack-meeting-alt18:12
jmaronthanks18:12
SergeyLukjanovNadya, thank you for continuously improving Hadoop scaling feature!18:13
SergeyLukjanov#info Minor bug fixes and improvements18:13
SergeyLukjanov#info Savanna 0.2.1 release planned to July, 2918:14
NadyaSergeyLukjanov, thanks :)18:14
SergeyLukjanov#topic Other updates18:14
*** openstack changes topic to "Other updates (Meeting topic: savanna)"18:14
SergeyLukjanovteam, are there any other updates?18:14
SergeyLukjanov#info A lot of new unit and integration tests has been added18:15
SergeyLukjanovlet's move on18:15
SergeyLukjanov#topic Action items from the last meeting18:15
*** openstack changes topic to "Action items from the last meeting (Meeting topic: savanna)"18:15
SergeyLukjanov#info we have no action items from the last meeting18:16
SergeyLukjanov:)18:16
SergeyLukjanov#topic Next generation Savanna architecture18:16
*** openstack changes topic to "Next generation Savanna architecture (Meeting topic: savanna)"18:16
SergeyLukjanovI've prepared a small document that describes our current vision on improving Savanna architecture18:17
*** Riddhi has quit IRC18:17
SergeyLukjanov#link https://wiki.openstack.org/wiki/Savanna/NextGenArchitecture18:17
SergeyLukjanovI'm planning to add more details to it tomorrow and prepare blueprints for all key stuff18:18
*** IlyaE has quit IRC18:18
SergeyLukjanovfeel free to comment, ask questions18:18
*** Riddhi has joined #openstack-meeting-alt18:18
*** jrodom has joined #openstack-meeting-alt18:19
SergeyLukjanovI'll post this link to the mailing lists when it'll be finished18:19
SergeyLukjanovthe main goal it is to make Savanna scalable18:19
SergeyLukjanovare there any question on it now?18:20
*** sballe has joined #openstack-meeting-alt18:20
SergeyLukjanovok, let's move on18:20
SergeyLukjanov#topic EDP18:20
*** openstack changes topic to "EDP (Meeting topic: savanna)"18:20
SergeyLukjanovrune, akuznetsov, are there any questions or updates from your side?18:20
SergeyLukjanovsorry again, s/rune/ruhe/18:21
ruhewe're working in etherpad doc now18:21
ruhe#link https://etherpad.openstack.org/edp_v3_components18:21
akuznetsovtmckayrh created a sequence diagram18:22
akuznetsov#link https://wiki.openstack.org/wiki/Savanna/EDP_Sequences18:22
ruheas we agreed with tmckayrh (Trevor) today we will work together on the etherpad to add more details for each component18:22
ruheright now it is very raw and mostly based on blueprints published by akuznetsov18:23
ruhegood news: we're aligned with Trevor and Chad on the EDP vision. so i expect good progress on this document18:25
SergeyLukjanovare there anything more about edp?18:25
crobertsrhI continue to evolve the UI mockups for EDP:  https://wiki.openstack.org/wiki/Savanna/UIMockups/JobCreation18:26
ruhethere are several open questions, but i think it'll be better to solve them in mailing list18:26
ruhequestions are about Oozie and about division of responsibilities between plugin and EDP component18:27
ruhecrobertsrh, mockups look good to me18:28
akuznetsovcrobertsrh, I proposed following changes for job parameters page18:29
crobertsrhthanks.  Still evolving a bit as the api becomes clearer18:29
akuznetsov#link https://wiki.openstack.org/w/images/f/f0/JobParameters.png18:29
akuznetsovcrobertsrh do you have some comments?18:30
crobertsrhakuznetsov:  ack.  That seems like a reasonable approach there.18:30
ruhei don't have anything else on EDP18:31
ruhefor those who might not know: EDP = Elastic Data Processing18:31
SergeyLukjanovare there any other thoughts on EDP?18:31
*** jrodom has quit IRC18:32
SergeyLukjanovok, thank you guys for updates18:32
SergeyLukjanov#info General discussion18:32
*** jrodom has joined #openstack-meeting-alt18:33
SergeyLukjanov#topic General discussion18:33
*** openstack changes topic to "General discussion (Meeting topic: savanna)"18:33
SergeyLukjanovif there no questions or news we can end meeting18:35
SergeyLukjanov#info JFYI you can always use openstack-dev@lists.openstack.org mailing lists and #savanna irc channel to find us and ask your questions18:35
SergeyLukjanov#endmeeting18:35
*** openstack changes topic to "OpenStack meetings (alternate)"18:35
openstackMeeting ended Thu Jul 18 18:35:53 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:35
openstackMinutes:        http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-18-18.07.html18:35
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-18-18.07.txt18:35
openstackLog:            http://eavesdrop.openstack.org/meetings/savanna/2013/savanna.2013-07-18-18.07.log.html18:35
*** dmitryme has left #openstack-meeting-alt18:41
*** IlyaE has joined #openstack-meeting-alt18:44
*** jrodom has quit IRC18:49
*** esheffield has joined #openstack-meeting-alt18:51
*** esheffield has left #openstack-meeting-alt18:51
*** zyuan has joined #openstack-meeting-alt18:53
*** cppcabrera has joined #openstack-meeting-alt18:56
*** amitgandhi has joined #openstack-meeting-alt18:56
*** malini has joined #openstack-meeting-alt18:58
*** bryansd has joined #openstack-meeting-alt19:00
*** kgriffs has joined #openstack-meeting-alt19:00
*** flaper87 has joined #openstack-meeting-alt19:03
*** jrodom has joined #openstack-meeting-alt19:03
*** Sriram has joined #openstack-meeting-alt19:03
kgriffso/19:03
flaper87\o/19:04
kgriffslet's get this party started19:04
megan_wwoohoo19:04
kgriffs#topic marconi19:05
kgriffs#startmeeting marconi19:05
openstackMeeting started Thu Jul 18 19:05:16 2013 UTC.  The chair is kgriffs. Information about MeetBot at http://wiki.debian.org/MeetBot.19:05
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:05
*** openstack changes topic to " (Meeting topic: marconi)"19:05
openstackThe meeting name has been set to 'marconi'19:05
cppcabreraWoot19:05
flaper87\o/19:05
kgriffs#topic review actions from last time19:05
*** openstack changes topic to "review actions from last time (Meeting topic: marconi)"19:05
kgriffs#link http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-07-11-19.03.html19:05
kgriffs1.oz_akan_ and flaper87 to investigate mongo insert performance19:05
flaper87kgriffs: It wasn't possible to do that, we'll have to schedule it for next week19:06
kgriffsok19:06
kgriffs#action oz_akan_ and flaper87 to investigate mongo insert performance19:06
kgriffs2. flaper87 to document client cleanup19:07
flaper87kgriffs: I started it here: https://etherpad.openstack.org/apiclient-marconi and folks helped me out19:07
flaper87Alessio added a bunch of stuff there19:07
kgriffssweet. can we get these turned into bugs/bp's?19:07
cppcabreraYup. I can do that today.19:08
* cppcabrera volunteers for action19:08
kgriffsimaginary internet bonus points (IIBP's) for anyone who helps!19:08
flaper87cppcabrera: I'll help you with that19:08
*** sarob has quit IRC19:08
*** mattf has left #openstack-meeting-alt19:08
cppcabreraAwesome, flaper87!19:08
kgriffs#action cppcabrera, flaper87 to turn apiclient-marconi etherpad into bps/bugs19:08
*** sarob has joined #openstack-meeting-alt19:09
kgriffs3. flaper87 to merge patches19:09
kgriffswell, that's rather specific, isn't it?19:09
kgriffs:p19:09
cppcabreraHahaha19:09
flaper87wheheheheheh19:09
cppcabreraCommon lib patches were merged.19:09
flaper87yeah, and we pointed out what needs to be done next19:09
kgriffssweet. nice work19:10
cppcabreraI think the input validation framework is still pending? Is that correct?19:10
zyuanyes.19:10
flaper87yup19:10
kgriffs4. flaper87, cppcabrera to finalize client design19:10
cppcabreraWe certainly rocked out on that item last week. All kinds of brainstorming happened.19:10
Sriram+119:10
flaper87indeed +119:10
kgriffsstill some loose ends there?19:10
cppcabrera#link https://wiki.openstack.org/wiki/Python_Marconi_Client19:10
flaper87cppcabrera: good work on that!19:11
cppcabrera#link https://wiki.openstack.org/wiki/Marconi/specs/zmq/api/v119:11
* flaper87 didn't know that page exists.19:11
flaper87glad it does19:11
flaper87cppcabrera: +119:11
zyuanthere are many thoughts on the input validation, while the auther is not in the office.19:11
cppcabreraA few loose ends remain, mostly in regards to adding polling support (drafting that now), and... some I can't think of yet. :P19:11
kgriffs#action cppcabrera to tie up loose ends re python-marconicient v1 design19:12
kgriffs5. zyuan to write up metadata handling proposal and review next time19:12
cppcabrera+1. I'll pick all your brains on that. :D19:12
zyuanwrote, as in the comment19:13
* kgriffs wonders if cppcabrera is secretly a zombie19:13
zyuansee card #28719:13
zyuanQAQ19:13
kgriffsok, let's take that topic now19:13
*** cp16net is now known as cp16net|away19:13
kgriffs#topic metadata handling proposal19:13
*** openstack changes topic to "metadata handling proposal (Meeting topic: marconi)"19:13
*** sarob has quit IRC19:13
kgriffszyuan: you have the floor. :D19:14
*** vipul is now known as vipul-away19:14
*** vipul-away is now known as vipul19:14
kgriffs(15 minutes)19:14
kgriffs(for this topic)19:14
zyuanfirst i want to clearify19:15
kgriffsI've discussed this at length already with zyuan, so I'll sit on the sidelines for a bit19:15
zyuanthe checking is costly.19:15
zyuanbecause the checking is to check have a user used a _name we already defined"19:16
zyuannot just to check whether the user have _ prefix in their metadata19:16
zyuanto distinguish "their" metadata from ours, we have to check all the _ prefixed metadata one by one19:17
zyuan1st it decreases runtime performance19:17
zyuan2nd it makes it hard for us to define new _names19:18
zyuan(the list will become longer and longer)19:18
zyuan(and can hardly be driver-specific)19:18
cppcabreraI agree on the performance portion. It's O(n), given n is the number of metadata fields defined. The actual check can be against a dictionary of reserved names O(1). So O(n) * O(1).19:18
flaper87TBH, I was thinking about that as forbidding anything starting with _19:19
zyuancppcabrera: trust me, never think O(1) is cheap19:19
flaper87that will avoid having to have a secondary list with reserved words19:19
zyuanO(1) is cost -- when compared with 119:19
flaper87if we don't want to use _ for reserved metadata, we can pick another prefix19:20
zyuanflaper87: i considered about that.19:20
zyuanlike C++'s std namespace19:20
zyuanwe can have our own19:20
cppcabreraHmm... namespaced metadata... that sounds pretty awesome.19:20
zyuanbut the core problem is not changed: what if a user expend the std namespace and add their own stuff?19:20
zyuan(some programmers really open the std namespace....)19:21
cppcabreraNo need to check user meta - that can be bundled as "metadata" : { "user" : { "mine" : ...} } and ours can be in "metadata" : { "private": { ... } }19:21
cppcabreraWhat if used that kind of scheme?19:21
flaper87well, the limit is up to us. What about just keeping everything in a separate metadata field that we *don't* return?19:21
cppcabreraflaper87: Roughly what I was thinking.19:22
flaper87cppcabrera: :P19:22
zyuanthen user can't see their configurations19:22
flaper87my turn to squize your brain19:22
kgriffsflaper87: we would need a different resource type to support setting it19:22
flaper87:D19:22
cppcabrera:)19:22
zyuanwhen i was implementing per-queue grace, i found that we have to return it19:22
flaper87kgriffs: that would make acl easier, wouldn't it ?19:22
kgriffsso, either same resource type with reserved sub-document name (namespace) or two different resources19:23
flaper87btw, just thinking outloud19:23
amitgandhireserved namespacing +119:23
zyuanas i said, a reserved namespace does not solve the problem intrinsincally.19:24
kgriffszyuan: pls elaborate19:24
zyuancheck or not check is the 1st problem19:24
zyuanhow to reserve -- 2nd problem19:25
flaper87zyuan: if we don;t answer the 2nd we won't be able to answer the 1st, IMHO19:25
kgriffslet's assume we namespace reserved variables19:25
kgriffs(for the sake of argument)19:25
kgriffshow does that effect 1st problem?19:26
kgriffsaffect19:26
zyuanmy opinion is, it does not.19:26
zyuanif you want to enforce the checking, you need to perform the checking wherever you have "reserved" things.19:27
cppcabreraI does change the check a lot, in my eyes. It changes the check from verifying whether *any* field in metadata is a reserved one to checking whether the PATCH operation contains a document that identifies itself with the key "reserved".19:28
*** marcos_sb has quit IRC19:28
cppcabreraHmm...19:28
kgriffsbut we want to allow them to PATCH that portion, no?19:29
cppcabreraRight. I got things mixed. :P19:29
zyuanoh, then you need to verify *any* fields in your reserved interface19:29
*** vipul is now known as vipul-away19:29
zyuans/interface/namespace/19:29
cppcabreraI was thinking of the "create metadata" and thought I meant patch, heh.19:29
cppcabreraBut yeah, we disallow users from creating new metadata fields in the reserved space.19:29
cppcabreras/space/namespace19:30
zyuanthere is no PATCH opt for queue; only PUT19:30
cppcabrerazyuan: Yup, I remembered after I posted my sentence. :)19:30
Sriramyes. i think there is a patch for only for claims.19:30
zyuanthen you have to check the names under the reserved namespace19:30
flaper87but, the reserved metadata should be used internally, right?19:30
*** cp16net|away is now known as cp16net19:30
Sriram*ignore first for19:30
kgriffsso, sounds like namespacing maybe helps psychologically, but not necessarily technically?19:31
zyuankgriffs: yes. it may looks clearer, but the problem is still there.19:31
zyuan(but to me, i think _ is enough...)19:31
zyuan(if your argument is like "who will touch 'metadata'")19:32
flaper87I think we should think about a real use-case19:32
flaper87(For the sake of the argument)19:32
kgriffsgo for it19:32
zyuan(i can answer "who will touch _names?")19:32
* cppcabrera wishes we had a whiteboard to think this one out19:32
* kgriffs budgets a few more minutes for this topic19:32
Sriram+1, a real use-case will help.19:32
cppcabrera+1 flaper8719:32
kgriffsstand by19:33
zyuanexample, if we have a field (w/o namespace/prefix)19:33
zyuancalled "grace"19:33
zyuanwith prefix19:33
flaper87so, when we first talk about reserved emtadata, IIRC, we were thinking about having different custom TTL per queue19:33
flaper87I mean, queue level TTL, IIRC19:33
zyuanit's "_grace"19:33
flaper87or grace19:33
zyuanif you want to do the checking, you need to keep a list of those names19:34
kgriffsyes, that's a good example - queue-level defaults if not specified per message/claim19:34
zyuanand theck the global namespace19:34
cppcabrera+1 for context19:34
zyuanif we use a reserved namespace instead19:34
flaper87so, having a queue level default means we have to read it everytime a message will be posted19:34
zyuansay, "metadata"19:34
zyuanthen the global namespace become19:34
kgriffsflaper87: yes, but we could cache I suppose19:34
zyuan{"metadata" : {"grace": 60}}19:35
flaper87which means that it won't be enough to have *just* the queue id when doing that19:35
kgriffs(memcached/redis colocated on app server)19:35
flaper87kgriffs: right right, just bringing the worst case scenario19:35
flaper87well, actually, that helps with the context19:35
zyuanthen you need to open the "metadata" field and keep checking the reserved names....19:35
kgriffsanyway, let's hold off on that tangent until another time19:35
flaper87so, lets think we have this cache system19:35
zyuanproblems become more: "metadata" may not be a dict....19:35
flaper87what would we put into that cache if we have everything mixed?19:36
flaper87we would have to separate *our* metadata from user's and store it in the cache19:36
flaper87so, that makes me think that a separate field for that would make sense19:36
*** arborism has joined #openstack-meeting-alt19:37
zyuani think it's ok to store anything metadata in the cache19:37
zyuanit's actually more simple, and cheap if we have a configurable json parser19:37
*** sarob has joined #openstack-meeting-alt19:37
zyuani mean, a proposed parser which can stop parsing at some level of the elements19:37
zyuanand don't forget, we have size limit on queue metadata -- as a whole19:38
flaper87zyuan: but that requiers more memory, right? And we'll have to update it everytime the metadata is updated. (re putting everything on cache)19:38
zyuanwe have size limit, the space should not matter that much19:39
kgriffswe could also compress with snappy19:39
zyuanthe thing matter may be the performance -- with our own namespace, the processing logic becomes more complex19:39
flaper87but you'd be counting the reserved metadata size as part of the queue metadata size19:39
kgriffsbut idk if cache is faster than mongo if you have it centralized19:39
flaper87unless we split them19:39
kgriffshere is how splitting into two resource types may look:19:40
kgriffshttps://etherpad.openstack.org/queuing-scratch19:40
zyuanwhich is not nessasory, from my point of view19:40
cppcabrera+1 kgriffs (a whiteboard!)19:40
cppcabrerai like this separation of config from metadata...19:41
kgriffsmeta would have no size checks except valid JSON and size19:41
cppcabrera*I19:41
cppcabreraconfig would have type checks, since we know what they are ahead of time.19:41
flaper87I prefer the second one19:42
zyuanthen what's the queue metadata for? what if user PUT garbage into the /meta19:42
kgriffsfor our first release, we just don't reference the config/settings/whatever resource in the home document19:42
kgriffsso, we kick the can down the road and have more time to come up with a good solution19:42
kgriffsI think we just ignore garbage fields19:42
kgriffsbut still check overal doc size for sanity19:43
cppcabreraSounds good to me.19:44
flaper87+119:44
kgriffszyuan: I'm not saying this solves the fundamental problem of schema checking vs. backwards compat with clients, but it lets us divide and conquer19:44
Sriramyes, this looks good.19:44
malinithis is one of the longest 15 minutes :)19:45
zyuansoo... what's the plan for the 1st release?19:45
kgriffsif we go with this, then what happens if you GET /v1/queues/foo19:45
kgriffs405 ?19:45
zyuanPUT has no content at all?19:46
kgriffsor do we leave as-is, and later add /queues/foo/defaults19:46
kgriffsthe original design was based on swift semantics, where they overload metadata headers to do fancy things19:46
kgriffsI wonder if that is the best approach after all?19:47
cppcabrerax-delete-at, x-delete-after...19:47
zyuan/queues/foo/defaults looks too fancy to me....19:47
*** malini has left #openstack-meeting-alt19:47
*** akuznetsov has quit IRC19:47
flaper87can we have /queues/foo/meta/foo ?19:47
*** jrodom has quit IRC19:47
flaper87in the first release?19:47
flaper87then we'll add more things when needed19:48
*** jrodom has joined #openstack-meeting-alt19:48
flaper87s/meta/metadata/19:48
kgriffswhat's the lat "foo"19:48
kgriffss/lat/last19:48
kgriffs?19:48
kgriffs(almost time for a vote)19:48
flaper87ah remove that foo19:48
flaper87/queue/foo/metadata/19:48
zyuanmy option: leave things as-is19:48
flaper87if we leave things as they are, we, most likely, will have to break backward compatibility in our next release19:49
*** oz_akan_ has joined #openstack-meeting-alt19:49
kgriffszyuan: as-is, including reserved prefix?19:49
zyuani don't like to invent needs19:49
zyuankgriffs: we have that in doc, and we don't care the guys want to challge us19:50
*** SergeyLukjanov has quit IRC19:51
zyuandoes the current design close the door of a more fancy metadata?19:51
*** ruhe has quit IRC19:51
flaper87no if we decide to have reserved words (and checks) within the existing metadata19:51
flaper87but if we want to split them, then yes19:51
*** amitgandhi has quit IRC19:51
zyuani'm OK with two metadata plan; i'm c++ guy :)19:52
*** akuznetsov has joined #openstack-meeting-alt19:52
flaper87so, vote? as-is or add new metadata resource to the queue ?19:53
kgriffs#startvote Should we keep queue metadata API as is (a), create a metadata type (b), or keep as-is, but not reserve a prefix, adding one or more new settings types later? a, b, c19:53
openstackBegin voting on: Should we keep queue metadata API as is (a), create a metadata type (b), or keep as-is, but not reserve a prefix, adding one or more new settings types later? Valid vote options are a, b, c.19:53
openstackVote using '#vote OPTION'. Only your last vote counts.19:53
flaper87#vote a19:53
flaper87#vote b19:53
flaper87sorry19:53
flaper87arrg19:53
flaper87:)19:53
kgriffsfortunately, only last vote counts. :D19:54
flaper87indeed :P19:54
cppcabrera#vote b19:54
Sriram#vote b19:54
zyuan#vote a19:54
zyuan...19:54
kgriffsanyone else in the room?19:54
zyuanthe explaination looks... confusing....19:55
zyuanwhat exactly (b) is?19:55
kgriffsthat is what flaper87 proposed19:55
megan_wkgriffs: in the room, but trust you guys to decide19:55
kgriffs:D19:56
kgriffs"/queue/foo/metadata"19:56
zyuanthen (c) looks not so good.19:56
zyuanwhy adding new routes in the future conflict with reserving _names now?19:57
kgriffszyuan: it is cleaner, if we add _foo, then harder to migrate that to a different resource later19:58
kgriffs#showvote19:58
openstacka (1): zyuan19:58
openstackb (3): cppcabrera, Sriram, flaper8719:58
kgriffsanyone want to change their vote?19:58
zyuanclean... he he19:59
flaper87kgriffs: u gotta vote19:59
kgriffsyou have 10 seconds19:59
bryansd#vote b19:59
kgriffs#vote b19:59
* bryansd votes for pop-tarts, too19:59
kgriffsheh19:59
Sriram+1 for pop tarts :D19:59
kgriffs#endvote19:59
openstackVoted on "Should we keep queue metadata API as is (a), create a metadata type (b), or keep as-is, but not reserve a prefix, adding one or more new settings types later?" Results are19:59
openstacka (1): zyuan19:59
* cppcabrera votes for donuts19:59
openstackb (5): bryansd, kgriffs, cppcabrera, Sriram, flaper8719:59
* flaper87 gives bryansd pop-tarts19:59
kgriffsok, so this is obviously a breaking change. Let's get it done ASAP20:00
cppcabreraThat's all the time we have, I believe. Any closing comments?20:00
* bryansd is bringing doughnuts tomorrow20:00
kgriffsso, quick one about priorities20:00
zyuani'm looking at the board and in deep thinking...20:00
kgriffslet's finalize API, continue focus on bugs and robustness and performance20:00
flaper87kgriffs: +1 (and client)20:01
kgriffsright20:01
kgriffsfocus on HTTP transport for now, ZMQ is lower priority20:01
*** Sriram has quit IRC20:01
flaper87+120:01
oz_akan_we need to finalize placement service design20:01
*** Sriram has joined #openstack-meeting-alt20:01
cppcabrera+120:02
flaper87oz_akan_: we're planning to discuss it on Monday20:02
flaper87since Amit will be out tomorrow20:02
kgriffsok, let's talk metadata implementation in #openstack-marconi20:02
flaper87rock on20:02
flaper87great work everyone20:02
oz_akan_ok20:02
flaper87Those bugs are afraid of us20:03
kgriffs#action oz_akan, amit, flaper87 to finalize placement service strategy20:03
kgriffs#endmeeting20:03
*** openstack changes topic to "OpenStack meetings (alternate)"20:03
openstackMeeting ended Thu Jul 18 20:03:47 2013 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)20:03
openstackMinutes:        http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-07-18-19.05.html20:03
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-07-18-19.05.txt20:03
openstackLog:            http://eavesdrop.openstack.org/meetings/marconi/2013/marconi.2013-07-18-19.05.log.html20:03
kgriffsthanks guys!20:03
oz_akan_thanks20:03
cppcabrera:)20:04
*** cppcabrera has left #openstack-meeting-alt20:04
SriramWoot!20:04
*** flaper87 has left #openstack-meeting-alt20:04
*** RajeshMohan has quit IRC20:06
*** RajeshMohan has joined #openstack-meeting-alt20:06
*** vipul-away is now known as vipul20:06
*** RajeshMohan has quit IRC20:06
*** RajeshMohan has joined #openstack-meeting-alt20:06
*** pcm_ has quit IRC20:13
*** Nadya has quit IRC20:13
*** RajeshMohan has quit IRC20:15
*** akuznetsov has quit IRC20:17
*** kgriffs is now known as kgriffs_afk20:18
*** IlyaE has quit IRC20:19
*** jmaron has quit IRC20:26
*** abaron has quit IRC20:29
*** bryansd has left #openstack-meeting-alt20:29
*** markwash has quit IRC20:32
*** sarob_ has joined #openstack-meeting-alt20:32
*** markwash has joined #openstack-meeting-alt20:34
*** sarob__ has joined #openstack-meeting-alt20:34
*** sarob_ has quit IRC20:35
*** sarob has quit IRC20:36
*** nkonovalov__ has quit IRC20:49
*** sarob__ has quit IRC20:54
*** sarob has joined #openstack-meeting-alt20:54
*** jmaron has joined #openstack-meeting-alt20:56
*** Riddhi has quit IRC20:58
*** Riddhi has joined #openstack-meeting-alt20:58
*** sarob has quit IRC20:59
*** vipul is now known as vipul-away21:00
*** djohnstone has quit IRC21:01
*** jmaron has quit IRC21:06
*** sarob has joined #openstack-meeting-alt21:07
*** sarob has quit IRC21:08
*** sarob has joined #openstack-meeting-alt21:09
*** sarob has quit IRC21:13
*** vipul-away is now known as vipul21:15
*** sarob has joined #openstack-meeting-alt21:16
*** demorris has quit IRC21:16
*** crobertsrh is now known as _crobertsrh21:29
*** pdmars has quit IRC21:30
*** Sriram has quit IRC21:31
*** jmaron has joined #openstack-meeting-alt21:32
*** jmaron has quit IRC21:39
*** kgriffs_afk is now known as kgriffs21:41
*** oz_akan_ has quit IRC21:42
*** vkmc has quit IRC21:44
*** megan_w has quit IRC21:55
*** sarob has quit IRC21:59
*** sarob has joined #openstack-meeting-alt22:02
*** jcru has quit IRC22:23
*** lastidiot has quit IRC22:23
*** jmaron has joined #openstack-meeting-alt22:35
*** jmaron has quit IRC22:40
*** akuznetsov has joined #openstack-meeting-alt22:49
*** akuznetsov has quit IRC22:51
*** jmaron has joined #openstack-meeting-alt23:01
*** sarob has quit IRC23:02
*** sarob has joined #openstack-meeting-alt23:02
*** sarob has quit IRC23:03
*** sarob_ has joined #openstack-meeting-alt23:03
*** vipul is now known as vipul-away23:03
*** vipul-away is now known as vipul23:09
*** jrodom has quit IRC23:19
*** vipul is now known as vipul-away23:25
*** vipul-away is now known as vipul23:26
*** sarob_ has quit IRC23:34
*** jmaron has quit IRC23:34
*** sarob has joined #openstack-meeting-alt23:35
*** sarob has quit IRC23:39
*** IlyaE has joined #openstack-meeting-alt23:41
*** jrodom has joined #openstack-meeting-alt23:41
*** markwash has quit IRC23:44
*** jergerber has quit IRC23:44
*** demorris has joined #openstack-meeting-alt23:46
*** jergerber has joined #openstack-meeting-alt23:52

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!