17:00:22 <tjones> #startmeeting vmwareapi
17:00:25 <openstack> Meeting started Wed Jul 23 17:00:22 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:26 <tjones> hi folks
17:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:29 <openstack> The meeting name has been set to 'vmwareapi'
17:01:05 <arnaud> hi tjones
17:01:44 <tjones> anyone else??
17:01:53 * mdbooth waves
17:02:02 <tjones> *waves back*
17:02:41 <tjones> so j-2 is tomorrow
17:02:45 <tjones> lets talk about reviews
17:02:52 <tjones> #topic reviews for j-2
17:03:00 <tjones> #link https://review.openstack.org/#/q/status:open+project:openstack/nova+message:vmware,n,z
17:03:26 <tjones> so many spawn refactor patches and so little time
17:03:44 <tjones> mdbooth: want to give an update ?  i know vui will be late
17:04:13 <mdbooth> tjones: A bunch got (very painfully) merged over the weekend
17:04:24 <tjones> congrats!
17:04:25 <mdbooth> There's still a long list without any +2s, though
17:04:32 <tjones> yes i see that - ugh
17:04:52 <mdbooth> I will start hassling about that at some point
17:05:31 <tjones> 9 patches for that in reivew
17:05:59 <tjones> + oslo.vmware
17:06:03 <tjones> no +2 yet
17:07:14 <tjones> so chances of those 2 getting in by tomorrow seem prettly slim unfortunately
17:08:07 <tjones> :-(
17:08:08 <mdbooth> tjones: non-existent
17:08:16 <browne> hi
17:08:24 <vuil> I hope we can still get some eyes after tomorrow
17:08:42 <tjones> yeah vuil but we have a TON of other work hoping to land j-3
17:09:20 <mdbooth> vuil: I still haven't noticed the phase 3 patches, btw
17:09:24 <mdbooth> Have I missed them?
17:10:02 <vuil> No, apologies, I have about a chain of 6 patches I need to post. Got interrupted by other things the last 2 days.
17:10:09 <vuil> Will try to get them up today.
17:10:42 <tjones> vuil: can you please mark spawn refactor to "needs code review"?  I cannot -
17:10:49 <tjones> i thought you did that last week
17:10:54 <tjones> do you have the privs?
17:11:13 <vuil> I should, let me do it.
17:11:14 <tjones> #link https://blueprints.launchpad.net/openstack?searchtext=vmware
17:11:27 <tjones> cause without that the cores don't know they should be reviewing like mad
17:11:46 <tjones> any other in that list that should be in code review status?
17:12:26 <vuil> no I can't do it
17:12:29 <vuil> can you tjones?
17:12:35 <tjones> i cannot
17:13:00 <vuil> I think we need to go ping hartsocks later then.
17:13:07 <tjones> johnthetubaguy: can you please mark https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor as "need code review"?  The patches have all been submitted (for a while now)
17:13:24 <hartsocks> vuil: pong
17:13:27 <tjones> ok - any other in that list in the wrong state?
17:13:41 <tjones> hartsocks can you set https://blueprints.launchpad.net/nova/+spec/vmware-spawn-refactor to "needs code review" please?
17:13:55 <hartsocks> tjones: no problem.
17:13:58 <tjones> thanks
17:14:30 <tjones> ok lets move on to BP for j-3
17:15:00 <johnthetubaguy> tjones: yeah, its up to the blueprint owner to update that, I just manually update that, if they haven't done it already when I check every blueprint at the end of a release
17:15:13 <tjones> johnthetubaguy: thanks
17:15:24 <tjones> so here's the link for the abandoned BP
17:15:26 <tjones> #link https://review.openstack.org/#/q/status:abandoned+project:openstack/nova-specs+message:vmware,n,z
17:15:49 <tjones> we need to decide which we want to target for j-3
17:15:53 <johnthetubaguy> tjones: juno-2 is released now, btw
17:16:05 <tjones> johnthetubaguy: thanks - thought it was tomorrow ;-)
17:16:36 <johnthetubaguy> tjones: tomorrow is the deadline, we try cut branches tuesday/wednesday to make sure we meet the deadline
17:16:42 <tjones> ok good to know
17:17:06 <johnthetubaguy> tjones: puntted everything to juno-3 on Monday that didn't have most of their patches approved, etc
17:17:27 <tjones> so BP owners - please ping johnthetubaguy to remove the -2 for the BP you want to target for j-3.  I suspect there are only a small number of them
17:17:54 <tjones> kiran and kanagaraj are not here and they own 2 of them
17:18:19 <tjones> arnaud: what about https://review.openstack.org/84281
17:18:38 <johnthetubaguy> tjones: the only −2s should be for unapproved blueprints
17:18:45 <arnaud> my priority was https://review.openstack.org/#/c/84887/
17:18:53 <tjones> johnthetubaguy: yes that is correct
17:18:54 <arnaud> but I don't think we can find a consensus
17:18:55 <arnaud> tbh
17:19:14 <johnthetubaguy> tjones: do you have exceptions granted for those, if you want them in juno-3?
17:19:37 <tjones> johnthetubaguy: not yet - i am asking people which ones they want to push in.  so far i hear - nothing
17:19:41 <arnaud> btw, I don't have an exception for #84281
17:19:57 <tjones> so nothing makes it easy ;-)
17:20:03 <johnthetubaguy> tjones: so the deadline for exceptions has passed I think, mikal sent info on how to request exceptions to the ML
17:20:12 <tjones> yeah - just making sure.
17:20:29 <tjones> so we drop that for juno and focus on the approved list
17:20:46 <tjones> anything else on BP today?
17:20:47 <johnthetubaguy> at this point, we are going to struggle getting in everything that is already in NeedCodeReview for Juno-3
17:20:56 <johnthetubaguy> as a heads up
17:21:00 * johnthetubaguy runs away again
17:21:50 <tjones> so guys - you heard it.  then it is likely that the only thing we get into juno is spawn refactor and oslo.vmware.  no other approved BP are in code review...
17:22:13 <tjones> :-(
17:22:44 <mdbooth> :(
17:22:56 <johnthetubaguy> tjones: sooner the code is up, the more likely its going to get reviewed in time
17:23:13 <johnthetubaguy> tjones: basically anything in ***-3 is at risk of missing ***
17:23:30 <johnthetubaguy> based on history
17:24:56 <tjones> so on to bugs
17:25:02 <tjones> we've got a bunch too
17:25:20 <tjones> http://tinyurl.com/p28mz43
17:26:51 <tjones> if you go to this dashboard http://54.201.139.117/nova-bugs.html, type vmware in the search string and select no owner you will see the ones that are up for grabs
17:27:03 <tjones> if you are bored (haha) feel free to grab a bug
17:27:32 <browne> bug https://bugs.launchpad.net/nova/+bug/1291741 is mine for which I've been rebasing for 3 months
17:27:33 <uvirtbot> Launchpad bug 1291741 in nova "VMWare: Resize action does not change disk" [High,In progress]
17:28:01 <browne> could use help on approval of its patch https://review.openstack.org/#/c/85804/
17:28:07 <tjones> that's one that customers could hit
17:28:09 * mdbooth bookmarks that page
17:28:18 <tjones> you have 1 +2 already
17:28:58 <tjones> folks please give it a look so browne can ask another core to bless it
17:28:59 <browne> yep, almost merged once too, but there was a conflict at the gate
17:29:25 <mdbooth> browne: It's abandoned
17:29:48 <tjones> it is??  i see review in progress
17:29:51 <browne> mdbooth: ?
17:30:00 <mdbooth> https://review.openstack.org/#/c/82227/
17:30:14 <browne> ah yes, ignore that one, look at the second patch
17:30:16 <tjones> https://review.openstack.org/#/c/85804/
17:30:25 <mdbooth> Ah, got it
17:30:48 <tjones> any other bugs?
17:31:30 <tjones> with that link i gave you you can also select ready for review and see a list of about 15 that are ready for review
17:31:55 <tjones> #open discusssion
17:32:05 <tjones> any one have anything?  if not we can end early
17:32:10 <arnaud> I would like to discuss oslo.vmware
17:32:21 <arnaud> and the structure that we want to have in it
17:32:34 <arnaud> while writing this patch yesterday https://review.openstack.org/#/c/105274/
17:32:46 <arnaud> I felt like we don't have any rules, any structure
17:33:01 <tjones> dims: you here?
17:33:17 <dims> tjones, pong
17:33:17 <arnaud> so I created objects for the objects and utils for the other stuff
17:33:33 * mdbooth has never liked the _utils model
17:33:34 <tjones> dims: talking about oslo.vmware
17:33:34 <arnaud> but, I want to make sure we have an agreement
17:33:42 <arnaud> mdbooth, me too
17:33:50 * mdbooth would prefer to see them as method objects
17:34:05 * dims agrees with mdbooth and arnaud
17:34:10 <arnaud> the problem mdbooth is that most of these method cannot be tied to a specific object
17:34:36 <arnaud> at least not an object that represents an object in the VC world
17:36:03 <mdbooth> arnaud: you mean file_delete(), file_move()?
17:36:05 <mdbooth> etc?
17:36:18 <arnaud> no what I mean
17:36:24 <arnaud> is if you take for example
17:36:26 <arnaud> Datastore
17:37:29 <arnaud> a Datastore (here: http://pubs.vmware.com/vi3/sdk/ReferenceGuide/vim.Datastore.html) has a set of fields etc., the representation that we use for datastore is different. Which is fine (I guess).
17:38:01 <arnaud> the object that we have is the most convenient based on what we need in the openstack world
17:38:21 <arnaud> but, I think for methods, the story becomes a bit more complicated
17:38:58 <arnaud> because most of the methods will "use" several objects at the same time
17:39:14 <arnaud> and I don't think we have to end up with a very complex object structure
17:39:30 <arnaud> as an example :)
17:39:39 <arnaud> these methods: https://review.openstack.org/#/c/105274/3/oslo/vmware/ds_util.py
17:39:52 <arnaud> for example: is_datastore_mount_usable
17:39:58 <arnaud> is not really tied to Datastore
17:40:13 <arnaud> in the VC world it would be more tied to DatastoreHostMount
17:40:23 <tjones> and also get_hosts_with_datastore_mounted
17:40:38 <arnaud> but we are not really using anywhere DatastoreHostMount
17:40:48 <arnaud> so having an object for that is kinda overkill
17:41:09 <arnaud> and if we have an object for DatastoreHostMount why not having an object for MountInfo
17:41:26 <mdbooth> I think you should make a judgement call based on how we're actually using it
17:41:28 <arnaud> and we end up with objects for the full VC inventory
17:41:42 <dims> right, we don't want to do that :)
17:41:47 <arnaud> mdbooth, I agree
17:41:48 <mdbooth> We definitely don't need to model VC in openstack
17:42:07 <arnaud> ok
17:42:16 <mdbooth> So is_datastore_mount_usable could go in the Datastore object
17:42:34 <mdbooth> as could get_hosts_with_datastore_mounted
17:42:42 <arnaud> which is fine to me
17:42:49 <mdbooth> although that might also reasonably live elsewhere
17:42:54 <mdbooth> I haven't looked at the usage
17:43:25 <mdbooth> In general, though, if it's 'Datastore'y it would be nice to find it all in the same place
17:43:26 <arnaud> I think it would be nice to define some rules
17:43:39 <arnaud> in the object creation + object/methods mappings
17:44:14 <mdbooth> Ultimately, api creation is a bit of an art :)
17:45:04 <vuil> +1, a lot does still depend on how we intend to use this information
17:45:49 <vuil> is_datastore_mount_usable looks private, and mountinfo retrieve being part of Datastore extends the latter's scope but not unreasaonably
17:46:00 <arnaud> we already have methods in vim_util
17:46:05 <arnaud> that from my perspective
17:46:13 <arnaud> should not live there
17:46:18 <mdbooth> Oh, yeah. If we can make anything private in the move, we absolutely should.
17:46:26 <mdbooth> Or remove it entirely.
17:46:56 <mdbooth> arnaud: I don't think vim_util should exist :)
17:47:13 <mdbooth> It should be in vim
17:47:26 <arnaud> yep
17:47:29 <arnaud> Agree
17:47:30 <mdbooth> Not this release, though
17:48:29 <mdbooth> We should try to have consistency in naming
17:48:49 <mdbooth> filenames are always filenames
17:48:53 <mdbooth> or they're always paths
17:48:54 <arnaud> ok, so what about a rule: we only have top level objects that maps only top level Managed types (Datastore, VirtualMachine, ..) in VC, and the content of these objects is based on the openstack use cases
17:49:04 <mdbooth> argument ordering should be consistent
17:49:14 <mdbooth> I think we can make fairly solid rules about this stuff
17:49:27 <mdbooth> But where to put things is going to be a judgement call, imho
17:50:05 <arnaud> it would be nice I think if this judgement call is a group decision
17:50:16 <mdbooth> arnaud: Sounds reasonable without having looked at it in detail
17:50:26 <dims> anyone want to write something up in our wiki?
17:50:32 <arnaud> yep dims I will
17:50:38 <dims> thanks arnaud
17:51:02 <mdbooth> We'll battle it out in review :)
17:51:15 <arnaud> **hopefully**
17:51:18 <arnaud> :)
17:51:35 <arnaud> not much battle for vim_util
17:53:00 <arnaud> tjones, we can move to another discussion :)
17:53:43 <tjones> anyone else?
17:54:17 <tjones> i have nothing else
17:54:38 <mdbooth> arosen has been an awesome help to me today getting NSX working
17:54:41 <dims> mdbooth, what was the full command line for generating the report i saw in the paste the other day?
17:54:45 <tjones> yeah i saw that - good news
17:55:05 <mdbooth> dims: Have you got the very latest gerrit_view?
17:55:21 <dims> yea i can grab that
17:55:33 <mdbooth> git://github.com/harlowja/gerrit_view.git
17:55:35 <dims> yep
17:55:53 <tjones> thanks for reminding me - i want to grab that too.  very handy
17:55:56 <tjones> ok i think we are done
17:56:00 <tjones> thanks all
17:56:12 <tjones> #endmeeting