09:32:21 <BobBall> #startmeeting XenAPI
09:32:22 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
09:32:25 <openstack> The meeting name has been set to 'xenapi'
09:32:28 <BobBall> johnthetubaguy: ping :)
09:33:04 <jianghuaw> Good morning BobBall and johnthetubaguy.
09:33:14 <jianghuaw> Good afternoon, Huan.
09:33:20 <BobBall> Afternoon jianghuaw
09:33:29 <BobBall> #link https://wiki.openstack.org/wiki/Meetings/XenAPI
09:33:38 <BobBall> #topic Blueprints
09:33:43 <BobBall> Right - so Ocata is open!
09:33:59 <BobBall> New priorities tracking link:
09:34:02 <huanxie> hi all
09:34:04 <BobBall> #link https://etherpad.openstack.org/p/ocata-nova-priorities-tracking
09:34:27 <BobBall> Could you check that blueprints we want approved in Ocata are in the list
09:34:52 <BobBall> In particular I think we have a spec-less BP for vif plug which is not on the list?
09:35:06 <BobBall> We should also have a spec-less BP for XenAPI's implementation of device tagging
09:35:07 <huanxie> Yes, I will add it to the list
09:35:25 <BobBall> but John Hua is on vacation today
09:35:35 <BobBall> I will ask him to add it
09:35:50 <BobBall> 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 <BobBall> so if the VIF hotplug spec has not yet been approved, the code review shouldn't be in that list
09:36:47 <huanxie> BobBall, there is a BP for it so I didn't create a new one
09:36:53 <johnthetubaguy> 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 <BobBall> huanxie: Is it an Ocata BP?
09:37:18 <BobBall> johnthetubaguy: I'm sure you know better than me :)
09:37:19 <huanxie> No, https://blueprints.launchpad.net/openstack/?searchtext=xenapi-vif-hotplug
09:37:46 <huanxie> I see johnthetubaguy raised a BP for VIF hot plug, so I just use that one
09:38:00 <BobBall> Ah, I see - this is one of johnthetubaguy's 3 year old BPs :)
09:38:10 <BobBall> johnthetubaguy: does this need a spec now?  or do you think this is OK for spec-less?
09:38:13 <huanxie> Should I use this BP or I create a new one?
09:38:25 <BobBall> I'd assume spec-less as it's a very well understood requirement
09:38:50 <johnthetubaguy> spec-less seems OK
09:38:57 <johnthetubaguy> its a "me too" feature
09:39:04 <johnthetubaguy> there was code up for that BP too, somewhere
09:39:07 <BobBall> OK - so we'll put that on the next nova meeting agenda
09:39:20 <BobBall> Indeed; and huanxie has already adapted that and proved it works with the new code structure.
09:39:21 <johnthetubaguy> yeah, I think thats the best way to get us to decide the way forward on that
09:39:28 <johnthetubaguy> cool
09:39:37 <BobBall> The next BP we want is one for os-xenapi
09:39:47 <huanxie> yes, with that patch it can pass tempest and manual test
09:39:57 <BobBall> jianghuaw is currently investigating this one and we'll get a spec + BP up as soon as we can
09:40:28 <BobBall> But, as a first push, I think we want to move session code and dom0 plugins to os-xenapi
09:40:51 <BobBall> 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 <jianghuaw> yes, the plan is to move the xenapi plugins to os-xenapi also.
09:41:41 <BobBall> Thoughts johnthetubaguy?  Good pair of things to move, anything else you think we should push to move in the first instance?
09:43:32 <BobBall> ping for johnthetubaguy :)
09:44:38 <BobBall> We may have lost johnthetubaguy
09:44:43 <johnthetubaguy> sorry, distracted
09:44:47 <BobBall> Anything else we should cover?
09:44:52 <johnthetubaguy> I think moving the plugins is a good start
09:44:57 <johnthetubaguy> its worth starting small
09:45:08 <johnthetubaguy> and folks will like those plugins going away from the nova tree
09:45:25 <BobBall> 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 <johnthetubaguy> yeah, +1 on that being the next thing to move
09:45:51 <BobBall> Nova's XenAPI session handling is comparatively light years ahead
09:46:08 <johnthetubaguy> I mean move nova's into the lib, then later we stop using nova's
09:46:30 <johnthetubaguy> I guess its good to have real code in the lib, so thats a good starting point
09:46:44 <BobBall> Absolutely.
09:46:53 <johnthetubaguy> yeah, I buy that, seems like a good start
09:47:02 <BobBall> OK - huanxie / jianghuaw - Anything I've forgotten on the spec/BP front?
09:47:23 <huanxie> none for me
09:47:48 <BobBall> OK
09:47:51 <BobBall> #topic Reviews
09:47:56 <BobBall> Is there anything stuck?
09:48:06 <BobBall> I saw yesterday that some of the UT code has been merged jianghuaw
09:48:14 <BobBall> along with the bandwidth vif fix, so that's good
09:48:18 <jianghuaw> yes.
09:48:51 <jianghuaw> 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 <johnthetubaguy> I guess pick the top 4 or 5 and get them into the etherpad
09:49:40 <BobBall> 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 <johnthetubaguy> yep, we are talking about just deleting the non-priority things really
09:50:26 <johnthetubaguy> there was that review board idea, but not sure that saw traction
09:50:42 <johnthetubaguy> we basically don't have enough folks reviewing code right now, people are just not stepping up there
09:51:30 <BobBall> 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 <johnthetubaguy> trying to spread the idea of doing at least 5 code reviews for every patchset (not review) you upload
09:51:50 <BobBall> Indeed
09:52:33 <johnthetubaguy> well, the last month is a bad example, becusase everyone should be focused on rc critical stuff
09:52:36 <johnthetubaguy> so thats quite correct
09:52:49 <johnthetubaguy> last few days we are opened back up a bit, obviously
09:53:00 <BobBall> 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 <johnthetubaguy> there is no simple way to spot a good review
09:54:21 <BobBall> 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 <johnthetubaguy> right, we have made it offical policy that it should be done, and why it needs doing
09:54:53 <johnthetubaguy> if there is any more I can write down for you to get permission, do shout up
09:54:55 <BobBall> Where is that policy documented?
09:55:31 <BobBall> It's not about more documentation, just that the traceability of "doing more reviews" is precisely zero currently
09:55:59 <johnthetubaguy> well, thats not true, we can trace *some* reviews very quickly
09:56:04 <johnthetubaguy> #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 <johnthetubaguy> so reading through that, its not forceful enough
09:56:22 <johnthetubaguy> we could make it more forceful
09:56:28 <BobBall> 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 <johnthetubaguy> #link http://docs.openstack.org/developer/nova/how_to_get_involved.html#how-do-i-get-my-feature-in
09:57:03 <johnthetubaguy> right, thats not really the point
09:57:33 <johnthetubaguy> 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 <BobBall> 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 <BobBall> 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 <BobBall> 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 <johnthetubaguy> true, but we are currently swamped by that stuff, so its hard to make time for the other stuff
10:00:21 <BobBall> But, we're getting too detailed.
10:00:47 <BobBall> 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 <johnthetubaguy> we don't see folks reviews enough to build up the trust right now for that to happen
10:02:05 <johnthetubaguy> I want it to happen, but its just not happening right now
10:02:28 <BobBall> 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 <johnthetubaguy> 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 <johnthetubaguy> I know about the etherpad, not followed the latest threads
10:04:44 <BobBall> Fair enough - well - it looks like some other core reviewers think that such a model is justifiable now
10:05:33 <BobBall> 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 <johnthetubaguy> yeah, I have been campaigning for it for years, the problem is building up the trust relationship to make it happen
10:07:36 <BobBall> 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 <BobBall> 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 <BobBall> Anyway - we have over-run today
10:09:40 <BobBall> Is there anything more to cover?
10:10:16 <BobBall> Awesome.
10:10:18 <BobBall> Thanks all!
10:10:18 <jianghuaw> none from me. thanks.
10:10:21 <BobBall> #endmeeting