17:04:54 <hartsocks> #startmeeting vmwareapi
17:04:55 <openstack> Meeting started Wed Apr  2 17:04:54 2014 UTC and is due to finish in 60 minutes.  The chair is hartsocks. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:04:56 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:04:59 <openstack> The meeting name has been set to 'vmwareapi'
17:05:02 <hartsocks> who's around?
17:07:14 <vuil> Vui here
17:07:52 <hartsocks> vuil: if it's just us, this will be short.
17:08:35 <hartsocks> syerrapragada: ping
17:08:55 <hartsocks> whoops… sorry thought you were sreeram.
17:09:13 <syerrapragada> hartsocks: yes I am
17:09:20 <syerrapragada> :)
17:09:23 <hartsocks> syerrapragada: oh. okay.
17:09:51 <hartsocks> syerrapragada: mind giving us a Minesweeper update? It's been down for a bit.
17:10:28 <syerrapragada> We are still experiencing neutron timeouts in our cloud
17:10:39 <syerrapragada> Engineering team is working hard to fix them
17:11:10 <syerrapragada> as of now minesweeper is down
17:11:43 <hartsocks> Will we roll back from Havana to Grizzly if we can't fix the issue?
17:12:08 <syerrapragada> Not sure if it is upgrade issue
17:13:08 <hartsocks> okay. Well, I'm sure lots of folks are heads-down on that and adding more hands will just cause confusion.
17:13:42 <hartsocks> If that's not the case I can lend a hand as needed.
17:13:44 <syerrapragada> We will update the status page as soon as we get the updates
17:13:45 <syerrapragada> https://wiki.openstack.org/wiki/NovaVMware/Minesweeper/Status
17:13:57 <hartsocks> cool.
17:14:24 <hartsocks> I'm getting periodic pings from people asking what's up. I've been pointing them at the page.
17:15:18 <hartsocks> Anything else on the Minesweeper we should know/
17:15:19 <hartsocks> ?
17:15:41 <syerrapragada> Nope
17:15:51 <hartsocks> okay.
17:15:54 <vuil> I kinda have been on point on issues nova-related for MS.
17:16:25 <vuil> So far the nova computes are working as expected, I will update the page as well should we see issue there
17:17:01 <hartsocks> okay, syerrapragada we're counting on you!
17:18:06 <syerrapragada> SG
17:18:53 <hartsocks> So, last week I took this time as a "soap box" to make the case that we need to do refactors in the driver or else we're endangering forward progress.
17:19:05 <hartsocks> I promise to avoid doing that ever again.
17:19:31 <hartsocks> This week, we have Juno open for commits… but a new blueprint process.
17:19:39 <hartsocks> #topic blueprints
17:19:46 <vuil> yep.
17:19:52 <vuil> oslo.vmware integration...
17:20:04 <hartsocks> So… I'm babysitting https://review.openstack.org/#/c/84307/ trying to get it approved.
17:20:12 <vuil> I am in the process of drafting one, mostly to cover https://review.openstack.org/#/c/70175/
17:20:17 <hartsocks> vuil: and I wanted to bring up what should go next.
17:20:30 <vuil> I saw john g has suggestion of combining into a bigger bp or something.
17:20:42 <vuil> do I still go ahead then?
17:21:17 <hartsocks> vuil: based on that feedback I think we need to write an over-arching "refactor blueprint"
17:21:20 <vuil> (https://review.openstack.org/#/c/70175/ was kinda hiding behind some vSAN-related patches because it was the first time where we _absolutely_ needed the oslo.vmware lib)
17:21:30 <hartsocks> vuil: then break that down into smaller BP/work items.
17:22:09 <hartsocks> One of the things we need to work out is how we move code between oslo.vmware and Nova …
17:22:19 <hartsocks> … I'm not 100% on how this should go.
17:22:37 <dhellmann> move code between?
17:22:43 <hartsocks> But one of the processes that made sense to me was to work out details in Nova then port them to oslo.vmware
17:22:48 <vuil> the over-arching bp sounds more like high level consolidation of 'here are the actual things we are doing", sounds about right?
17:23:01 <dhellmann> ah, from nova into the lib, ok :-)
17:23:15 <hartsocks> vuil: yeah, that's what I think.
17:23:27 <vuil> moving common code to oslo.vmware  is an ongoing process.
17:23:52 <hartsocks> dhellmann: yeah. More or less. As we define things in Nova that work well and generically then migrate them up to oslo.vmware for later consumption.
17:24:00 <vuil> I think step 1 with the oslo.vmware integration is convert stuff in nova to use the stuff that is _already_ in oslo.vmware
17:25:01 <hartsocks> vuil: like this? https://review.openstack.org/#/c/70175/18/nova/virt/vmwareapi/error_util.py … which is mostly removes
17:25:21 <vuil> the ongoing process part is taking a holistic view and see if there is other code that has cross-project benefits and promote it to oslo.vmware if so.
17:25:40 <vuil> and pretty much all of vmware_images.py
17:25:44 <vuil> api.py
17:25:46 <vuil> etc
17:26:36 <vuil> they have much better test coverage in the oslo equivalent, and it's painful to have to modify similar stuff in >1 place
17:27:22 <hartsocks> This is that common "dual maintenance" problem other libs have to deal with.
17:27:29 <vuil> is this part of the conversion what john g wants described in the overarching bp?
17:27:46 <hartsocks> vuil: yeah, I think it is actually.
17:28:30 <hartsocks> I'm also trying to figure out when the "you should do this in oslo.vmware" statements are spurious or really sharp points. :-)
17:28:38 <vuil> okay, would be good if the 'ongoing process', well, being ongoing (™), can be taken out of the scope of the bp
17:29:14 <hartsocks> There's "ongoing" and then there's "ongoing" ...
17:29:29 <hartsocks> … I mean the oslo.vmware library has discrete releases.
17:29:39 <hartsocks> So you integrate release 1.
17:29:55 <hartsocks> When release 2 shows up, you use that.
17:30:14 <hartsocks> Is each one a full blown BP? It seems like that's how they want us to do business now.
17:31:05 <hartsocks> Make sense?
17:31:23 <dhellmann> fwiw, during juno I anticipate us doing regular alpha releases with a targeted 1.x release at the end of the cycle
17:31:24 <vuil> first part I think so.
17:31:30 <dhellmann> of all oslo libs
17:32:00 <hartsocks> dhellmann: so… does that mean we do an integration effort on each alpha release?
17:32:23 <hartsocks> dhellmann: and are those typically bugs or blueprints?
17:32:41 <hartsocks> dhellmann: or free floating patches (which I've seen a few on Nova)
17:32:43 <vuil> doug can you comment on whether you think each hunk of coversion of existing code to oslo.vmware will warrant a BP? Maybe a new work item in a bp or something?
17:32:46 <dhellmann> hartsocks: the devstack gate integration already pulls from master, and we are going to add similar integration jobs to run unit tests for consuming projects
17:32:59 <dhellmann> so for oslo.vmware, we might have nova and cinder unit tests gate changes to oslo.vmware for example
17:33:35 <dhellmann> vuil: I'm not sure it needs a separate blueprint in oslo, although if they are large chunks it would make tracking simpler
17:33:44 <dhellmann> I can't really comment on what other projects are going to want
17:34:03 <dhellmann> and I would think blueprints, not bugs
17:34:44 <hartsocks> dhellmann: that makes the imported version of the library up-to date. Which underscores that any interfaces we define need to stay stable.
17:35:01 <dhellmann> that's right
17:35:15 <hartsocks> dhellmann: and I suppose depending on the project's PTL and core team you have to have a blueprint to make the project use new methods and classes in your library.
17:35:43 <dhellmann> that's likely, but as you say it would depend on how the project runs
17:35:49 <hartsocks> okay.
17:36:18 <dhellmann> keep in mind, stable doesn't mean the API can't change, just that the old API needs to keep working in parallel
17:37:13 <hartsocks> in general, that means deprecate API you don't want to use, add new API and get people moving to the new API.
17:37:27 <hartsocks> So. How do you deprecate an API in OSLO?
17:37:34 <hartsocks> Is there a decorator?
17:38:15 <dhellmann> yes, there's a decorator in one of the incubator libs
17:38:33 <hartsocks> okay.
17:39:14 <hartsocks> I bring it up because of issues like: https://blueprints.launchpad.net/nova/+spec/vmware-vm-ref-refactor
17:39:25 <hartsocks> Where I'm convinced the issue is with the definition of the API.
17:40:14 <hartsocks> AFAIK we avoided moving that up to oslo.vmware but if we had mistakenly I wanted to know how to get out of the situation.
17:41:02 <dhellmann> hartsocks: you could leave the old code in place, create the new classes in separate (or the same) modules, deprecate the old way, update the consumers, and eventually remove it from the lib following a deprecation period
17:41:12 <dhellmann> we're still working out the details on "deprecation period" :-)
17:41:39 <dhellmann> we have to be careful that new releases of an oslo lib don't break old versions of apps while they are under stable maint, for example
17:41:48 * hartsocks wonders how long Java had deprecated date classes
17:42:12 <dhellmann> that probably means we need a 3 cycle deprecation, but that's just off-the-cuff and not a real policy
17:43:25 <hartsocks> okay, so it's a moving target.
17:44:21 <hartsocks> In some projects the level of VMware code is very shallow.
17:44:27 <hartsocks> vmware code integration
17:44:42 <hartsocks> so that means deprecation won't have to go on for very long.
17:44:55 <dhellmann> do you anticipate supporting users of this library other than the openstack projects?
17:45:13 <hartsocks> if it's oslo.vmware then it should be open stack only
17:45:21 <sdague> fungi: so https://jenkins03.openstack.org/job/check-tempest-dsvm-full-havana/59/console didn't do the right thing
17:46:03 <hartsocks> dhellmann, I happen to have been given a project to create a separate open source library in python that I anticipate moving anything really general out to
17:46:06 <fungi> oh no
17:46:38 <dhellmann> hartsocks: cool
17:47:28 <hartsocks> dhellmann: fyi … https://github.com/vmware/pyvmomi
17:47:38 <sdague> oops, sorry folks, tab placement challenges
17:47:49 <hartsocks> sdague: :-) I figured.
17:49:36 <hartsocks> okay, so we had a light turn out this week.
17:49:49 <hartsocks> I wanted to get to Juno planning but there's not enough folks around.
17:50:00 <hartsocks> #link https://etherpad.openstack.org/p/vmware-subteam-juno
17:50:20 <hartsocks> I think we should do some data collection on everything we want targeted for Juno
17:50:39 <hartsocks> … and we should do some sort of vote for priority order of things.
17:50:48 <hartsocks> (when coordination is needed)
17:51:22 <hartsocks> What do people think of that? Too much process? Too little? Let tjones decide?
17:53:10 <hartsocks> #topic open discussion
17:55:30 <hartsocks> going once...
17:56:58 <hartsocks> going twice…
17:58:26 <hartsocks> okay, see you next week
17:58:29 <hartsocks> #endmeeting