14:00:01 #startmeeting Glance 14:00:02 Meeting started Thu Jun 11 14:00:01 2015 UTC and is due to finish in 60 minutes. The chair is nikhil_k. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:05 The meeting name has been set to 'glance' 14:00:09 #link https://etherpad.openstack.org/p/glance-team-meeting-agenda 14:00:15 o/ 14:00:17 o/ 14:00:18 o/ 14:00:45 Welcome all! 14:01:01 o/ 14:01:13 We have a short agenda today ; and looks like a decent turnout for it. So thanks! 14:01:22 Let's get started 14:01:35 #topic Updates 14:02:04 o/ 14:02:22 o/ 14:02:32 o/ 14:02:53 #info Glance mid-cycle to be very likely co-located with Horizon and SearchLight mid-cycle on the week of July 21 for 2-3 days. Venue to be annouced soon. #link https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=0 14:03:34 The date was finalized so that people can start talking to their management for getting the travel approved. 14:04:01 why was the other week cancelled ? 14:04:04 Approval usually depends on budget, and budget depends on location :) 14:04:43 We tried to keep it earlier in the cycle however, the attempt to co-locate with Nova failed and then scheduling complications delayed the decision a lot more. After having more than an hour long chat with Horizon and SearchLight PTLs yesterday we were able to come up with a date. 14:05:23 o/ 14:05:24 that's unfortunate, I won't be able to attend 14:05:48 I had made a full attempt to keep it on July 8 until last week however, the pre-conversation and then conversation with Nova team delayed things a bit 14:06:09 Sorry for being so bold but, in this specific case, what would be the benefit of co-locating with Horizon and searchlight ? 14:06:14 well, I see the point about searchlight 14:06:18 is it the venue? 14:06:46 Also, keeping it later was seen as a failure to keep it mid-cycle and would reduce the value of the meetip a lot more 14:07:09 'Mid' cycle * 14:07:10 mid-cycle sessions started as an experimental thing, but it looks like they are becoming almost mandatory ... maybe we should get th openstack foundation to start handling scheduling and stuff 14:07:26 rosmaita: ++ 14:07:30 they could take into account "rival" conference conflicts 14:07:31 rosmaita: We had some converstion last cycle about this 14:07:52 the feedback was that these should not be conveyed as mandatory 14:08:09 right but the discussions in the mid-cycle are very important 14:08:15 flaper87: +1 14:08:25 the topics we discuss there are *mandatory* for our release and priorities 14:08:33 for various reasons -- like different team want to keep them at isolated venues, keep a different style andwant to get different things out of it 14:08:34 flaper87: +1 14:08:37 and it's a real bummer and pain to not be able to attend to the mid-cycle 14:08:59 since many times, for those not there, these comes down to "I've no freaking idea of what happened there" 14:09:11 i think if the foundation could take on scheduling, it would reduce the burden on PTLs trying to set thinkgs up 14:09:16 unless you stay up 'til 2am to attend through phone calls 14:09:19 they could still be "optional" 14:09:27 (sorry, I don't mean to take it on anyone) 14:09:29 flaper87: how about we bring this up in next weeks TC meeting? I actually would love to have a formal process for such important event but it was pushed back hard the last time 14:09:37 but the foundation could find locations, etc, rotate where they are held, etc 14:10:05 I just don't see the conflict between Foundation scheduled and non-mandatory 14:10:08 the foundation should have administrative assistant support that projects don't 14:10:17 jokke_: +1 14:10:17 nikhil_k: I'll bring this up but this'll likely come down to "it's not mandatory and the foundation can't do anything about it" 14:10:29 it's really hard for companies to afford mid-cycles+summits 14:10:44 and for people to travel to all those things and still be able to take care of their families 14:10:49 so, it's a problem 14:10:56 flaper87: then maybe propose changing to a 3 month release cycle 14:11:02 The point is when foundation handle it project preferences become secondary. The hard part is being able to co-locate 14:11:15 as soon as the foundation weights in in any way, it'll change the meaning of the mid-cycle entirely (which already happened implicitly) 14:11:35 rosmaita: well, nothing forbids us to do it 14:11:42 ironic just did it :D 14:11:42 3 month cycles would have a ton of overhead for release mgmt 14:12:00 it'll be really hard to sync with other projects that depend on Glance 14:12:02 we would be in freeze a lot more 14:12:07 nikhil_k: i know, so supporting a mid-cycle meeting is much cheaper in comparison 14:12:15 flaper87: but does it in the bad way ... I'd assume if it's Foundation "supported" event it's easier for manager to justify the travel & time for it 14:12:17 not financially though ;) 14:12:30 sigmavirus24: ++ 14:12:45 also this is a bit orthogonal to the discussion 14:12:51 sigmavirus24: LOL 14:12:53 you're right 14:12:57 (whether the foundation handles midcycle planning or not) 14:12:59 so we all agree that the midcycle meetings are good 14:13:03 (that's a TC decision ;)) 14:13:06 rosmaita: I didn't say that =P 14:13:07 do we move htem to video only? 14:13:20 May be we need to decide on the location before the summit like Nova tried to do in Kilo-Liberty 14:13:23 anyway, my point is that I'd like us to prioritize more on our team rather than co-location (unless I'm missing something, venue?) 14:13:34 i'm assuming the reason flaper87 is bummed about hte scheduling is that he wants to attend, so must be good 14:13:38 flaper87: ++ 14:13:56 rosmaita: yeah, mostly. And this is the third time this happens to me 14:13:57 :D 14:14:04 if we do video only, then co-location is not a problem 14:14:11 and you're all cool kids that I want to hangout with 14:14:13 we just dont schedule at exactly the same time 14:14:18 flaper87: :) 14:14:55 anyway, I'd assume it's already too late to make changes this time 14:14:58 and with video only, we can be more flexible about scheduling 14:15:04 the pre-liberty mini-summit did not have much participation in vidyo or was very difficult rather 14:15:04 but lets keep it in mind for the next time 14:15:05 video has it's own focus problems, but I'm ok for that. Let's just do it for change for example UTC+3 ;) 14:15:10 glance-team>co-location 14:15:22 nikhil_k: and it was >=midnight here 14:15:32 jokke_ :)) nice idea 14:15:56 why don't we do vidyo bi-weekly? 14:16:11 nikhil_k: if there's a good agenda, I'd be ok 14:16:21 I can definitely come up with one 14:16:35 "I can always come up with work for my minions" -- nikhil_k probably 14:16:36 ;) 14:16:45 lol 14:16:53 awesome, I think alternate participation is also acceptable so that'd be ok 14:16:59 Ok, I will come up with a plan and propose it on ML with hopes of not getting push back that we are not using irc as primary means of communication 14:17:28 if it is open to everyone, I don't see the problem 14:17:35 also, we can take minutes 14:17:40 actually, we should take minutes 14:17:45 yeah, I feel that we need cross-sub-team and cross-timezone participation every so often 14:17:47 (if it isn't logged, it ain't true) 14:18:03 we could log minutes in irc during the mtg 14:18:16 rosmaita: ++ 14:18:22 flaper87: would you want to be a scheduling liaison if not burnt out? or may be rosmaita ? 14:18:23 do vidyo & irc at the same time 14:18:36 co-liaison :) 14:19:05 nikhil_k: sure 14:19:13 if we have <10 participants then we can record/hangout on air and publish it thus keeping up with openness principle 14:19:36 as long as jokke_ doesn't mind being recorded ;) 14:19:43 * flaper87 goes to get vidyo working on his laptop 14:19:43 (which google probably does anyway =P 14:19:51 ) 14:20:07 * flaper87 just saved sigmavirus24 from a SyntaxError 14:20:12 can I get a quick vote here to see the possiblity of delaying the mini-summit by a week? 14:20:15 i think we can record vidyo also with >10 participants? 14:20:25 meeting is one thing, but the problem is that I just can't do it in the office ... so I'll be at best on irc on those 14:20:26 I actually had created another column for it 14:20:37 thanks flaper87. you're my hero 14:20:51 and I don't think I'm the only one with that problem 14:20:53 sigmavirus24: lol, yeah 14:21:26 jokke_: get a better firewall 14:21:29 problem solved :P 14:21:42 #startvote Would you prefer mid-cycle to be from Jul 28-30 vs Jul 21-23 ? 14:21:43 Begin voting on: Would you prefer mid-cycle to be from Jul 28-30 vs Jul 21-23 ? Valid vote options are Yes, No. 14:21:44 Vote using '#vote OPTION'. Only your last vote counts. 14:21:52 #vote Yes 14:22:05 #vote Yes 14:22:06 #vote Yes 14:22:13 #vote probably neither works 14:22:25 There are no gurantees and I will try my best 14:22:36 #vote meh 14:22:41 no opinion from my side 14:22:41 #vote Yes 14:23:12 Ok, let me make the column a bit more official 14:23:15 nikhil_k: when do you think you'll be able to have an answer about this? 14:23:22 no preassure but the sooner the better 14:23:46 (I got another meeting/trip to arrange around those dates and I'd like to prioritize) 14:23:53 #endvote 14:23:54 Voted on "Would you prefer mid-cycle to be from Jul 28-30 vs Jul 21-23 ?" Results are 14:23:59 flaper87: I think next week 14:24:06 nikhil_k: Do you mean 28-30 or 29 - 31? The latter is Wed-Fri. 14:24:28 flaper87: I will keep you or rosmaita in sync and ping if anyone if online when that conversation happens 14:24:36 heh 14:24:45 Since we say many yes for that vote, please 14:24:52 nikhil_k: awesome, thanks! 14:24:54 #action add your preference about the date on https://docs.google.com/spreadsheets/d/1w0eI6SPCA2IrOyHiEYC2uDO3fbYGzahZRUQSva0UD3Y/edit#gid=0 14:25:24 sigmavirus24: This scheduling stuff is very tricky ;-) 14:25:59 sabari: I meant 28-30 as it helps avoid flying on weekend and is preferred by many a folks 14:26:03 Yeah I just have little faith that I won't be scheduled into a sprint during the midcycle and told I can't have the time to go to it 14:26:25 s/say/saw/g 14:26:50 nikhil_k: are you going to try co-locating it ? 14:27:05 because if not, then I'd say we should reconsider 8-10 :P 14:27:08 nikhil_k: hmm, ok 14:27:15 * flaper87 confuses nikhil_k even more 14:28:05 flaper87: Actually co-locating helps from many other reasons. Lesser travel for overlaps for those who work on more than one project, easier to get budget, interest from other companies who are just joining the project, opportunity of companies to host many project etc 14:28:17 s/from/for/g 14:28:42 nikhil_k: fair enough. 14:29:18 flaper87: 8-10 would be very hard to get budget approved you see and we may end up being less than a donez hanging out in a game room or something 14:29:49 nikhil_k: game room sounds good 14:29:50 :P 14:29:52 (joking) 14:30:02 nikhil_k: I don't see anything wrong with that ;P 14:30:32 Blacksburg it is then for the venue :P 14:30:35 jk :-) 14:30:46 we can go bowling 14:30:58 we've a nice game room with guitar hero 14:31:10 lol 14:31:23 is that place in minnesota still an option? 14:31:28 I know sigmavirus24 is thinking about coming to Bburg now, even more than before :P 14:31:42 I swear, I hear wonderful things about that place 14:31:44 And I want to see it 14:31:54 sigmavirus24: no, Nova said strict no unless there was some discussion on ML about horizon wanting to co-locate with them 14:32:02 Ah okay 14:32:08 Guess I'm off to join the Nova team then =P 14:32:12 :) 14:32:40 Hope that resolves concerns.. 14:33:00 Moving to next one.. 14:33:15 #topic Cross project awareness 14:33:18 #link https://review.openstack.org/#/c/186635/ 14:33:58 Please provide input on the same. If we go with direct pins, there would be more pressure on the glance (project) developers to write stuff according to the requirements. 14:34:34 That may create more hacks and add project side maintenance load 14:35:07 vs. not going that route means more work on packaging side and harder to converge 14:35:25 that does involve fixing bug(ish) code in the project 14:35:51 hm 14:35:51 That's it from my end.. 14:36:23 So as I understood that spec, this was only for testing. The official requirements will still be ranges. This is too smooth over testing 14:36:54 Which is not to say your points aren't valid. I actually agree with them, to be honest. 14:37:34 sigmavirus24: yes, that's the way I read it as well 14:37:38 and yes, nikhil_k are valid 14:38:09 On the one hand, if we get stuck with super old dependencies that are in those ranges, then yes we'll have to do a lot of stuff to smooth over differences in libraries 14:38:18 Agreed, just for testing. Though, I kinda agree with Doug that it makes projects looks second class citizen however, with a lesser intensity and intent to push back 14:39:20 One thing that would have made me think a lot more if it was project wise was security impact of libraries and harder upgrades 14:39:53 with testing that can be quarantined in other ways 14:40:09 unless there are deployments that don't agree with such approch 14:41:25 Ok, we can hope to get more feedback on the review 14:41:28 Yeah 14:41:29 Moving on.. 14:41:33 I'll try to give some feedback tonight 14:41:36 Thanks! 14:41:54 #topic Refactor: HTTP Store onto requests 14:42:02 #link https://review.openstack.org/#/c/189537/4 14:42:06 sigmavirus24: all yours 14:42:29 the title sounds amazing already 14:42:32 oh right 14:42:36 I forgot that was on the agenda 14:42:46 :) 14:42:48 tl;dr I started refactoring this before the summit but failed to write a spec until the other night 14:43:07 I need to update it some, but the updates are mainly around the threat model which I'm using as reasoning for the refactor 14:43:22 That said, I'm talking about adding 2 new config options which I want everyone's input on 14:43:44 And if anyone can think of other config problems we might run into using something that isn't as lazy as httplib, they should provide feedback 14:43:51 There's a patch up without the config options 14:44:04 https://review.openstack.org/#/c/168507/ 14:44:21 I can rebase it sometime this week and y'all can test it out if you're using an HTTP store and give feedback 14:44:35 It should be functionally equivalent (except that it breaks if there's a verification error) 14:44:36 hmm, we may have a use isecure conn kinda flag in glance 14:44:47 nikhil_k: that's one of the config options 14:44:59 I'd rather glance not pass insecure=False all the time, that defeats the purpose of the refactor 14:45:04 sigmavirus24: I'm good with this spec, FWIW 14:45:19 sigmavirus24: and sorry I haven't reviewed the spec yet :) thought I reviewed your code long back :) 14:45:23 sigmavirus24: yeah, +1 on glance not passing 14:45:24 though* 14:45:26 I'll also be writing a spec to make the checksum configurable 14:45:35 ooh 14:45:35 sabari: yes you did. Your reviews were excellent 14:45:41 nikhil_k: yeah 14:45:46 I'm that guy this cycle 14:45:48 that's a tricky one 14:45:58 ok 14:46:01 :D 14:46:05 tricky siggy 14:46:29 rosmaita: you know any api/filtering constraints for configurable checksum? 14:46:33 sigmavirus24: I think that insecurity needs to be the default 'though 14:46:43 and may be brianna has more input there 14:47:24 sigmavirus24: should the spec also cover VMware driver since you started that refactor too ? https://review.openstack.org/#/c/168540/3 14:48:21 nikhil_k: not aware of any, except the schema says 32 maxlength string, description says md5 hash 14:48:40 sabari: I'm thinking of writing a separate spec for that 14:48:42 but we could 14:48:45 rosmaita: right 14:48:51 yeah, we would need to document/educate if that becomes consifugrable! 14:49:06 jokke_: please comment on the review 14:49:22 rosmaita: but if not api constraints, then I guess it shouldn't take us more than one cycle.. 14:49:28 sigmavirus24: hmm, thanks. 14:49:29 the database does validate the length of the checksum and inessa was adding validation to the API about it 14:50:08 The reason we need to make the checksum configurable is so people stop -1'ing bpoulos' spec 14:50:25 And they're right that this needs to be done, but wrong about the order of operations relative to bpoulos' spec 14:50:40 Anyway, that's all I have 14:50:41 =P 14:50:42 umm 14:51:10 #topic Open Discussion 14:51:18 we can continue or discuss something else.. 14:51:42 I was gunna ask if we should officially register a Drivers' meeting? 14:52:10 so that feedback can be synchronously and async-ly possible 14:52:27 Attendance would not be mandatory 14:52:39 but would be good/great for awareness 14:52:45 o/ 14:52:46 I would attend 14:52:57 30 mins? 14:53:04 45 or 60, or more? 14:53:10 I'd like to bring this spec to your attention: https://review.openstack.org/#/c/188388/ 14:53:16 should probably take it to the ML to decide. I think we're missing drivers from this meeting 14:53:19 14:53:31 I need to update it with latests discussions I had with sabari but early comments are appreciated 14:53:56 I would say between 30 and 45 minutes would be sufficient 14:54:20 maybe start with 30 and see if we need more? 14:55:09 nikhil_k: only v2 api constraint on checksum is that you can use it to filter an image list 14:55:16 ok, I will send email to ML and get more feedback. As this would be a place for open feedback and track progress and do prioritization outside of sprints like mid-cycle 14:55:42 rosmaita: awesome, thanks! 14:56:20 We can decide on dates/time there 14:56:36 weekly would be nice but may be bi-weekly if needed 14:56:46 (or not needed) 14:58:43 Do we need more active cores? We do need a policy and cleanup of the core-list soon-ish possibly before mid-cycle. May be we can chat about it next weekly mtg.. 14:59:20 If nothing else .. 14:59:27 Thanks all! 14:59:45 ending 33 sec early 14:59:47 #endmeeting