17:00:41 <tjones> #startmeeting vmwareapi 17:00:46 <arnaud__> hi 17:00:49 <openstack> Meeting started Wed Jul 16 17:00:41 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:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:52 <openstack> The meeting name has been set to 'vmwareapi' 17:01:16 <tjones> hi golks 17:01:21 <tjones> s/golks/folks 17:01:22 <tjones> heh 17:01:27 <mdbooth> Hello 17:01:54 <arnaud__> fyi: gary and dado can't make it 17:02:03 <arnaud__> s/dado/rado 17:02:09 <tjones> ok bummer 17:02:14 <tjones> lets get started then 17:02:32 <tjones> just want to bring to your attention - the schedule 17:02:35 <tjones> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule 17:02:41 <tjones> juno-2 is next week! 17:03:32 <tjones> that came fast!!! 17:03:42 <vuil> o/ 17:03:57 <tjones> #topic BP under review 17:04:14 <tjones> #link https://review.openstack.org/#/q/status:open+project:openstack/nova-specs+message:vmware,n,z 17:04:21 <tjones> so take a look here - there is nothing 17:04:25 <tjones> no open specs 17:05:19 <tjones> here are the merged specs #link https://review.openstack.org/#/q/status:merged+project:openstack/nova-specs+message:vmware,n,z 17:05:34 <tjones> kiran is not here 17:05:37 <tjones> his is missing 17:05:42 <mdbooth> tjones: n00b question: what does 'open' mean in the above context? 17:05:56 <tjones> open means still in review 17:06:04 <tjones> not yet approved 17:06:10 <tjones> merged means approved 17:06:12 <mdbooth> Thanks 17:06:16 <mdbooth> Ok 17:06:28 <tjones> yeah so i am wondering what happened to the specs we had last week in review 17:06:53 <mdbooth> johnthetubaguy was doing some spec cleanup 17:07:01 <mdbooth> Did he kill them? 17:07:06 <tjones> https://review.openstack.org/#/c/98704/ 17:07:07 <arnaud__> -2 them 17:07:08 <tjones> yep 17:07:15 <johnthetubaguy> I suspect I did, sorry, its freeze time 17:07:50 <tjones> bummer 17:07:51 <johnthetubaguy> so, in future, it would be awesome to see lots of +1s on your specs that you really think are ready, it will help us identify when a sub-group has blessed something 17:08:15 <johnthetubaguy> now we are compiling the list of things that might want exceptions, but its getting too big already 17:08:24 <tjones> yeah thanks johnthetubaguy. i see that in your comment 17:08:32 <johnthetubaguy> do you have anything that is about driver consistency? 17:08:42 <mdbooth> johnthetubaguy: Like what? 17:09:00 <johnthetubaguy> like adding support for API xyz that doesn't already work 17:09:06 <johnthetubaguy> or something like that 17:09:32 <mdbooth> I don't think so 17:09:45 <tjones> i don't think so either 17:10:22 <mdbooth> While we're on the subject, I (very briefly) discussed the refactor series with johnthetubaguy, this morning I think 17:10:30 <johnthetubaguy> bummer, oh well, feel free to raise one or two you think are super super important, but I can't promise anything 17:10:50 <mdbooth> We've got a huge patch series which is ready for core review 17:11:10 <mdbooth> However, because the phase 3 stuff hasn't landed, yet, we can't mark the BP as needs review 17:11:29 <mdbooth> Which means we're less likely to get attention on the stuff which is already in 17:11:40 <mdbooth> I think we need to land that asap 17:12:00 <vuil> I am working on getting the phase 3 stuff posted in the next day or two. 17:12:17 <mdbooth> vuil: Awesome 17:12:18 <vuil> But honestly the current huge list of patches are ready and orthogonal 17:12:32 <mdbooth> vuil: Phase 3 patches? 17:12:33 <vuil> We should encourage review eyes on them 17:12:38 <tjones> lets talk about aproved BP then 17:12:46 <tjones> #topic approved BP 17:12:51 <tjones> so - the refactor!! 17:13:11 <vuil> mdbooth: I mean the current rather sizeable list of reviews that we should have the cores look at 17:13:43 <mdbooth> #link http://paste.fedoraproject.org/118493/40552732/raw/ 17:13:47 <tjones> wow - it's 15 or so patches now right? 17:13:49 <mdbooth> Did I do that right? 17:14:06 <vuil> I was referring to the refactor-related chain of patches 17:14:23 <mdbooth> vuil: Cool. I'm surprised they're orthogonal, though. 17:14:44 <mdbooth> I can't imagine it's possible to touch that code without conflicting with something in the existing series. 17:14:55 <vuil> for review purposes, I mean. It's not like the current dozen or so patches cannot be reviewed and merged 17:15:25 <mdbooth> Yes, they can 17:15:36 <tjones> mdbooth: can you paste the link to the dependent patches list like you did that time? 17:15:37 <vuil> The phase 3 code mainly refactors the second part of spawn that the current series mostly does not touch. 17:15:42 <tjones> the list has grown 17:15:44 <mdbooth> tjones: ^^^ 17:15:53 <tjones> that is all of our ourstanding patches 17:16:00 <tjones> not just spawn 17:16:06 <tjones> refactor 17:16:14 <mdbooth> tjones: If you make it wide enough you can see the refactor series in the middle of it 17:16:41 <tjones> ok i see it 17:16:43 <mdbooth> Incidentally, I've now ported the dep feature to qgerrit 17:16:47 <tjones> wow 17:17:07 <mdbooth> The above was generated by my qgerrit fork 17:17:24 <vuil> 106794 to 104148 17:17:24 <mdbooth> So I could probably improve it by removing some fields :) 17:18:03 <tjones> this is great 17:18:21 <tjones> anyway —— do you guys think we can get this done by juno-2 (7/24)? 17:18:56 <vuil> It's not unreasonable to ask that the cores look at those right? They have had various stages of +1/+2 already 17:19:10 <tjones> yes that seems very reasonable 17:20:07 <mdbooth> vuil: Right. If we genuinely think the whole BP is landed, though, we can mark it as needs review 17:20:15 <mdbooth> Which apparently puts it in a priority queue 17:21:08 <tjones> vuil: mdbooth: do you have anything ele to do or is it done? 17:21:23 <mdbooth> tjones: Nothing on refactor, no. 17:21:45 <tjones> lets mark it as need review then! 17:21:51 <vuil> The last patch in my list https://review.openstack.org/#/c/98322/, is being rebased and broken up right now. 17:22:05 <mdbooth> Here's output with fewer fields, btw: http://paste.fedoraproject.org/118519/40553124/raw/ 17:22:09 <mdbooth> Slightly easier to read 17:22:16 <vuil> I do think it is not a stretch to mark this as needs review. 17:22:25 <tjones> ok so vuil when you have pushed it, lets mark the BP as need review 17:22:30 <vuil> It will take time for the cores to wade through even the initial list 17:22:42 <tjones> https://blueprints.launchpad.net/openstack?searchtext=vmware 17:23:38 <tjones> we are not going to have much time to get vsan, spbm, etc in after refactor 17:24:08 <mdbooth> spbm has a dep on oslo.vmware 17:24:23 <mdbooth> I think we need to push oslo.vmware hard 17:24:54 <mdbooth> If we don't, it won't make juno-3 17:25:05 <tjones> that BP is already marked as need review. it's quite large. i see dims and gary have already +1 17:25:22 <tjones> it could use a few more from this team before we start asking the cores to look 17:25:27 <mdbooth> I think I've reviewed it at least once 17:25:34 <mdbooth> Although I haven't looked in detail recently 17:26:01 <tjones> so for the next week - the prio is spawn refactor reviews and oslo.vmware reviews 17:26:07 <tjones> #link https://review.openstack.org/#/c/70175/ 17:27:10 <vuil> 70175 is large by necessity, but changes are quite mechanical 17:27:24 <tjones> oslo.vmware maybe higher prio as it's already marked in review - so it really has a chance of making j-2 17:27:39 <tjones> anything else on BP for juno? 17:28:40 <arnaud__> on the glance side (which might be relevant for vmware stuff at some point): I am asking an exception for this one https://review.openstack.org/#/c/84887/ 17:29:56 <tjones> will there be significant changes in nova if you get it approved? 17:30:05 <johnthetubaguy> mdbooth: hey, I got distracted, but about those refactor patches, if you people can review them all and get it to where you are all happy, and add lots of +1s, it makes life easier for the core reviewers that come along afterwards, and should make it easer to get merged 17:30:36 <mdbooth> johnthetubaguy: We're there :) 17:30:55 <mdbooth> It's good to go 17:31:13 <arnaud__> tjones: I can bring up the patches, they are already pretty much written since icehouse 17:31:19 <arnaud__> or maybe havana 17:31:38 <tjones> arnaud__: lol. 17:31:42 <arnaud__> it's not too big 17:31:55 <arnaud__> fairly mechanical I would say 17:32:15 <tjones> have you rebased on top of the refactor work ?? 17:32:38 <arnaud__> I am not the author of the patches 17:32:42 <arnaud__> just the spec 17:32:42 <arnaud__> :) 17:32:47 <tjones> ah ok 17:32:57 <arnaud__> I doesn't impact vmware driver 17:33:20 <tjones> ok no worries then ;-) 17:33:25 <tjones> anything else on BP 17:33:26 <tjones> ? 17:34:51 <tjones> #topic bugs 17:35:26 <tjones> im doing a quick triage 17:35:32 <tjones> this one looks interesting 17:35:35 <tjones> #link https://bugs.launchpad.net/nova/+bug/1337798 17:35:36 <uvirtbot> Launchpad bug 1337798 in nova "VMware: snapshot operation copies a live image" [Undecided,New] 17:35:47 <mdbooth> Ah, yes 17:35:54 * mdbooth had forgotten that one 17:36:08 <mdbooth> vuil: I replied, btw 17:36:21 <mdbooth> I think you may have misread it 17:36:39 <vuil> ah reading now. 17:37:53 <mdbooth> vuil: My suspicion is aroused because we do: 17:37:58 <mdbooth> snapshot = self._create_vm_snapshot(instance, vm_ref) 17:38:14 <mdbooth> And the only other place the snapshot variable is used is when it's deleted 17:38:32 <mdbooth> IIRC there are some apis for streaming a snapshot, and it doesn't look like we're using them 17:38:57 <vuil> yeah, the snapshot changes the vmdk file that is written to, making the original vmdk the read-only (frozen) data 17:39:09 <vuil> we copy that out to glance, 17:39:25 <mdbooth> Ok, so: 17:39:28 <mdbooth> dest_vmdk_file_path = ds_util.build_datastore_path(datastore_name, 17:39:28 <mdbooth> "%s/%s.vmdk" % (self._tmp_folder, random_name)) 17:39:29 <vuil> deleting snapshot undoes the disk chain lengthening, restores file name , etc. 17:39:38 <mdbooth> That's now the snapshot 17:39:55 <mdbooth> ? 17:40:02 <vuil> key is vmdk_file_path_before_snapshot 17:40:21 <vuil> probably bad name, what it is saving is the path that will become the frozen disk after the snapshot 17:40:44 <mdbooth> sourceName=vmdk_file_path_before_snapshot, 17:40:52 <mdbooth> Yeah, that's deeply suspicious :) 17:40:58 <vuil> it also happens to be the path of the disk that we write to again once the snapshot is deleted. 17:41:08 <mdbooth> Is that documented anywhere? 17:41:20 <mdbooth> Also, what happens if you make 2 snapshots? 17:41:26 <mdbooth> They can't both have the original uri 17:41:44 * mdbooth has seen vmdk filenames with lots of zeroes in them 17:42:21 <vuil> only the first one does, the chain build from there. If we take two (which we are careful not to), the path is still valid and points to the first. 17:42:57 <vuil> not the first one 17:43:27 <mdbooth> Anyway, it was non-obvious so I opened that bug to ensure somebody looked 17:43:32 <vuil> anyway, I now get your concern, we can sort this out offline to make sure we didn't miss anything. 17:43:32 <mdbooth> You looked :) 17:43:42 <tjones> so the code works but is confusing? 17:43:52 <tjones> *im confused* 17:43:56 <mdbooth> Might be worth leaving the bug open to track adding a big comment 17:44:03 <tjones> ok lets do that 17:44:20 <tjones> i don't have any other bugs to bring up. anyone else? 17:45:01 * mdbooth doesn't have anything 17:45:15 <tjones> topic #opendiscussion 17:45:45 <tjones> i guess we don't want to ask for exception on any of the missed BP. The only one i am wondering about is kiran's 17:46:20 <tjones> thoughts on that (or any of the others)? 17:46:32 <mdbooth> tjones: Link? 17:47:01 <tjones> https://review.openstack.org/#/c/98704/ 17:48:28 <tjones> https://review.openstack.org/#/q/status:abandoned+project:openstack/nova-specs+message:vmware,n,z 17:48:32 <tjones> here is all of them 17:48:45 <arnaud__> fiy: I sent an email to the ML about oslo.vmware and requirements. If anyone has a pov: http://www.mail-archive.com/openstack-dev%40lists.openstack.org/msg29544.html , that would help 17:49:24 <mdbooth> arnaud__: Reading 17:49:54 <mdbooth> fwiw, I only really read posts with [nova] or [vmware] 17:50:06 * mdbooth can't handle the firehose 17:50:35 <arnaud__> I forgot the vmware tag 17:50:44 <arnaud__> I realized that just after sending 17:50:45 <arnaud__> lol 17:52:40 * mdbooth isn't familiar with project requirements in openstack, unfortunately 17:53:15 <arnaud__> I will ping openstack-qa to see if they are familiar with that 17:53:22 <tjones> arnaud__: did you talk with dhellmann ? 17:53:26 <arnaud__> yep 17:53:41 <arnaud__> he is suggesting to add retrying to requirements of icehouse 17:53:55 <arnaud__> but that would mean repackaging for operators 17:54:12 <tjones> sdague may have an idea 17:54:30 <arnaud__> also, that would not fix the issue on the long run from pov 17:55:29 <arnaud__> anyway, I will let you know if I find a solution 17:56:03 <tjones> ok 5 more minutes - anyone have other stuff? 17:57:25 <mdbooth> My changes to qgerrit just got merged upstream 17:57:38 <mdbooth> So if you pull that you can generate those dep tree views 17:57:41 <tjones> mdbooth: cool! 17:57:47 <tjones> please review oslo.vmware https://review.openstack.org/70175 17:58:06 <tjones> and the other refactor patches starting with https://review.openstack.org/106794 17:58:33 <tjones> #endmeeting