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