14:01:21 #startmeeting glance 14:01:22 Meeting started Thu Dec 19 14:01:21 2013 UTC and is due to finish in 60 minutes. The chair is markwash. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:01:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:01:25 The meeting name has been set to 'glance' 14:01:45 hi 14:01:46 o/ 14:01:48 o/ 14:02:02 |o/ 14:02:08 flaper87: \o 14:02:15 markwash: o/ 14:02:34 zhiyan: yo 14:02:43 just the three of us? (we can make it if we try) 14:03:18 markwash: lets do it 14:03:27 I've a couple of things I'd like to get your thoughts on 14:03:30 :D 14:03:53 okay 14:04:01 o/ 14:04:06 rosmaita: good morning 14:04:07 markwash: if we have time, i have a little question 14:04:17 zhiyan: it looks like we might have lots of time 14:04:28 flaper87: good afternoon! 14:04:42 todays agenda: https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:05:56 markwash: ok. actually it's a question for my location-status bp implementation. i believe we can talk it offline also. 14:06:11 so first item, we won't have a meeting next week 14:06:21 rosmaita: hello 14:06:29 do folks here want to meet on Jan 2nd? I think it probably works for me 14:07:11 markwash: I'd say 9th 14:07:20 zhiyan: howdy 14:07:38 i will be offline jan 2 14:07:44 it'll probably work for me too but I'm not sure yet 14:07:46 okay, seems fine then, the 9th 14:07:50 kk 14:08:07 Next meeting will be at 2000 UTC on Jan 9 14:08:15 #topic reviews 14:08:21 markwash: cool 14:08:44 Just briefly wanted to mention that we still have a fair amount of work to do on our review queue 14:09:00 #info Next meeting will be at 2000 UTC on Jan 9 14:09:10 and I'm going to be free from the bonds of the day job for the next chunk of time, so I'll be putting in a near daily effort on it despite the holidays 14:09:37 so if you have a bit of time, be sure to check the queue for things that just need one more +2 14:11:07 flaper87: want to share your thoughts next? 14:11:17 markwash: yup 14:11:25 #topic flaper87's thoughts 14:11:29 :-) 14:11:32 LOL 14:11:47 the first thing I'd like to get your thoughts on is this review: https://review.openstack.org/#/c/59150/ 14:12:18 I really don't think we should be enabling all the stores by default, instead that should be an explicit action 14:12:41 Most of the stores - besides http + file - need lot of configs that are not there by default 14:12:52 flaper87: agreed 14:12:54 and will confuse users when glance starts 14:13:09 now, the tests there fail because we need this patch in: https://review.openstack.org/#/c/59177/ 14:13:11 flaper87: but i just meaning we need change others to make it work well 14:13:30 which is a devstack patch 14:14:03 I talked with sdague today and I'd also need your thoughts there as a consensus of this change 14:14:15 zhiyan: not sure what you mean 14:14:25 flaper87: okay, I've starred the reviews 14:14:50 In general I think this change in default makes sense but I'm still processing the concerns I see raised there 14:14:53 flaper87: hum..i'm trying explaining my comments in https://review.openstack.org/#/c/59150/1/glance/store/__init__.py 14:15:05 especially last one 14:15:34 markwash: agreed. I put some thoughts there 14:16:06 so, distros don't override config files - and if there's a distro doing that, it's not a good one - which means that users will notice the change 14:16:23 and if they're upgrading from H to I they'll have to look into those files 14:16:36 that said, I doubt there's an environment with all those stores enabled 14:16:41 I really doubt it 14:16:54 and if there's one, I want to know why :D 14:17:00 (that was a joke( 14:17:02 ) 14:17:09 zhiyan: I think you're especially asking for some better error handling when an unsupported store is accessed? 14:17:24 o/ 14:17:25 this change will bring benefits to glance and to the users of it 14:17:34 I agree there should be a better error handling 14:17:42 but I don't think that's the solution for this issue 14:17:53 stores *have* to yell when they're not configured correctly 14:17:58 and that's what they do now 14:18:07 markwash: part of. you when user finish upgrade, then error is not make sense. 14:18:11 we could improve the messages being printed 14:18:21 but still, I think it's not worth it to enabled them all 14:18:32 flaper87: I was imagining the error handling was about reporting errors *with* your patch, not instead of it 14:18:42 but still not sure 14:18:58 iccha: o/ 14:19:08 markwash: yeah, I think I misread zhiyan comment maybe 14:19:19 but anyway, I think both should happen 14:19:20 hey markwash :) 14:19:24 iccha: heyyyy 14:19:27 :D 14:19:28 hey flaper87 14:19:45 I've got those reviews starred now which means I think I can effectivlye prioritize following up 14:20:13 awesome I think at least 2 other cores should chime in in both patches 14:20:16 to show consensus 14:20:32 I explicitly asked not to approve the devstack patch until we agree that's the way to go 14:20:40 okay, flaper87 other thoughts? 14:20:44 yup 14:20:45 just one more 14:21:50 I've been thinking that other projects (nova, glanceclient (?) ) could benefit from the glance.stores code. The API there seems pretty stable. I would like to know what you guys think about pulling that could out of glance into its own lib 14:21:58 we could move it into oslo 14:22:04 and then use it somewhere else 14:22:13 I think it's not that tight to glance 14:22:24 and it exposes useful methods to interact with stores 14:22:29 either they are remote or local 14:22:44 flaper87: just curious what other components talk directly to the stores? 14:23:12 hmm interesting idea 14:23:16 none yet but, if we want to improve nova and let it interact with the store we could use it 14:23:36 zhiyan: and myself are working on zero-copy for nova 14:23:45 one of the things we'd like add there is multi-locations 14:23:46 making it easier for nova and cinder to talk direclty to stores would be nice 14:24:05 and it'd be cool to let nova access the remote location 14:24:05 though I was wondering if code like that might better live in someplace accessible through glanceclient 14:24:14 and making it so all projects talk the same way would be good for the stores 14:24:25 we could reduce technical debt 14:24:42 flaper87: probably we need rethink a little for store's interface. 14:24:44 I thought about a library because I think it could be useful for other scenarios outside openstack 14:25:03 and btw, i think this is a little related with John's bp 14:25:11 I first thought about pulling it into glanceclient then I thought about having a glance.stores lib 14:25:17 store plugin (or something like that) 14:25:24 zhiyan: ++ 14:25:25 and my last thought was moving it into oslo first 14:25:31 zhiyan: yeah 14:25:40 that most likely will need to happen 14:25:57 but before getting there, I wanted to know your thoughts about that 14:26:01 I think a stores lib could work nicely. . and it wouldn't prevent us from reusing logic through glanceclient 14:26:06 i'm thinking can we merge those two ideas to one? 14:26:10 markwash: exactly 14:26:30 zhiyan: yup, all that will happen as part of the lib creation 14:26:57 there's some logic zhiyan has been working on that is somewhat related, essentially applying selection strategies for dealing with multiple locations. . I guess that would *not* be in the stores lib but would be reused through the glanceclient. . do you agree? 14:27:18 is there a patch? 14:27:30 markwash: agree 14:27:34 yeah 14:27:36 curious why client needs store logic. sorry been lil outta sync 14:27:36 just is what i want to say 14:27:57 iccha: the idea is for any client to be able to talk directly to the store 14:28:01 glance client lib can also include api discovery part. iiuc 14:28:25 not just nova 14:28:31 iccha: https://blueprints.launchpad.net/glance/+spec/image-location-selection-strategy 14:28:42 interesting, then the client lib can be used in any project 14:28:45 thanks zhiyan 14:28:48 zhiyan: sorry I have not given you any reviews yet! 14:29:01 iccha: :) happy can get your comments btw 14:29:12 markwash: hehe 14:29:29 Agreed 14:29:31 markwash: i really hope tbh 14:29:47 also, location selection should also be done based on the glanceclient location 14:29:54 i guess this would force us to improve credentials handling for the stores 14:29:57 like getting the best / nearest remote location to the client 14:30:00 etc 14:30:21 rosmaita: yes and no 14:30:30 so, the stores currently don't store the location 14:30:33 we do it in glance 14:30:56 just one point to keep in mind, when we start encouraging other projects like nova talking directly to stores, is that the number of compute nodes >>> glance nodes 14:31:01 which means we need to improve the way we're keeping it in glance. (I may be saying something stupid here) 14:31:06 flaper87: how should we proceed with this idea? are you going to work on it? what kind of spec would you want to see 14:31:17 rosmaita: I haven't followed the credentials work very closely 14:31:38 flaper87: I think that's basically correct, depending on how the api for a storage lib is defined 14:31:39 flaper87: not at all, the problem I see is glance can tell you where something is, but you need to have your own credentials to actually get it 14:31:43 markwash: The first thing we need to do is choose whether to have glance/stores or oslo.stores 14:31:47 I vote for the later 14:31:56 markwash: agree 14:31:58 then create a bp for oslo and I'll pull it out 14:32:10 so if you use a glance-owned container for images, then there's a credentials problem 14:32:19 rosmaita: agreed, not sure we want to spread the swift backend creds more than we need to 14:32:31 hmm, I actually prefer the former. . this seems like a case where we have an established supported api already, or nearly 14:32:39 mclaren: +1K 14:32:43 lol 14:32:44 no need to iterate on it in the copy-paste fashion 14:32:52 flaper87: =1 to markwash's 14:32:58 +1 14:33:01 markwash: but we could aim to have an oslo.store right away 14:33:06 rosmaita: I think what you're saying is "the stores lib would not be useful until we fix the creds issue" 14:33:06 just ruined mclaren and rosmaita 's slepe for next few days 14:33:08 just because we have an established api 14:33:15 instead of entering into oslo-incubator 14:33:20 rosmaita: not "the stores lib will make the creds issue worse" 14:33:22 I guess we could discuss that in the m-l 14:33:22 markwash: exactly, thank you 14:33:33 (I don't want to highjack this but multi-tenant would help with direct access...) 14:33:44 i think this could be an opportunity to get keystone to make some improvements 14:34:02 mclaren: i'm not sold on multi-tenant 14:34:22 ok, that's it from me 14:34:22 flaper87: perhaps, I guess ml is the best place to figure that out. . seems like it might be something that we could keep under the images program though 14:34:38 flaper87: so yeah if you want to bring that up on the ML that would be great 14:34:43 okay, moving on! 14:34:44 rosmaita: mclaren I agree with you 14:34:47 markwash: I will 14:34:51 thank you guys 14:34:59 we've been going in a slightly roundabout fashion today agenda-wise 14:35:53 zhiyan: did you have an item for us before we try to dive in on the domain model? 14:36:07 (not sure we have all the folks that were intended for that conversation 14:36:08 ) 14:36:14 yeah 14:36:19 markwash: can we talk this part off line? thanks 14:36:21 lot of ppl seem missin 14:36:34 zhiyan: sure, that's fine 14:36:54 markwash: cool. (will ping you) 14:37:04 okay, then I'd like to at least visit the blueprint process notes 14:37:09 #topic blueprint process 14:37:23 https://etherpad.openstack.org/p/glance-blueprint-process 14:37:53 so i have been doing some research on blueprint process for openstack and what other projects follow 14:38:21 nova has a really interesting process : they have a separate team called the drivers 14:39:14 every person who submits a blueprint is responsible for assigning to deliver it by a given milestone and a condition stating this blueprint is done when 14:39:22 and a detailed enough description 14:39:32 this is then reviewed by team of drivers 14:39:48 so drivers are like core except for blueprint review? 14:39:57 and a blueprint is approved only when one or more driver supports the bp 14:40:01 yes markwash 14:40:44 iccha: can you tell me when they discuss that? and where? 14:41:03 also the importance of the blueprint is decided by how many core members has volunteered to be revieweing that feature 14:41:04 ML or irc weekly-meeting 14:41:05 it seemed like they also have some specific rules about what must be provided and guidelines for how blueprints transition through their state-flow 14:41:37 http://lists.openstack.org/pipermail/openstack-dev/2013-October/017290.html 14:42:10 some of these discussions happened at the summit i believe 14:42:36 zhiyan: the wiki page on blueprints has the nova process too 14:43:19 iccha: indeed, thanks. 14:43:36 https://wiki.openstack.org/wiki/Blueprints 14:44:10 I guess what I'd really love to do with this is to use it to guide an automated review process as well as using the underlying rules to power a dashboard 14:44:15 so if we feel we could pick parts of process or customize it for us 14:44:22 markwash: +1 14:44:33 even if its just for me, that would be a huge help, but I also like the idea of figuring out if we need something like a drivers team 14:44:40 its possible core == drivers for us 14:45:19 or maybe we can have another group of drivers, and have people who can review blueprints be cores + drivers 14:45:27 i would like the possibility of non core members also to have a change to be part of drivers 14:45:32 yeah 14:45:46 and also perhaps there are some cores that don't want to mess with bp review 14:45:50 if they are going to consistent and have valuable input from glance as a paroduct side 14:46:35 so the action item I really want to take from this is for someone to start playing around with automating this workflow, but I'm not sure we're ready exactly 14:46:48 maybe the right action item is an ML proposal for exactly what our workflow would be? 14:47:03 markwash: yes, we need a workflow before we try to automate it! 14:47:06 novas + whatever tweaks I guess 14:47:52 okay, I'll take that on, bp triaging is something I really want us to step up 14:48:03 maybe like theirs but a little lighter weight :) 14:48:06 also, +1 to the non-core BP driver idea 14:48:11 rosmaita: ;-) 14:48:15 :) 14:48:44 #action markwash propose bp workflow to ML after more careful review of nova's