09:32:21 #startmeeting XenAPI 09:32:22 Meeting started Wed Sep 21 09:32:21 2016 UTC and is due to finish in 60 minutes. The chair is BobBall. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:32:23 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 09:32:25 The meeting name has been set to 'xenapi' 09:32:28 johnthetubaguy: ping :) 09:33:04 Good morning BobBall and johnthetubaguy. 09:33:14 Good afternoon, Huan. 09:33:20 Afternoon jianghuaw 09:33:29 #link https://wiki.openstack.org/wiki/Meetings/XenAPI 09:33:38 #topic Blueprints 09:33:43 Right - so Ocata is open! 09:33:59 New priorities tracking link: 09:34:02 hi all 09:34:04 #link https://etherpad.openstack.org/p/ocata-nova-priorities-tracking 09:34:27 Could you check that blueprints we want approved in Ocata are in the list 09:34:52 In particular I think we have a spec-less BP for vif plug which is not on the list? 09:35:06 We should also have a spec-less BP for XenAPI's implementation of device tagging 09:35:07 Yes, I will add it to the list 09:35:25 but John Hua is on vacation today 09:35:35 I will ask him to add it 09:35:50 huanxie: Just a point; we need the spec to be approved *before* the code is ready to be reviewed by nova core 09:36:06 so if the VIF hotplug spec has not yet been approved, the code review shouldn't be in that list 09:36:47 BobBall, there is a BP for it so I didn't create a new one 09:36:53 are you sure thats the right place to put those? I thought spec less BPs should be added to the meeting agenda 09:36:58 huanxie: Is it an Ocata BP? 09:37:18 johnthetubaguy: I'm sure you know better than me :) 09:37:19 No, https://blueprints.launchpad.net/openstack/?searchtext=xenapi-vif-hotplug 09:37:46 I see johnthetubaguy raised a BP for VIF hot plug, so I just use that one 09:38:00 Ah, I see - this is one of johnthetubaguy's 3 year old BPs :) 09:38:10 johnthetubaguy: does this need a spec now? or do you think this is OK for spec-less? 09:38:13 Should I use this BP or I create a new one? 09:38:25 I'd assume spec-less as it's a very well understood requirement 09:38:50 spec-less seems OK 09:38:57 its a "me too" feature 09:39:04 there was code up for that BP too, somewhere 09:39:07 OK - so we'll put that on the next nova meeting agenda 09:39:20 Indeed; and huanxie has already adapted that and proved it works with the new code structure. 09:39:21 yeah, I think thats the best way to get us to decide the way forward on that 09:39:28 cool 09:39:37 The next BP we want is one for os-xenapi 09:39:47 yes, with that patch it can pass tempest and manual test 09:39:57 jianghuaw is currently investigating this one and we'll get a spec + BP up as soon as we can 09:40:28 But, as a first push, I think we want to move session code and dom0 plugins to os-xenapi 09:40:51 Both are used by multiple projects (nova, neutron, ceilometer) and so it makes sense to clean up Nova as well by removing the Python 2.4 code 09:41:32 yes, the plan is to move the xenapi plugins to os-xenapi also. 09:41:41 Thoughts johnthetubaguy? Good pair of things to move, anything else you think we should push to move in the first instance? 09:43:32 ping for johnthetubaguy :) 09:44:38 We may have lost johnthetubaguy 09:44:43 sorry, distracted 09:44:47 Anything else we should cover? 09:44:52 I think moving the plugins is a good start 09:44:57 its worth starting small 09:45:08 and folks will like those plugins going away from the nova tree 09:45:25 I really want to move a bunch of the session code too because we're using that in Neutron and Ceilometer - but very badly in those two projects 09:45:45 yeah, +1 on that being the next thing to move 09:45:51 Nova's XenAPI session handling is comparatively light years ahead 09:46:08 I mean move nova's into the lib, then later we stop using nova's 09:46:30 I guess its good to have real code in the lib, so thats a good starting point 09:46:44 Absolutely. 09:46:53 yeah, I buy that, seems like a good start 09:47:02 OK - huanxie / jianghuaw - Anything I've forgotten on the spec/BP front? 09:47:23 none for me 09:47:48 OK 09:47:51 #topic Reviews 09:47:56 Is there anything stuck? 09:48:06 I saw yesterday that some of the UT code has been merged jianghuaw 09:48:14 along with the bandwidth vif fix, so that's good 09:48:18 yes. 09:48:51 and also hope this one will be approved soon: https://review.openstack.org/#/c/366825/ - Use raw disk format as default when create image with glance v2 09:48:55 I guess pick the top 4 or 5 and get them into the etherpad 09:49:40 There are a bunch in the etherpad of course - but with the etherpad being so huge it's proving to not be a good way to push for reviews 09:50:09 yep, we are talking about just deleting the non-priority things really 09:50:26 there was that review board idea, but not sure that saw traction 09:50:42 we basically don't have enough folks reviewing code right now, people are just not stepping up there 09:51:30 https://review.openstack.org/#/c/299092/ is a good example - has been in the etherpad for ages and is a trivial fix - but I think you were the only core to look at it, and that was last checked a month ago 09:51:44 trying to spread the idea of doing at least 5 code reviews for every patchset (not review) you upload 09:51:50 Indeed 09:52:33 well, the last month is a bad example, becusase everyone should be focused on rc critical stuff 09:52:36 so thats quite correct 09:52:49 last few days we are opened back up a bit, obviously 09:53:00 Unfortunately without a tool to enforce that and track progress against it - for example a way to ensure that reviews done have some impact on getting reviews on the changes you care about - it's hard to justify deep reviews 09:54:03 there is no simple way to spot a good review 09:54:21 It's great for the community in general (hopefully) of course - but justifying it to managers it's just effort that goes into a black hole - possibly in entirely the wrong direction - with no return on the time spent 09:54:41 right, we have made it offical policy that it should be done, and why it needs doing 09:54:53 if there is any more I can write down for you to get permission, do shout up 09:54:55 Where is that policy documented? 09:55:31 It's not about more documentation, just that the traceability of "doing more reviews" is precisely zero currently 09:55:59 well, thats not true, we can trace *some* reviews very quickly 09:56:04 #link http://docs.openstack.org/developer/nova/how_to_get_involved.html#why-do-code-reviews-if-i-am-not-in-nova-core 09:56:15 so reading through that, its not forceful enough 09:56:22 we could make it more forceful 09:56:28 As we've discussed before, even if we do 10 reviews for every patchset uploaded, there is no feedback mechanism for effort to be directed to the things we care about 09:56:53 #link http://docs.openstack.org/developer/nova/how_to_get_involved.html#how-do-i-get-my-feature-in 09:57:03 right, thats not really the point 09:57:33 if everyone does 10 reviews, there is a way smaller queue, and loads of patches ready to merge, so the core time can be more wisely spent 09:57:40 Nah - the problem with that is that random reviews speed up overall velocity, great, but if the overall velocity is 99% in favour of libvirt changes (for example) then the impact of doing more reviews on changes where we want some reviews is virtually zero 09:59:40 Absolutely - but my point is that the vast majority of that core time is still focused on their own priorities / nova priorities which are for the most part focused around libvirt 10:00:14 Also, the nova queue is *huge* and so random reviews, rather than targetted ones, are most likely to hit changes that would unlikely to be reviewed by core reviewers anyway 10:00:15 true, but we are currently swamped by that stuff, so its hard to make time for the other stuff 10:00:21 But, we're getting too detailed. 10:00:47 I'm very much looking forward to the rest of the Newton retrospective and the discussion of permitting non-core +2's in particular subtrees scheduled for Barcelona 10:01:29 we don't see folks reviews enough to build up the trust right now for that to happen 10:02:05 I want it to happen, but its just not happening right now 10:02:28 I presume you know about the discussion proposed for Barcelona and the posts to openstack-dev on this subject in the last few days? 10:03:36 btw, one one of these was lib-virt specific, one of them only happened in libvirt so far, but its not specific: http://specs.openstack.org/openstack/nova-specs/priorities/newton-priorities.html 10:03:52 I know about the etherpad, not followed the latest threads 10:04:44 Fair enough - well - it looks like some other core reviewers think that such a model is justifiable now 10:05:33 And I should have been clearer - rather than being libvirt specific, my point is that there are specialised sections (such as XenAPI) which could be argued to be that 1% of developer effort 10:05:51 yeah, I have been campaigning for it for years, the problem is building up the trust relationship to make it happen 10:07:36 Thankfully the proposal seems to suggest that the level of "trust" in the reviews doesn't have to be huge - suggesting that only core reviewers could +A and with a banhammer in easy reach 10:08:26 Therefore the impact on a bad +2 from a subsystem maintainer is small as the core is likely not to +2 really bad/incomplete changes - as long as you trust your cores 10:09:28 Anyway - we have over-run today 10:09:40 Is there anything more to cover? 10:10:16 Awesome. 10:10:18 Thanks all! 10:10:18 none from me. thanks. 10:10:21 #endmeeting