14:10:36 #startmeeting Glance Drivers 14:10:36 Meeting started Tue Dec 22 14:10:36 2015 UTC and is due to finish in 60 minutes. The chair is flaper87. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:10:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:10:39 Courtesy Glance Drivers' meeting reminder: nikhil_k, flaper87, sigmavirus24, rosmaita, mclaren, dhellmann, jokke_,kragniz 14:10:40 The meeting name has been set to 'glance_drivers' 14:10:48 o/ 14:10:49 sorry folks, I thought we weren't having this meeting today 14:10:56 o/ 14:10:56 we can skip it if you're busy w/ other things 14:11:14 o/ 14:11:16 o/ 14:11:30 ok, lets do this 14:11:34 I'm sorry again 14:12:03 #topic OVF/OVA in mitaka 14:12:06 #link http://lists.openstack.org/pipermail/openstack-dev/2015-December/082711.html 14:12:14 did you have time to read that email? 14:12:32 not me 14:12:38 malini replied to it but I'd love to get your feedback on it 14:12:48 rosmaita: it's short, we can wait for you 14:12:55 rosmaita: as in, feel free to read it now 14:13:08 done 14:13:50 oops, I read only first and did not realize malini replied 14:13:50 My thoughts are that the work on the task is not going to impact the API design. TBH, it's kinda useless for the cloud user as we'll be making the task API admin only, which means that the OVF task won't be triggered unless we finish the image import process 14:14:13 but again, the code is isolated enough and the engine, as far as we've discussed, won't change 14:15:01 I agree on both points 14:15:17 coolio 14:15:21 the one thing that was of worry was the concept of standard way to upload OVAs 14:15:26 the way i see this working is that a deployer would put 'ova' as one of the accepted formats for import, and then the task engine would handle the rest 14:15:36 Now, the new spec that they want to make the OVF one depend on is a whole different thing and I need to read it 14:15:45 rosmaita: right 14:16:07 is there a new spec? or a new PS? confirming 14:16:15 so, to be clear, the one I'm advocating for is: https://review.openstack.org/#/c/194868/ 14:16:28 but then they created a new one for CIM 14:16:38 and they'd like to store metadata using that format 14:16:52 gerrit is really slow ATM 14:17:01 I haven't read it in detail but I'd say we're too close to the spec freeze to even consider it 14:17:06 but again, I need to read it 14:17:08 rosmaita: same here :( 14:17:09 i keep getting 502s 14:17:11 ok 14:17:32 me too, I asked in infra 14:17:40 dhellmann: danke 14:17:42 flaper87: there is prob enough to do on the other spec 14:17:54 exactly my thoughts 14:18:15 flaper87: they could always add code to handle the gzip decompression bomb and tarball escalation of privileges problems 14:18:15 hmm, I get 502 on one FF window and not on other 14:18:26 awesome... So, let's give that one a review and comment on it. Malini mentioned she'll be on top of it and make sure comments are addressed 14:18:50 I'd like to avoid spec freeze exceptions except for the image import one, if possible 14:18:56 but I understand christmass is 2 days away 14:19:19 so, lets do our best to provide feedback before christmas and then deal with the exception if needed 14:19:39 last I remember (from my read of the OVF spec last week) is that it's pretty close to be ok for a first implementation 14:20:02 anyway, I'd love to use the last 10 mins for updates on the image import spec if there's nothing else to add on this topic 14:20:22 do you happen to have the gerrit link for the "new" ova spec? 14:20:48 yes, 2s 14:20:54 ty 14:21:12 #link https://review.openstack.org/259694 CIM metadata definition 14:21:26 #link https://review.openstack.org/194868 OVA/OVF import 14:21:32 image import update: i've been away 14:21:36 the last one is the one we've reviewed already 14:21:41 will be working on that all day today 14:21:57 sounds good. Anything blocking you? Any questions? 14:22:06 nothing but time 14:22:07 I've replied to every comment from mclaren 14:22:14 i saw that, thankd 14:22:18 thanks 14:22:22 I hope I've been clear and I'd love to hear other opinions on that. 14:22:46 I've a quite strong opinion against his proposal not from a technical point of view but an API/UX point of view 14:23:01 and time, and reviews, adn $ADD_YOUR_FAVOURITE_BLOCKING_THING_HERE 14:23:03 i am going to work out some detailed examples on the wiki or etherpad just to make sure the workflow is good 14:23:37 rosmaita: ok, I'll be pinging other folks for reviews to get opinions from outside ( dhellmann, mordred, API-GW) 14:23:48 but I'd like to close this topic (bikeshed) asap 14:23:55 i'll put out a message on the ML as soon as the update is done 14:23:56 not really asap but just close it 14:24:09 yes, it would be nice to get this settled 14:24:18 we've been talking about it quite a bit and I'm mentally ready to make a call if we don't manage to convince mclaren 14:24:20 :D 14:24:26 i put one more thing on the agenda 14:24:32 shoot 14:24:37 i am about to -1 niall's property protections spec 14:24:50 when gerrit comes back 14:24:55 I've been meaning to review that one. Looking forward to your comments 14:25:00 anything you'd like to share now? 14:25:00 i have a concern about the compute api 14:25:03 yeah 14:26:12 so, the proposal is that nova will pass a service token to glance when it creates a snapshot, and that will allow a deployer to recognize that it's nova, and configure the property protections to allow them to be modified 14:26:19 whereas normally a user couldn't do that 14:26:22 i'm not being clear 14:26:32 nova uses end-user token to create snapshot now 14:26:44 right 14:26:46 so, nova cannot modify properties that only a glance admin cna modify 14:26:58 these aere usually billing-related, we want them on snapshots 14:27:01 anyway ... 14:27:21 the compute API also has calls in it that allow an end-user to modify image metadata 14:27:29 we talked a bit about this back in Tokyo and the idea seemed to be to do this just for snapshots create 14:28:04 right, except that during the snapshot process, nova may need to update a property 14:28:19 maybe it's not a concern 14:28:30 oh mmh, ok. This definitely needs more thinking. We'll need keystone folks to chime in as well 14:28:42 i guess we just need to make sure that the service token is only passed in particular contexts 14:28:55 right, like we're doing with keystone trusts 14:29:00 in the upload path 14:29:21 that's a great concern, I'll read the spec and provide feedback after your comment 14:29:37 ok, i'll get it up there as soon as gerrit is back 14:29:41 ok, we ran out of time. Sorry for cutting you off like this. 14:29:49 np, glad to be cut off! 14:30:05 Again, I'm sorry for assuming we'd skip the metting. I think it'd be safe to say we won't have it next week 14:30:12 +1 14:30:16 So, have a great christmass and I wish you all a happy new year 14:30:30 BTW, I'll -2 all specs next week since it's the spec freeze week 14:30:36 we'll handle exceptions the week after that 14:30:48 sounds good 14:30:58 ok, have fun and misbehave. Behaving is boring 14:31:00 #endmeeting