14:03:38 #startmeeting glance 14:03:39 Meeting started Thu Jul 18 14:03:38 2013 UTC. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:40 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:42 The meeting name has been set to 'glance' 14:03:43 \o/ 14:03:45 \o/ 14:03:48 :) 14:03:52 #topic agenda 14:04:03 hi folks 14:04:09 hi markwash 14:04:12 Hi markwash 14:04:14 lol 14:04:44 at the end of next meeting, I wanna have a pretty good idea of what we're trying to deliver over havana-3 14:04:45 btw, thank you all, for review and landing my patch to H2 14:04:57 but is there other stuff folks want to talk about today? 14:05:04 zhiyan: thank you for working on that 14:05:05 https://etherpad.openstack.org/glance-havana3-blueprints 14:05:25 flaper87: :-D, thanks you! 14:05:38 yes, 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 h2 14:05:54 coool! 14:06:26 markwash: could you pls take a look above link? do you think they are make your sense? 14:07:02 looking 14:07:23 I think those are all good, but I'm still a little unclear about "global state management" 14:07:33 that sounds kind of like something nova does that is problematic 14:07:41 maybe i can create BPs for that (except Enable task, others are all I added) 14:08:14 markwash: following our former plan to get Glance "Out There" - reading, making it a public service - I'd love to see async workers move forward 14:08:14 #topic havana 3 blueprints 14:08:25 flaper87: +1 14:08:29 This is the patch for that 14:08:31 #link https://blueprints.launchpad.net/glance/+spec/async-glance-workers 14:08:35 blueprint* 14:08:38 I think we might have a critical mass at this point 14:08:45 markwash's draft : https://review.openstack.org/#/c/31874/2 14:08:53 flaper87: +1 14:08:57 I have a better idea how I think it should work (my draft is not up to date) 14:09:16 since the registry stuff is ready, I can focus on that and help you with that blueprint 14:09:49 markwash: yes, i'd like post our discussing summary (IRC) to a etherpad page, if you like 14:10:28 also, I think this is important - still sticking to our former plan - to have some quotas in glance. IMHO, we should track this down as well 14:10:31 #link https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas 14:11:35 flaper87: could you pls add them to that etherpad page also? 14:11:43 yeah, I think that is just looking for workers at this point 14:12:06 s/workers/developers 14:12:11 :) 14:12:15 not to be confused with image workers / async processing 14:12:42 markwash: I know John was looking at it (re quotas) 14:12:44 maybe that's truth, 'developer' = 'worker' :) 14:13:19 we could implement async just as a mechanical turk with glance developers manually doing image conversions on their laptops 14:13:29 markwash: LOOOOL 14:13:52 that might cause a security problem I guess :-) 14:13:55 https://etherpad.openstack.org/glance-async-task-discussing 14:14:24 zhiyan thanks 14:15:04 flwang: o/ 14:15:20 markwash:o/ 14:16:15 zhiyan: can you describe the scrubber changes in some more detail? 14:16:31 I'm interested in refactoring it as well, principally to make testing it less brittle and slow 14:17:11 markwash: ok, for now, the biggest issue for it is about 'multiple-locations' supporting IMO 14:18:38 zhiyan: okay cool, makes sense 14:18:44 currently 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:19:01 s/use/user 14:19:15 zhiyan: I think I lost the first message, re scrubber. Sorry. Can you re-send it ? 14:19:28 and other code also need be refactoring 14:19:47 ok, for now, the biggest issue for it is about 'multiple-locations' supporting IMO 14:19:57 zhiyan: +1 14:20:28 I'm also a bit confused about its architecture, not to complicate the discussion, but. . . 14:20:45 it tends to use a local process consuming a file-backed queue of locations to delete 14:20:46 flaper87: actually, i checked scrubber code, IMO it's not so clear... 14:21:09 though it can also periodically query the database and shove images into the local queue for processing 14:21:14 its very scatter brained 14:21:37 and yet, its only a small LOC 14:21:58 meaning to say, its not that hard to replace 14:22:23 markwash: yes, but i'm not followed your last point .. 14:22:46 when I was looking at it for testing purposes, I thought the best thing would be a rewrite 14:22:47 markwash: are you meaning scrubber can be removing? or some change 14:23:07 I don't think we can remove it, because we need something to handle pending deletes 14:23:08 markwash: ok, for change what? 14:23:45 markwash: yes, i think so. but not clear what you want to rewrite..sorry 14:24:06 zhiyan: I was just thinking of completely rewriting the component that handles pending_deletes 14:24:13 so probably completely replace glance-scrubber 14:24:26 markwash: using async-task? 14:24:37 or just internal refactoring? 14:24:43 just internal refactoring 14:24:47 for glance-scrubber .. ok 14:25:15 i will check it when i do that, and I'd like / we can discussing details. 14:25:29 I haven't looked at scrubber that much 14:25:48 flaper87: it's easy, small 14:26:34 but as markwash said, currently it read delete 'task/request' from file 14:26:36 so, I mention that only as a green light to folks if they want to be a bit drastic with it 14:26:46 zhiyan: yeah, I wonder if we'll be ever be able to get rid of it, perhaps using async-workers 14:27:13 markwash: aha, thanks. 14:27:44 zhiyan: are those blueprints in the etherpad that you added all things you plan to work on? 14:27:54 or are some of them just general suggestions of things you think need to be done 14:28:27 flaper87: 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:29:10 markwash: i'd like create them, but i'm not sure i have enough bandwidth do all of them, you know. 14:29:16 zhiyan: agreed 14:29:30 markwash: btw, I remembered another blueprint that I think is important for H-3 14:29:41 zhiyan: makes sense, can you put your name by the ones you *definitely* want to work on, including teh ones already in progress? 14:29:41 markwash: store credentials being saved in the DB 14:29:55 flaper87: ah good point, I think iccha has some current work on that 14:29:58 * flaper87 is trying to find the blueprint 14:30:19 unfortunately the rackspace folks cannot be here today, they have a corporate thing, not just protesting us :-) 14:30:28 markwash: sure, will do. 14:30:30 markwash: yeah, she mentioned it, we should sync with her about that 14:30:32 markwash: LOL 14:30:51 markwash: do we want plan the task bp into h-3? 14:31:06 flwang: I think we do 14:31:12 https://review.openstack.org/#/c/34801/ ? 14:31:16 flwang: it is very important and there are several interested folks 14:31:17 markwash: and this one: https://blueprints.launchpad.net/glance/+spec/glance-cache-path 14:31:51 markwash: yep, but obviously, we need more discussion 14:31:55 I think the cache one is pretyt important as well. 14:32:10 flaper87: agree +1 14:32:26 I'd like to see the cache management is improved 14:32:37 yeah, there have been some definite requests around that 14:33:21 flaper87: markwash: i really think we should write them down to etherpad page 14:33:32 +1 14:33:35 I just added the cache path one 14:33:55 * flaper87 gets the other ones 14:33:56 thanks 14:34:48 btw, i just know iccha is a lady...since flaper87 use 'she'.. 14:34:55 flwang: you're planning on working on the task / async stuff during h3, correct? 14:35:05 yep 14:35:10 zhiyan: she is and she rocks! :D 14:35:14 but I think I need you guys support 14:35:22 to make sure the design is correct :) 14:35:23 flwang: sure thing 14:35:28 flwang: +1 14:35:42 flwang: where are you based? 14:35:43 also there are some other folks for whom async processing is very important, and we need to make sure they are in the discussion 14:35:57 flaper87, Beijing, China 14:36:10 flwang: cool! 14:36:11 currently nikhil is assigned on the blueprint, but I know he's been very busy with some other work as well and would welcome your work 14:36:41 markwash: yep, we have started some discussion since yesterday 14:37:11 flaper87: where are you based? 14:37:14 flwang: paste again for you, a summary we discussed yesterday. https://etherpad.openstack.org/glance-async-task-discussing 14:37:34 zhiyan: great, thanks 14:37:36 flwang: I'll take the cache management one, hopefully, the common oslo cache will land soon as well and we can pull that in 14:37:40 flwang: Como, Italy 14:38:03 flwang: pull me in into the async workers discussions, pls :) 14:38:27 flaper87: have you seen https://blueprints.launchpad.net/glance/+spec/refactoring-move-caching-out-of-middleware ? 14:38:33 flaper87: nice, I love pizza 14:38:43 flwang: markwash: and me pls 14:38:47 flaper87: sure thing 14:39:21 zhiyan: sure 14:40:19 flaper87: I'd be interested in seeing if we can address that refactoring during the process, or if its too much to take on 14:40:30 markwash: mmh, I think I did and forgot. That makes more sense than having a cache service as we discussed once 14:40:41 I'm pretty sad about the way the cache lives at the wsgi middleware layer and thus has to duplicate all the formatting logic 14:40:54 markwash: I think we can do it and it makes sense 14:41:06 markwash: +1 14:41:15 also, multiple-location landed already, that will help us on addressing john's comments as well 14:42:05 I 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 folks 14:42:10 markwash: 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 well 14:42:59 zhiyan: 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 further 14:43:05 perhaps in our next meeting 14:43:05 zhiyan: I think the idea is that for admins, cache could be managed as another location on the image 14:43:25 I'd like to open up the dicussion in case folks have general issues they want to bring up 14:43:34 markwash: o/ 14:43:43 #topic open discussion 14:43:44 markwash: i'd like to know them all 14:43:55 o/ 14:44:14 flaper87: go for it 14:44:28 markwash: do you think it's time to take a look again on https://blueprints.launchpad.net/nova/+spec/image-multiple-location 14:44:38 it's for nova side, but related with glance 14:44:44 I'm pretty concerned about the client and it's support for glance's v2, I know iccha and esheffield are working on it 14:44:58 thanks for you earlier input for that btw. 14:45:20 so, I was planning to take less bps for H-3 and dedicate some more time to the client 14:45:31 flaper87: oh, yes, cinder guy ping me again for it, in yesterday cinder weekly meeting 14:45:38 but, the client needs some review-help 14:45:39 flaper87: that would make me crazy happy 14:45:56 flaper87: just because glanceclient has gay on v2 client, causes cinder has some limitation 14:46:00 markwash know that 14:46:04 a defect 14:46:48 markwash: cool, so, I'll sync with iccha and esheffield and dedicate more time to it 14:46:55 flaper87: noted, I'll double down my efforts to review client patches 14:47:12 should be easy to do, after all 2 * 0 = 0 :-) 14:47:14 markwash: question: How are client releases planned? I know those are just tags but when do they happen? 14:47:30 it essentially has its own roadmap 14:47:49 for now, the roadmap issues are v2 support and deprecating legacy I believe 14:47:59 markwash: ok, so it's feature based 14:48:09 once those are covered, we can release a new version 14:48:11 yeah, it is not tied into the general openstack release 14:48:28 oke-doke! 14:48:39 I'm still really interested in someone basically taking on the client as pseudo-ptl, honestly 14:48:52 because I keep accidentally ignoring it to focus on the server side 14:48:58 markwash: I raised my hand the last time :D 14:49:27 I think you'd be a good fit, but we probably have to sync up more to make the transition 14:49:33 markwash: flaper87: can you take a look on https://review.openstack.org/#/c/37616/ ? 14:49:51 for resolve this: https://bugs.launchpad.net/glance/+bug/1202391 14:49:56 zhiyan: yes, thanks for that 14:50:24 markwash: yup, we should also ask iccha! 14:50:33 +2 pls, if you ok, just don't like other guys say my patch block something. :) 14:50:35 is it time to call for reviewer ? :) 14:50:39 oke, that was my point for the open discussion 14:50:41 :D 14:51:16 was wondering did anyone have any thoughts on the topic of unicode in exceptions... 14:51:29 bourke: ? 14:51:37 bourke: https://review.openstack.org/#/c/37421/ ? 14:51:47 flaper87: both yourself and zhiyan have a nice fairly similar solution there 14:52:03 zhiyan: https://review.openstack.org/#/c/36658/ 14:52:05 :D 14:52:07 yes, i lean from flaper87 :) 14:52:30 flaper87: but was wondering what about other exceptions. is it something that could be wrapped in a function and used in multiple places? 14:52:32 aha, since you give me a comment, so i checked your patch, and got it 14:52:50 markwash: flaper87: may I get your comments about this https://review.openstack.org/#/c/37511/ ? 14:53:06 bourke: can we take care that be case by case? defect driven maybe more easy 14:53:15 zhiyan: +! 14:53:17 zhiyan: +1 14:53:36 sure thing 14:54:03 bourke: thanks you for you raise this up, i just forget it... 14:54:25 flwang: I like that you are getting the latest oslo.rpc code, but I'd still slightly prefer to see it in another patch 14:54:42 flwang: maybe you can ask the other submitter to update their patch with the latest code? 14:54:47 markwash: yes https://review.openstack.org/#/c/37184/ 14:55:05 flwang: have you looked at the new oslo.messaging? 14:55:47 I wonder whether it is worth to pull oslo's rpc code into glance instead of waiting 'til new oslo.messaging is ready 14:55:57 5 mins left 14:56:24 flaper87: nope, what's up? 14:56:26 flaper87: I think the goal here is to use notifier, which depends on rpc 14:56:47 markwash: yes 14:56:49 markwash: indeed, that notifier will depend on oslo.messaging by the end of H-3 14:57:05 flaper87: well, that's pretty nice 14:57:05 oh, one other thing, if someone could take a look at https://review.openstack.org/#/c/35286/ that would be much appreciated 14:57:18 is it worth to pull all that in instead of waiting for that migration to happen ? 14:57:20 flaper87: any blueprint or bug to track that? 14:57:31 flwang: erm, let me check 14:57:37 bourke: looks like an easy +2 approve, will check immediately after mtg 14:57:52 markwash: thanks! 14:58:07 flaper87: do you know if its like "early h3" for being ready? or last minute? 14:58:13 and https://review.openstack.org/#/c/36884/ and https://review.openstack.org/#/c/37222/ 14:58:30 flaper87: it oslo.messaging is the direction, it would be nice to do that 14:58:32 markwash: I'd say last minute 14:59:14 any other folks have last minute notices or announcements? 14:59:19 markwash: so I still can't get approve for my fix ? O:-) 14:59:34 flaper87: any comments? 14:59:50 flwang: TBH, I'd wait for that before pulling oslo's notification in 15:00:11 because oslo.rpc has some config parameters that might change when oslo.messaging is complete 15:00:30 markwash: just notice, pls review https://review.openstack.org/#/c/37616/ for fix https://bugs.launchpad.net/glance/+bug/1202391 15:00:35 among other things 15:00:58 flaper87: that makes sense 15:01:30 markwash: how do you think? IMO, I think we can do the refactoring for notifier and follow up the change of oslo.messaging 15:01:50 we can, but it increases the operational burden 15:01:56 I think we have to clear out now folks 15:02:06 thanks errbody 15:02:10 kk, good meeting! Thanks to all!! 15:02:11 #endmeeting