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