09:31:14 #startmeeting XenAPI 09:31:15 Meeting started Wed Aug 17 09:31:14 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:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:31:18 The meeting name has been set to 'xenapi' 09:31:38 johnthetubaguy: ping :) 09:31:55 First subject: Meeting time. 09:32:07 I realised that I hadn't updated the meeting room, so I have now done so 09:32:14 #link https://review.openstack.org/356332 09:32:26 Please review and comment / vote on the change. 09:32:45 Main issue is, of course, that the validation scripts don't check for overlapping 1h meetings, just start times 09:33:03 so scientific-wg changed to use the #openstack-meeting room at 0900 UTC even though we were due to use at 0930 UTC 09:33:30 Hi all 09:33:40 hi huanxie jianghuaw and huazhihao 09:33:48 Do we have anyone else here for the meeting today? 09:33:50 Hi all 09:33:54 Morning Bob. 09:34:33 I could wait a very long time for an answer to that question :D 09:34:45 Bob: so will we use #openstack-meeting-alt for the future XenAPI meetings or just for this time once? 09:35:01 All future meetings - see proposed change at https://review.openstack.org/356332 09:35:10 I have also updated https://wiki.openstack.org/wiki/Meetings/XenAPI 09:35:22 Ok. thanks. 09:35:36 Thanks BobBall 09:35:48 OK, it seems that johnthetubaguy is not around 09:36:15 A few points of note - there is a tricky review up on the plugins 09:36:38 #link https://review.openstack.org/#/c/289431/ 09:37:00 It's particularly tricky because there will be some plugin version number fudging to mean that 1.8 is the same as 2.0 09:37:31 Once Newton is released, we will change the plugin version to 2.0, change the requried version to 2.0 and remove the symlinked non-.py files 09:37:42 This is all so the plugins all end in .py so they can be run through the flake checks 09:38:00 Any questions on how we hope it will work? 09:38:36 It's the first time we have a major version bump for the plugins 09:39:22 OK, good 09:39:28 Bob: it makes sense. 09:39:38 Do please review that chnage (https://review.openstack.org/#/c/289431/) and add any comments there 09:39:48 Sure. 09:39:50 Sure 09:40:04 Will do 09:40:33 OK - anything else we should talk about. 09:40:53 Support for Fuel 9 has now merged into our fuel-plugins-xenapi 09:41:04 that was a big milestone over the last 2 weeks which si good 09:41:35 Anything else on the fuel plugin worth highlighting? 09:42:04 OK 09:42:07 #topic Newton priorities 09:42:17 We currently have two items in the priorities tracking: 09:42:20 Spec reviews that are ready for Nova core review. Have been reviewed by subteam: 09:42:23 https://review.openstack.org/#/c/274045/ - XenAPI: a new VDI store via streaming 09:42:26 Code reviews that are ready for Nova core review. Have been reviewed by subteam: 09:42:29 https://review.openstack.org/#/c/286383/ - Adds unit tests 09:42:52 Are there any other reviews for Nova which are ready for review but not linked in the https://etherpad.openstack.org/p/newton-nova-priorities-tracking document? 09:43:16 None for me ATM 09:43:54 huazhihao? Any changes from you which are not in the priorities list yet? 09:45:04 I have no more beside the above two. 09:45:30 ok 09:45:51 I did actually see https://review.openstack.org/#/c/341304/ which has a comment we can discuss 09:46:10 The question is why does the xenapi rootwrap need a custom way to extract the return code / etc 09:46:38 I'm thinking that maybe it doesn't - can we move this code to the rootwrap executable itself? 09:46:54 and then exit the rootwrap executable with the return code extracted from the dictionary? 09:46:56 Let me see 09:46:58 thoughts? 09:47:50 Maybe https://review.openstack.org/#/c/299092/ or https://review.openstack.org/#/c/333781/ ? 09:48:16 For exmaple, https://review.openstack.org/#/c/341304/8/bin/neutron-rootwrap-xen-dom0 line 121 could sys.exit with the return code extracted from the dictionary 09:48:19 "Remove ovs_integration_bridge default value" or the device tagging 09:48:25 I think we have two level return, the outer is not the actuall exit code which run in dom0 conntrack command returns 09:49:05 huazhihao: https://review.openstack.org/#/c/299092 has an outstanding review comment from John Garbutt which you haven't dealt with 09:49:32 https://review.openstack.org/#/c/333781 will be -2 until Ocata; we will likely need a specless blueprint to get that change merged 09:49:35 Ah yes there is 09:49:46 huanxie: Not sure what you mean? 09:52:39 BobBall: neutron-rootwrap-xen-dom0's return code is not the actually exit code of this command "conntrack" 09:53:01 At the moment - but the question is, could we change neutron-rootwrap-xen-dom0 to always return the exit code of the command 09:53:16 particularly if it failed in dom0 and we have the evidence returned through the dictionary 09:54:10 yes, this change is not only for conntrack, with that change, the execute command's exit code will be returned through the dict 09:54:37 OK - can you look into the comment and think whether that's a possibility then> 09:54:38 what do you mean the evidence? 09:54:42 It'd be good to avoid changes in utils 09:55:02 sure, I will look into the comments 09:55:04 What I meant was that if the XAPI command succeeded we will have the dictionary which is the 'evidence' that contains the exit code 09:55:32 ok 09:55:40 #topic AOB 09:55:42 I see 09:55:48 Is there anything else we should discuss today? 12:43:40 #endmeeting