17:00:15 #startmeeting vmwareapi 17:00:16 Meeting started Wed Sep 24 17:00:15 2014 UTC and is due to finish in 60 minutes. The chair is tjones. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:19 The meeting name has been set to 'vmwareapi' 17:00:19 hi folks 17:00:27 hi tjones 17:00:28 hello 17:00:29 who's here today? 17:00:30 o/ 17:00:33 o/ 17:00:35 o/ 17:00:38 o/ 17:00:56 o/ 17:01:03 o/ 17:01:03 cool - so i am on the bus right now. If i drop off you will know why 17:01:39 juno is at rc1 now - so unfortunately the bugs we were hoping to fix will not land 17:01:51 https://etherpad.openstack.org/p/VMware-juno-bugs 17:02:05 it's a bummer - but we just ran out of time 17:02:35 are we going to try for rc2? 17:02:59 that's the question - what on this list is critical enough to try for rc2? thoughts? 17:03:50 not sure 17:04:09 tjones: this one is critical "VMware: prevent race condition with VNC port allocation" 17:04:20 tjones: the requirements update went through via the bot proposed review 17:05:02 rgerganov: that is a secuity issue - isn't it? 17:05:10 tjones: yes, it is 17:05:16 dims: it is abandoned today 17:05:45 unfortunately I missed that when I fixed the initial races for VNC ports 17:07:11 tjones: #3,#4,#5,#6 seem important to me... 17:07:50 for anyone upgrading from prev versions 17:07:56 im back 17:07:57 sorry 17:08:04 bus dropped me off 17:08:12 tjones: do you see the scroll back? 17:08:16 yes 17:08:21 so dims - 1 did land then?? 17:08:27 tjones: y 17:08:35 ok good 17:09:18 3 will be a tough sell since the cores don't even want us to be doing that 17:09:30 oh wait - i misread 17:10:15 actually 3) is aligned with what the cores want 17:10:25 i have not read 6 - why is that an rc2 candidate? 17:11:42 tjones: user facing issue "unable to access the VNC console after a VM was rescued" 17:11:51 reading now 17:11:52 ok yes 17:11:55 no workaround 17:12:02 tjones: ya 17:12:30 some added 9 and 10 - presumably for rc2? 17:12:54 yeah tjones 17:12:59 would be nice 17:13:34 arnaud: higher bar for getting stuff in, #10 smells like a feature no? 17:13:36 i suspect would be nice is a hard sell ;-) 17:13:50 :) 17:13:51 * dims really really wants it, but don't know if we can justify 17:13:59 I don't think so, dims: since this is an API call that currently fails 17:14:06 I don't see that as a feature 17:14:30 arnaud: i'd rework the title a bit :) 17:14:40 I can do that 17:14:41 :) 17:15:04 it's a small change - yet if i were the release manager i would say no at this point. certainly a very good thing to have, since this is clearly broken, but….. 17:15:42 tjones: ack 17:15:55 ok any thing else on juno? 17:16:01 the patch is there: if it can make it, that nice. if not :) as usually in openstack, it will make it later :) 17:16:12 arnaud: true 17:16:32 +1 arnaud 17:17:05 tjones: who do you have to talk to for rc2 blessing? 17:17:13 for those marked as such 17:17:19 im guessing mikal 17:17:49 cool thx 17:17:51 i'll send something to the ML perhaps?? right now the cores are fighing gate fires so it is certainly not time to ask for this 17:18:03 what do you guys think? 17:18:03 * dims agrees 17:18:14 ok lets talk about kilo 17:18:20 https://etherpad.openstack.org/p/VMwareapi-kilo 17:18:30 this is our leftover from juno 17:18:44 dims you are fast! 17:18:55 i know tflower wanted to talk about ova 17:18:56 lol 17:19:19 tjones, yes I did - can we talk about that now? 17:19:25 sure go ahead 17:20:11 tflower: you had questions?? 17:20:16 Thanks - We're really interested in this feature as I'm looking to deploy ova images - Will this feature be a first step to enabling ova images with multiple disks? (multiple vmdks?) 17:20:29 sorry, I'm not fast like dims :) 17:20:55 heh 17:21:12 tflower, the implementation that we proposed only uses the root disk in the ova 17:21:12 I had actually looked at the blueprint a while back, and thought it mentioned multiple disks at the time (but just mentioned there were "discussions")...if memory serves 17:21:25 but this can definitely be extended to use more than 1 17:21:57 https://review.openstack.org/#/c/82715/1 17:21:58 i suspect we should push this and propose a depenent BP which extends this - thoughts?? 17:22:11 by *this* i mean the ova BP already in flight 17:22:30 tjones: sounds great 17:22:42 sounds really good to me 17:22:52 tflower: are you interested in proposing the new BP for this? 17:22:59 Sure! 17:23:17 * dims hoping arnaud can help tflower :) 17:23:33 yes sure no problem 17:23:38 thanks! 17:23:42 thanks arnaud 17:23:44 arnaud: thanks 17:23:52 I actually have another question - when it comes to the ova deploy, since an image is just 1 file in glance, will the ova need to be copied to nova-compute and untarred each time? 17:24:16 in the short term yes flower 17:24:25 but 17:24:28 currently 17:24:43 by taking only the root disk, we can optimize and download only the root disk 17:24:54 this is not part of the part mentioned above 17:25:00 but fairly easy to do 17:25:14 the files in the ova 17:25:17 are ordered 17:25:22 I see - for linked clones for example you can assume if the file is there, it's the root disk and not the ova? 17:25:35 ..file is there in the datastore I mean 17:26:06 I guess so yeah 17:26:13 what happens if the ova contains multiple VMs? 17:26:18 is there a "primary" vm? 17:26:57 you mean a vapp rgerganov ? 17:27:03 yes 17:27:23 we should take the first one 17:27:30 not sure if Vui tested that 17:27:33 ok :) 17:27:37 I will check with him 17:27:38 rgerganov: guess we have to expand slowly...first tackle one ova with one vm and multiple disks first 17:27:55 +1 dims 17:28:10 that was the approach taken by supporting only the root disk initially 17:28:20 then expand to more than one 17:28:21 nice 17:28:26 yes 17:28:30 the spec in the BP mentinos the ovf isn't really read yet, at least in the short term 17:29:07 actually afaik, in the patch, we read the ovf first 17:29:15 to know where is the root disk 17:29:16 ah, cool 17:29:58 Just to continue on the untarring thing - not sure how to get around this, would that be considered yet another blueprint? 17:30:29 I would say yes but I would hope no :) 17:31:23 Does that mean the ova implementation may have some solution for this? 17:31:45 I think we can come with 2 patches 17:32:04 that would be fantastic 17:32:08 the first 1: supporting the root disk, and a dependency to support more than 1 17:32:58 arnaud: is there some way I can help out? 17:33:21 you can take the patch I mentioned above and try to add the support for multiple disks 17:33:26 that would be great 17:33:43 tflower: need to start with writing the BP in nova-specs and getting it approved 17:34:00 ok great, I will do that 17:34:14 I guess I will do both (BP and start looking at the code too) 17:34:25 cool, thanks tflower 17:34:34 I will rebase the first patch 17:34:37 by the end of the week 17:34:49 thanks arnaud 17:34:58 thanks everyone for taking time in your meeting for me 17:35:35 :) 17:35:49 ok anything else people are thinking about for kilo? or anything else for that matter? 17:37:01 *listening* 17:37:14 tjones: we'll have some time carved out in the summit? 17:37:41 for kilo discussions? 17:37:42 yes we will - the usual roadmap 20 minutes (i think) 17:37:57 but we should meet and talk more before that 17:38:14 +1 17:38:23 +1 17:38:34 tjones: will try to generate some lists 17:39:07 dims: can you add to the etherpad? 17:39:12 tjones: yep 17:39:31 i still have the link to your list from icehouse - sigh 17:39:49 tjones: :) 17:40:08 ok folks if nothing else - lets end early 17:40:28 going once…. 17:41:02 ok see you next week 17:41:05 #endmeeting