09:31:08 <BobBall> #startmeeting XenAPI
09:31:09 <openstack> Meeting started Wed Aug 24 09:31:08 2016 UTC and is due to finish in 60 minutes.  The chair is BobBall. Information about MeetBot at http://wiki.debian.org/MeetBot.
09:31:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:31:13 <openstack> The meeting name has been set to 'xenapi'
09:31:21 <BobBall> Good morning / afternoon all.
09:31:28 <BobBall> Ping for johnthetubaguy too :)
09:31:54 <johnthetubaguy> yeah, I spotted your email, yet to update my calendar
09:32:22 <BobBall> No worries.  Not sure how we got out of sync, but I proposed a fix to the upstream ical and the response was "there is no conflict" :)
09:32:34 <BobBall> Our biweekly was odd and scientific-wg is even :P
09:32:37 <johnthetubaguy> I suspect it was at the beginning of the year
09:32:38 <huanxie> Hi Bob and all
09:32:39 <BobBall> (or the other way round)
09:32:53 <johnthetubaguy> we had two odd weeks or something, at the end of last year
09:32:57 <BobBall> Well, hopefully now I've got the invite from the ical it will keep the right time.
09:33:03 <johnthetubaguy> I mean end of last, beginning of this
09:33:07 <jianghuaw> hello. every one.
09:33:28 <BobBall> #topic Blueprints / Reviews
09:33:34 <BobBall> OK - couple of things this week...
09:33:44 <BobBall> johnthetubaguy: Are you aware of https://review.openstack.org/#/c/289431/ ?
09:33:53 <johnthetubaguy> http://lists.openstack.org/pipermail/openstack-dev/2016-January/083216.html
09:34:16 <johnthetubaguy> BobBall: yeah, hadn't seen it was fixed up though
09:34:37 <BobBall> So this change is something that we *really* want in Newton
09:34:50 <BobBall> If we don't get the .py extension added now, it'll be a whole release before we can fix it again
09:34:59 <johnthetubaguy> so the original idea was that .py were utils and the others were plugins
09:35:11 <johnthetubaguy> not sure why we did that though
09:35:17 <BobBall> Understood, but flake8 won't run on non-.py stuff :(
09:35:29 <BobBall> Possibly just because that's how XS does it in our plugins
09:35:37 <johnthetubaguy> yep, and the unit tests go strange when you add "c" to the filename
09:35:39 <BobBall> But actually, xapi doesn't care what the name of the file is
09:35:52 <johnthetubaguy> yeah, I suspect it was just copying the pattern
09:35:54 <BobBall> heh :D yes.  agentc ...
09:36:01 <johnthetubaguy> did we update the permissions on the files?
09:36:16 <BobBall> Why are they wrong?
09:36:28 <johnthetubaguy> well, I think the plugins and utils were different
09:37:00 <BobBall> plugins must be executable
09:37:03 <johnthetubaguy> gerrit kinda hides all that detail
09:37:04 <BobBall> utils don't need to be
09:37:13 <BobBall> if plugins are not executable then XAPI can't load them.
09:37:19 <johnthetubaguy> right, which we have broke in the past
09:37:28 <johnthetubaguy> its really something the packaging should worry about I guess
09:37:54 <BobBall> Yeah, I agree with that
09:38:14 <BobBall> Anyway - any chance you can find time to review the change?
09:38:16 <johnthetubaguy> anyways, we can make it separate to that change
09:39:07 <BobBall> As I said, it's one that really needs to be in N so we can fix it finally in O
09:39:11 <johnthetubaguy> dang it, we are adding mox tests
09:39:44 <BobBall> yeah, because it's using the same session stuff... just following the existing pattern
09:40:06 <BobBall> I remember that was the recommendation at some point - is it now stricter and zero new mox tests?
09:40:41 <johnthetubaguy> yes
09:40:45 <johnthetubaguy> its zero new mock tests now
09:40:56 <johnthetubaguy> because there is a BP trying to convert all the mox tests to mock
09:41:02 <johnthetubaguy> if we keep adding them, it will never finish
09:41:20 <BobBall> Ah.  I missed that.
09:41:41 <BobBall> Thankfully this *should* be a simple test to mockify
09:42:23 <johnthetubaguy> so the compat here
09:42:37 <johnthetubaguy> the idea is to make sure we can have older versions of the plugins on the disk?
09:43:01 <johnthetubaguy> or newer plugins work with older code?
09:43:59 <johnthetubaguy> so I am not seeing any sym links, thats whats confusing me
09:44:06 <BobBall> The idea is to say that once Newton is out we can update plugin version to 2.0.  As long as Nova doesn't depend on new functionality (e.g. 2.1+) then you can deploy the new plugins
09:44:12 <BobBall> symlinks are there just not shown by gerrit
09:44:27 <BobBall> I think
09:44:38 <johnthetubaguy> so I checked out the code, I don't see them, unless I am missing something
09:44:45 <johnthetubaguy> gerrit normally shows sym links
09:45:08 <BobBall> hmmm... They were definitely in a previous version
09:45:53 <BobBall> Yeah - I don't see them either eeek
09:46:07 <BobBall> Well - that's not a huge deal as the packaging / deploying can always add the symlink
09:46:18 <BobBall> but yes, the commit message says they should be there.
09:46:40 <BobBall> Are you going to leave that feedback as a review comment, or shall I?
09:46:50 <johnthetubaguy> I can leave those comments
09:46:56 <BobBall> ok
09:47:08 <BobBall> Let's move on then
09:47:23 <BobBall> Anything else on blueprints?
09:47:45 <jianghuaw> Hi Bob and johnthetubaguy, our second proposal on VGPU was rejected in Newton. Now we are planning to re-start this work for Ocata. The last comment is to generalize the PCI devices.
09:48:12 <johnthetubaguy> so I think the problem there is around the resource providers
09:48:15 <jianghuaw> johnthetubaguy, could you give some advice>
09:48:16 <BobBall> Right - so this one we tried to start a ML thread about this since there were open questions
09:48:36 <johnthetubaguy> we now have a system we can model what we have more precisely, so we should do that
09:48:39 <BobBall> but there was no engagement on the ML and jay pipes was clearly over-worked at the time
09:48:48 <BobBall> Is resource providers complete in Newton?
09:48:51 <johnthetubaguy> nope
09:48:57 <BobBall> I didn't think it was
09:49:24 <johnthetubaguy> but this feature will be blocked till it is complete enough to add vGPU, I suspect
09:49:59 <BobBall> I see.  Do you know if that's planned to be complete enough in Ocata?
09:50:08 <johnthetubaguy> the ironic stuff, with dynamic resource types, feels quite similar to the VGPU stuff I guess
09:50:24 <johnthetubaguy> unsure, I just don't have enough visibility into the ordering of all the moving parts
09:51:13 <BobBall> OK.  I think we need to discuss with jay pipes to understand the ordering and whether there are useful things we can do to help move it along
09:52:06 <jianghuaw> Yes. Thanks John for the input.
09:52:27 <BobBall> OK - anything else for blueprints / reviews?
09:52:55 <jianghuaw> Another BP: https://review.openstack.org/#/c/274045/
09:53:33 <jianghuaw> Please help to review on it when you have time.
09:53:43 <jianghuaw> thanks.
09:53:44 <BobBall> Hmmm yes
09:53:53 <BobBall> Let's discuss that one offline jianghuaw
09:54:01 <jianghuaw> Sure. thanks.
09:54:31 <BobBall> It's ready for review, and the best it can be, but my concern is that it needs quite "ugly" parsing code in Nova.
09:54:55 <BobBall> A more important blueprint, when we have it available, will be to introduce os-xenapi
09:55:15 <johnthetubaguy> yeah, it may be a good excuse to create that
09:55:28 <BobBall> I'd definitely rather push for extracting out common code into a new library rather than pushing for the VDI store streaming
09:55:34 <johnthetubaguy> that might be a better place for python 2.4 code to live, etc
09:55:36 <BobBall> While we have johnthetubaguy ... Interesting question ...
09:55:43 <BobBall> Yes.  That's what I was going to say.
09:56:11 <johnthetubaguy> yeah, I am not against that approach
09:56:13 <BobBall> If Nova depends on a particular version of os-xenapi then the plugins could be moved there, and Nova using a python interface to os-xenapi to get specific functionality
09:56:22 <BobBall> which happens to be implemented in a plugin in dom0 in os-xenapi
09:56:25 <johnthetubaguy> yeah
09:56:36 <johnthetubaguy> thats a nice clean cut
09:56:38 <BobBall> The other thought was some of the tools that are currently in Nova's tree
09:56:45 <BobBall> which are unmaintained ATM
09:57:04 <johnthetubaguy> so there is an ops repo for that stuff now
09:57:06 <johnthetubaguy> os-ops
09:57:11 <BobBall> They seem a better fit for a common xenapi library or the ops repo
09:57:12 <BobBall> yes
09:57:24 <johnthetubaguy> #link https://wiki.openstack.org/wiki/Osops
09:57:33 <BobBall> but the ops repo I think doesn't import nova utilities stuff
09:57:44 <johnthetubaguy> right, but those scripts really shouldn't be doing that
09:57:45 <BobBall> so the tools can only use cli-based things?
09:57:48 <johnthetubaguy> its not a stable interface
09:57:59 <johnthetubaguy> mostly those tools only use REST APIs
09:58:05 <BobBall> Indeed.  As was proven when they broke.
09:58:24 <johnthetubaguy> honestly, just deleting them is the kindest thing
09:58:50 <BobBall> How do we delete tools?  Add big warning messages when they run to say they are deprecated and wait a cycle?
09:59:05 <johnthetubaguy> so its totally broken right now, and has been for over a cycle
09:59:13 <johnthetubaguy> I am OK counting that as deprecated
09:59:27 <johnthetubaguy> not sure if all the reviewers would agree with me
09:59:45 <BobBall> Understood.  We can submit a change to delete the tools and see what feedback comes back.
09:59:50 <BobBall> OK - moving on.
09:59:58 <BobBall> Anything else in the last 30 seconds?
10:00:18 <johnthetubaguy> oh, feature classification
10:00:19 <huazhihao> A small one for https://review.openstack.org/#/c/299092/
10:00:21 <huanxie> I have a patch fixing live-migrate https://review.openstack.org/#/c/359548/2
10:00:25 <johnthetubaguy> its slowly happening
10:00:36 <johnthetubaguy> http://docs.openstack.org/developer/nova/feature_classification.html
10:00:45 <johnthetubaguy> XenServer is listed there, hence the heads up
10:01:02 <BobBall> Anything you need us to do for that johnthetubaguy ?
10:01:27 <BobBall> johnthetubaguy: huanxie's patch is potentially important for Rackspace: https://review.openstack.org/#/c/359548
10:01:33 <johnthetubaguy> so I think "custom disk configurations on boot" should probably be a red cross thinking about it, but a double check would be great
10:01:53 <johnthetubaguy> BobBall: I remember you mentioning about that patch somewhen
10:02:06 <BobBall> You could work around it by setting the value in /etc/xapi.conf even though it's not needed, but Huan's change should fix it
10:02:33 <BobBall> Ah - and huazhihao's change https://review.openstack.org/#/c/299092 is a trivial fix
10:03:09 <BobBall> ovs_integration_bridge setting to xapi1 in Nova is going to be wrong more times than it's right, so we wanted to remove the default so people have to set it if using Neutron
10:04:26 <BobBall> OK - so actually I think we're keen to get huazhihao's, huanxie's and the .py fixes all into Newton if we can
10:05:01 <BobBall> johnthetubaguy: Can you remind me?   Is n-3 the deadline for those, or is RC1 the deadline for bug fixes?
10:05:59 <johnthetubaguy> RC1
10:06:25 <johnthetubaguy> but... we do only let through lower risk bug fixes as we approach RC, and focus more on regressions.
10:07:18 <BobBall> Understood.  So we need to push these bugfixes now and before n-3 if at all possible.
10:07:36 <BobBall> n-3 is 1 week on Friday, so we don't have much time to push for them.
10:08:36 <BobBall> I think there's nothing else?
10:08:46 <huanxie> None for me
10:08:49 <BobBall> Unless there is anything else, we should close the meeting there.
10:08:53 <BobBall> 3....
10:08:55 <BobBall> 2...
10:08:57 <BobBall> 1......
10:09:02 <BobBall> Thanks all! :)
10:09:04 <BobBall> #endmeeting