17:01:08 <jroll> #startmeeting ironic
17:01:09 <jlvillal> :)
17:01:09 <openstack> Meeting started Mon Dec  5 17:01:08 2016 UTC and is due to finish in 60 minutes.  The chair is jroll. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:11 <aslezil> o/
17:01:11 <vdrok> o/
17:01:12 <openstack> The meeting name has been set to 'ironic'
17:01:16 <jlvillal> o/
17:01:17 <mariojv> o/
17:01:18 <galyna_> Hello to everyone!
17:01:20 <sambetts> o/
17:01:23 <rpioso> o/
17:01:23 <rajinir> o/
17:01:24 <galyna_> rloo and all, I'd like to ask about the priority of etags spec in api evolution. As for my status, the spec is updated and needs a review https://review.openstack.org/#/c/381991/. And approapriate patches, POC are up, just need uninttests. Thanks for you review in advance
17:01:25 <rloo> o/
17:01:33 <bfournie> o/
17:01:40 <galyna_> o/
17:01:53 <joanna> o/
17:01:54 <TheJulia> o/
17:01:59 <krtaylor> o/
17:02:07 <jroll> galyna_: please wait for open discussion for review requests :)
17:02:27 <jroll> as always, the agenda:
17:02:31 <jroll> #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting
17:02:37 <jroll> #topic announcements and reminders
17:02:52 <jroll> I just have one thing, I'll be out next week, does someone mind running the meeting?
17:03:17 <TheJulia> I could run it
17:03:26 <jroll> awesome, thanks!
17:03:31 <jroll> #info TheJulia to run next week's meeting
17:03:32 <vdrok> jaypipes asked about reviews on resource providers stuff -- http://lists.openstack.org/pipermail/openstack-dev/2016-December/108393.html
17:03:47 <jroll> vdrok: yeah, that's on my list for today, I encourage others to review it
17:04:56 <jroll> anything else?
17:05:01 <mgould> o/
17:05:02 <xavierr> o/
17:05:27 <jroll> #topic subteam status reports
17:05:30 <jroll> as always
17:05:32 <jroll> #link https://etherpad.openstack.org/p/IronicWhiteBoard
17:05:35 <jroll> around line 79 this week
17:05:53 <mjturek> o/
17:06:05 <milan> o/
17:06:12 <jroll> looks like dtantsur|brb didn't have time to update bug stats, but I know I saw JayF helping with some triage last week, thanks for that!
17:06:13 <mariojv> my apologies for missing notification status update last week; i was on vacation
17:06:19 <mariojv> it's updated this week
17:06:43 <JayF> I have been, there's a lot more left to go
17:06:55 <JayF> but I'll keep trying to triage a couple dozen a day until I've worked through them all
17:07:21 <rloo> oh, is dtantsur|brb away today?
17:07:31 <rloo> i can update the bug stat i think...
17:07:39 <rama_y> o/
17:07:45 <jroll> rloo: nice, thanks
17:08:02 <dtantsur|brb> rloo, I'm semi-away, sorry :(
17:08:19 <xhku> o/
17:08:24 <lindycoder> o/
17:08:30 <jroll> luzC: nice job fixing the postgres job :)
17:08:45 <jroll> er, lucas<tab> is not here :(
17:09:24 <jroll> looks like rolling upgrades spec can land this week
17:10:38 <jroll> BFV made good progress \o/
17:10:44 <xavierr> only cores can do bug triage?
17:10:50 <jlvillal> xavierr: No
17:10:54 <jlvillal> I don't think so
17:11:01 <jroll> xavierr: no, anyone can help, just be sure to ask questions if you don't know things
17:11:02 <jlvillal> xavierr: You just need to join the launchpad group
17:11:10 <rloo> ok, bug stats updated. inspector has 2 critical! :-(
17:11:34 <xavierr> jroll jlvillal o/
17:11:39 <jlvillal> xavierr: https://launchpad.net/~ironic-bugs
17:12:37 <xavierr> jlvillal: thanks
17:12:46 * dtantsur back
17:12:52 <dtantsur> thanks rloo for covering me with bug stats
17:13:04 <rloo> dtantsur: yw, the hardest part was doing the math :)
17:13:26 <dtantsur> xavierr, join that group and get acquainted with https://wiki.openstack.org/wiki/BugTriage
17:13:31 <dtantsur> that's all you need
17:14:30 <dtantsur> TheJulia, re BFV nova part: I guess it's in pretty sad condition, right?
17:14:39 * xavierr have successfully joined Ironic Bugs Team
17:14:41 <rloo> dtantsur: wrt inspector. 'there might be some controversion w/r ...'. controversy?
17:15:06 <dtantsur> rloo, it was not me who wrote that, but yes :)
17:15:07 <TheJulia> dtantsur: I've not touched it because I pretty much considered that I was mainly pushing this stuff forward alone and the the only way I would be able to get stuff moving is one cycle at a time per project
17:15:14 * dtantsur would definitely confuse these words as well
17:15:27 <TheJulia> dtantsur: tl;dr help on that front would be awesome!
17:15:31 <dtantsur> TheJulia, ok, Lucas and I may will with it
17:15:37 <dtantsur> s/may will/will help/
17:15:43 <TheJulia> \o/
17:16:14 * TheJulia looks at the clock
17:16:25 <jroll> indeed
17:16:39 <jroll> anything we should add/remove in terms of what to look at this week?
17:16:46 * jroll puts next driver comp patch in there
17:17:07 <milan> rloo, ah, yeah
17:17:09 <milan> thx
17:17:14 <rloo> milan: :)
17:17:27 <dtantsur> just a note: I'm out Dec 17 - Jan 2
17:17:48 <jroll> good to know
17:17:50 <dtantsur> so we'd better land a few driver composition before that :) /me sees one on the priority list, good
17:17:53 <JayF> Similarly; I'm out 12/17 - 12/26
17:17:54 <NobodyCam> o/
17:17:54 <jroll> I actually put this on the agenda
17:18:01 <jroll> so let's wait to all post our vacation :)
17:18:05 <TheJulia> jroll: the review url for bfs stuff needs to be updated, but I can take care of that later.  Ether pad is hung for me at the moment
17:18:18 <rloo> 'so we better land everything before Dec 17' :D
17:18:20 <TheJulia> err, bfv
17:18:21 <jroll> TheJulia: link it here and I'll do it :)
17:18:27 <TheJulia> https://review.openstack.org/#/q/status:open+project:openstack/ironic+branch:master+topic:bug/1559691
17:18:50 <jroll> thanks
17:19:10 <jroll> anything else on this topic?
17:19:11 <TheJulia> I'm expecting to be semi-unavailable for a few days around the 26th, but I'm fine with a meeting on the 2nd.
17:19:11 <dtantsur> does anybody has a link to nova bp handy?
17:19:18 <jroll> dtantsur: for?
17:19:24 <dtantsur> jroll, BFV
17:19:33 <jroll> dtantsur: not sure we have one, we don't expect it to happen this cycle
17:19:38 <jroll> afaik
17:19:41 <TheJulia> dtantsur: I'll get it, give me a couple minutes
17:19:42 <jroll> I may be remembering wrong
17:19:44 <jroll> oh cool
17:19:45 <dtantsur> we do, I saw it today
17:20:16 <dtantsur> aha, https://blueprints.launchpad.net/nova/+spec/ironic-boot-from-volume
17:20:23 <TheJulia> ahh, thank you dtantsur
17:21:28 <jroll> ok, anything else?
17:22:05 <jroll> #topic what are core's schedules like for december? What meetings should we cancel? (initial proposal, cancel Dec 26 and Jan 2)
17:22:20 <jroll> so I'm out dec 9-14 and dec 22 - jan 2
17:22:34 <jroll> and propose we cancel meetings for dec 26 and jan 2
17:22:35 <vdrok> I'm out Jan 2 and Jan 7 :'(
17:22:57 <rloo> i'm out dec 22 - jan 8
17:23:10 <jlvillal> I am out 24-Dec-2016 through 2-Jan-2016. Back on 3-Jan-2016.
17:23:20 <TheJulia> I'm only really expecting to be out the 26th, maybe sporadically that week.
17:24:01 <mariojv> not core but out 22nd-27th, probably 1 more day last week of december, and jan. 2nd
17:24:07 <JayF> I'm out 12/17 - 12/26
17:24:15 <JayF> jroll: I wonder why we should even try to have the 12/19 meeting
17:24:24 <JayF> jroll: why not cancel 12/19, 12/26 and 1/2
17:24:36 <jlvillal> I will be here the 19th
17:24:44 <dtantsur> I'll be here Jan 2 btw
17:24:48 <jlvillal> But agree with cancelling 112/26 and 1/2
17:24:49 <jroll> JayF: seems like at least a few people will be here 12/19
17:24:52 <rloo> there are at least 4 cores that will be here the 19th.
17:25:00 <rloo> i think cancelling 3 meetings in a row is too much
17:25:00 <dtantsur> I'm out only on 19th and 26th
17:25:12 * JayF just trying to save others from meetnigs, he won't be at a 12/19 meeting either way
17:25:17 <TheJulia> Lets just cancel the 26th, if we have super short meetings on the 19th and 2nd, then \o/
17:25:23 <sambetts> I'm out 12th -> 3rd
17:25:25 <JayF> TheJulia: you don't get 1/2 off?
17:25:28 <mariojv> +1 to keeping the 19th meeting. it'll probably be short though
17:25:35 <jroll> okay, we could leave jan 2 if people like, can't hurt
17:25:36 <JayF> TheJulia: most people in US should get 1/2 off as observation of NYD
17:25:39 <jroll> will need someone to run it though :)
17:25:43 <TheJulia> JayF: I dunno :)
17:25:53 <rloo> think TheJulia can run them :)
17:25:54 <dtantsur> jroll, I can run Jan 2 if needed.. though I'm not sure it's going to be useful
17:26:27 <TheJulia> JayF: Holidays are weird for me since my significant other works for a bank.
17:26:32 <jroll> dtantsur: it might be nice for the people that are around to sync up
17:26:46 <dtantsur> jroll, ok, I can run it if I'm not too wasted that day
17:26:58 <jroll> heh
17:26:59 <TheJulia> jroll: I think syncing up would be a good idea so we don't loose all velocity until mid janurary
17:27:07 <jroll> okay, we'll leave it
17:27:29 <jroll> thanks y'all
17:27:31 <rloo> that reminds me, we have < 2 months before ocata release
17:27:35 <dtantsur> so, only 12/26 is out for everyone, right?
17:27:40 <jroll> sounds like it
17:28:11 <jroll> #topic RFE review
17:28:15 <jroll> rloo: take it away :)
17:28:41 <rloo> https://bugs.launchpad.net/ironic/+bug/1638505
17:28:41 <openstack> Launchpad bug 1638505 in Ironic "[RFE] Allow to not cache images on conductor for iPXE nodes in standalone mode" [Wishlist,New] - Assigned to Pavlo Shchelokovskyy (pshchelo)
17:28:59 <rloo> should we require a spec for that?
17:29:24 <dtantsur> I thought we do have a spec, but maybe I'm wrong
17:29:52 <TheJulia> I'd personally like a little more context on that RFE.
17:29:59 <jroll> I seem to remember a spec too, pas-ha isn't here
17:30:02 <jroll> I would as well
17:30:11 <jroll> let's ask for one and maybe there already is one :)
17:30:17 <rloo> ok, let's ask for one.
17:30:26 <rloo> next ...
17:30:27 <rloo> https://bugs.launchpad.net/ironic/+bug/1639688
17:30:27 <dtantsur> hmm, I thought about https://review.openstack.org/#/c/392290/
17:30:28 <openstack> Launchpad bug 1639688 in Ironic "[RFE] Add "reset bios settings to default" to iRMC drivers as cleaning step" [Wishlist,New]
17:30:48 <rpioso> Not sure if the scope is sufficent. What does "default" mean? Seems to me that the BIOS settings depend on the role/flavor.
17:30:54 <dtantsur> rloo, I'm fine with that
17:31:01 <dtantsur> rpioso, I think to factory defaults, but I may be wrong
17:31:08 <jroll> I'm fine with it too, but rpioso has a good question
17:31:10 <jroll> oh yes, probably
17:31:35 <JayF> I'm generally fine with any cleaning step added to a driver
17:31:39 <rpioso> dtantsur: I don't feel that would be sufficient.
17:31:40 <mariojv> i think that RFE needs to be expanded, though
17:31:41 <JayF> as they would be the experts
17:31:51 <JayF> but I would like the RFE to mention if it's going to be a priority =0 or >0
17:31:54 <TheJulia> rloo: I'm also fine with it just being an RFE for a cleaning step.
17:31:55 <rpioso> I vote for an RFE. I'm interested in helping with it.
17:32:06 <rloo> so clarification in the rfe itself, no spec required.
17:32:10 <JayF> +1
17:32:53 <rloo> we good with that then?
17:33:00 <dtantsur> as usual, I vote for more drivers to support the same thing, but I'm fine with RFE
17:33:09 <rloo> moving on...
17:33:12 <rloo> https://bugs.launchpad.net/ironic/+bug/1640546
17:33:12 <openstack> Launchpad bug 1640546 in Ironic "[RFE] Sub-endpoints of ironic resources should be considered subcontrollers, not fields of the resource" [Wishlist,New] - Assigned to Vladyslav Drok (vdrok)
17:33:34 <dtantsur> sounds like a refactoring/bug, not RFE
17:33:43 <jroll> this feels like another pecan bug to me
17:33:49 <vdrok> hm, I don't remember making it an rfe :)
17:34:02 <vdrok> oh yes, I did, sorry
17:34:12 <rloo> vdrok: i added 'rfe' cuz you tagged it as an rfe.
17:34:23 <rloo> it is going to require a microversion bump
17:34:33 <vdrok> yup
17:34:47 <mariojv> that seems straightforward enough not to require a spec, even though it changes api behavior
17:34:47 <rloo> i am fine if it is a bug. i can't remember if an rfe is needed for a microversion bump
17:34:51 <rpioso> dtantsur: I agree re: more drivers to support BIOS thing.
17:35:03 <jroll> I almost wonder if we should just leave it if we're going to want a microversion bump
17:35:20 <jroll> I would argue like crazy against this behavior if it was new
17:35:28 <jroll> but now that it's there I'm not sure I see a benefit in removing it
17:35:46 <mariojv> maybe a microversion bump is warranted even though it's just changing error-like behavior.... in case clients rely on the 400
17:35:47 <JayF> I only want a microversion bump because it's a significant-enough change in behavior to break some clients imo
17:35:53 <mariojv> +1 JayF
17:35:57 <JayF> mariojv exactly
17:36:01 <dtantsur> yes, if we do it, we need a version bump
17:36:06 <dtantsur> the question is: should we?
17:36:19 <jroll> I don't think we should, but could be convinced otherwise
17:36:30 <mariojv> i think we should
17:36:36 <mariojv> 400 is for syntax errors generally, right?
17:36:58 <sambetts> I'm +1 to fixing our API endpoints
17:37:00 <rloo> does it matter either way? it is a bug so seems like we should fix it.
17:37:11 <mariojv> #link https://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error
17:37:12 <vdrok> the only inconvenience it brings is - some subendpoints return 404, some 400
17:37:21 <jroll> oh wait
17:37:22 <rloo> just not a high priority thing though
17:37:31 <mariojv> +1 to not high priority
17:37:33 <jroll> is this only fixing the status code?
17:37:50 <jroll> sorry, I thought this was also about making /nodes/foo/driver_info not succeed
17:37:55 <vdrok> jroll: about removing possibility too :)
17:38:01 <jroll> if this is only s/400/404/ I'm good with it
17:38:06 <jroll> not good with the other bits
17:38:12 <mariojv> oh, i did not know that vdrok
17:38:17 <jroll> I don't see a real benefit to that
17:38:28 <mariojv> i agree with jroll in that case. i just think the status code should change
17:38:35 <vdrok> OK, I'll remove the last paragraph theb
17:38:37 <vdrok> then
17:39:09 <jroll> well, remove part of it :)
17:39:16 <jroll> idk, what do other people think?
17:39:26 <sambetts> jroll: its about fixing our REST api to be more consistent, how do you tell the difference between a subresource and a field on the node? e.g. nodes/node-0/ports vs /nodes/node-0/driver_info
17:39:47 <sambetts> I'm personally +1 to only allowing subcontrollers/resources in the URL
17:39:58 * JayF does not have strong opinions on api semantics
17:40:00 <jroll> yeah, consistency is good
17:40:07 <sambetts> fields should be accessed using GET /nodes/node-0?field=
17:40:08 * jroll waffles some more
17:40:15 <jroll> is that also a thing?
17:40:23 <sambetts> fields*
17:40:25 <sambetts> yeah
17:40:28 <jroll> ಠ_ಠ
17:40:41 <vdrok> yes, a list can be specified there too
17:40:46 <jroll> oh right, that
17:41:21 <jroll> maybe it's fine, why not
17:41:26 <vdrok> sambetts: different links returned in response?
17:41:28 * jroll is not decisive today
17:41:40 <vdrok> this way we can distinguish subresource or just a field
17:41:56 <mariojv> in either case, neither of those should require a spec, right?
17:42:17 <TheJulia> This seems more than something that can just be masked with a micro version... and to qariojv's point, it needs a spec.
17:42:17 <mariojv> i think we were originally trying to decide spec / no spec
17:42:38 * sambetts wonders if we should include this sort of thing in the API reworking that devananda was working on and talked about at the summit
17:42:48 <TheJulia> sambetts: I'm kind of wondering the same
17:42:56 <jroll> yeah, let's have a short spec on this
17:42:56 <mariojv> TheJulia: so you think the removal of /node-0/<field> should require a spec, but status code should not?
17:42:56 <sambetts> we should cover all the endpoints for nodes/ports/portgroups
17:43:05 <mariojv> sambetts: +1, then it could be done all at once
17:43:08 <jroll> this would just be adding to the list of api things to do
17:43:22 <jroll> I'd also be fine with a 'fix all the subresource junk' spec
17:43:24 <galyna1> sambetts, +1 about API. It may touch etags
17:43:43 <TheJulia> mariojv: if we're starting to change the overall behavior of the api, I worry we would have to maintain backwards compatibility, which means we will just end up with quite a headache.
17:43:45 <mariojv> yeah, if there are more changes than this required for subresource fixing, then a spec would be good
17:44:00 <rloo> i don't see that it matters if it falls under the 'api reworking'. it still needs to be described and it looks to me that folks want a spec.
17:44:01 <mariojv> TheJulia: oh, true... gotta leave in some code to respect the lower versions
17:44:05 <jroll> rloo: +1
17:44:29 <rloo> are we good with asking for a spec? any nays?
17:44:37 <TheJulia> no nay here.
17:44:42 <jroll> yay from me
17:44:45 <vdrok> OK, will bring rfe things back
17:44:48 <jlvillal> sambetts: Yeah on the API reworking. It would be good to eliminate the overloading of fields/node_names.
17:44:54 <NobodyCam> sounds like we want one
17:45:10 <mariojv> yay, given there's additional work and we've been discussing for quite a while - RFEs should be easier to discuss
17:45:16 <vdrok> thanks for the feedback
17:45:19 <rloo> ok, a spec it is. thx!
17:45:23 <rloo> and last but not least
17:45:25 <rloo> https://bugs.launchpad.net/ironic/+bug/1641857
17:45:25 <openstack> Launchpad bug 1641857 in Ironic "[RFE] Allow IPA to perform disk erase using thirdparty storage controller" [Wishlist,New]
17:45:30 <rloo> JayF:  will like this one
17:45:37 <jroll> oh yes
17:45:59 <JayF> I am not only not in favor of approving the RFE
17:46:00 <mariojv> how is this not just a different priority clean step?
17:46:02 <jroll> I agree with JayF's last comment on this
17:46:04 <JayF> I am -2 to the feature being in-tree
17:46:22 <dtantsur> I remember what JayF said when discussion this feature the other day, and I'm with him on it
17:46:45 <rloo> did any of you get any good reasons for that rfe?
17:46:53 <jroll> no
17:47:08 <rloo> jroll: ok. then not approved.
17:47:11 <mariojv> the concern is mainly proprietary tooling, right?
17:47:21 <mariojv> i agree, should not be in-tree
17:47:43 <JayF> Well it's basically two in-treee options for this, both are unsavory:
17:48:10 <JayF> 1) Add $proprietary_tool to methods we use to detect block devices, so we can see the storage controller disks and wipe them
17:48:39 <JayF> 2) add a new *upstream* cleaning step of "erase_controller_disks" or similar which would noop in Generic (not sensible -- why would we ship a noop step?)
17:48:46 * dtantsur does not get why an out-of-tree hardware manager cannot Just Do It (tm)
17:48:52 <JayF> 3) Add a 3rd party HWM step that can detect+erase these devices
17:49:01 <mariojv> yeah, 3 sounds much better
17:49:02 <JayF> #3 is the sanest solution, and doesn't require any in-tree work for IPA
17:49:07 <mariojv> yup
17:49:30 <mariojv> so, perhaps just reject and link to the meeting notes here
17:49:45 <jroll> +1 reject
17:49:47 <JayF> Is there anyone here who wants to fight for that RFE? So far we have two core votes to reject the RFE
17:49:49 <JayF> make that 3
17:49:56 <jlvillal> I also vote for #3.
17:50:07 <jlvillal> And also for reject of RFE.
17:50:39 <rloo> let's reject. they can come back if they have a good reason but so far, there doesn't seem to be one.
17:50:53 <rloo> i'm done. thanks all. over to you jroll.
17:50:59 <jroll> thanks
17:51:03 <jroll> #topic open discussion
17:51:05 <jroll> anything?
17:51:06 <JayF> I do wanna send kudos to those folks who have been adding third party managers in-tree to IPA
17:51:14 <rloo> (and yeah, i'll update the rfe's with what we discussed in this meeting)
17:51:14 <JayF> we have one in-tree now and another up for review
17:51:26 <xhku> yes
17:51:30 <xhku> For testing the SNMP driver in CI, lindycoder and I have a change in progress https://review.openstack.org/#/c/388154/.
17:51:35 <xhku> Once we land that, we will move the experimental gate (gate-tempest-dsvm-ironic-ipa-partition-pxe_snmp-tinyipa-ubuntu-xenial-nv) to a non-voting gate to be sure it's stable before making it voting.
17:51:43 <xhku> Does everyone agree with the way it's done ? We would like to land this this week, if nobody disagree, to begin the un-deprecation of snmp driver.
17:52:11 <jroll> yeah, it seems fine to me
17:52:22 <JayF> Should we, at this point, go ahead and un-deprecate teh snmp drive?
17:52:24 <JayF> *driver?
17:52:28 <JayF> Given CI is in progress
17:52:28 <srobert> +1 :-)
17:52:36 <JayF> or should we wait the few weeks until the CI is running?
17:52:41 <dtantsur> xhku, I agree with vsaienk0's comment, but I do realize it may require non-trivial refactoring of our devstack scripts, so I'd just let this in
17:52:53 <galyna1> Btw, I d ask to review the spec for Etags  https://review.openstack.org/#/c/381991/
17:52:55 <dtantsur> JayF, ++ for wait, we do have time before we start removing drivers
17:52:57 <NobodyCam> JayF: I would say wait for CI
17:52:59 <vdrok> yeah, having it as out of tree plugin would be good
17:53:05 <mariojv> i vote to wait, otherwise something could break it before CI is merged
17:53:10 <JayF> dtantsur: NobodyCam: the only reason I say we should maybe go ahead and do it
17:53:19 <JayF> is there are a number of very minor SNMP patches that people want
17:53:22 <JayF> i.e. support for new PDUs
17:53:34 <rloo> JayF: I htink we have to +A https://review.openstack.org/#/c/388154/ first. and wait -- how long?
17:53:35 <JayF> that wouldn't be tested in the gate anyway, but are blocked right now for, honestly at this point, probably no reason
17:53:39 <dtantsur> JayF, we should not land patches before they're covered by CI, right?
17:53:54 <JayF> In case of the SNMP driver, we do have some "mappings" of SNMP mibs to actions
17:53:54 <NobodyCam> dtantsur: +
17:53:54 <mariojv> JayF: those could still break SNMP in general, theoretically
17:53:56 <dtantsur> I mean, I dunno if an innocent change may actually break the whole driver
17:54:00 <JayF> that are for individual pieces of hardware
17:54:02 <xhku> dtantsur: For now we did it the same way vbmc does, I agree it could be moved to virtualpdu project. We could do both at the same time in a separate patchset ?
17:54:20 <JayF> that I don't think the virtualpdu testing would expose breakage for, unless somehow it magically breaks the whole driver which doesn't make sense
17:54:24 <dtantsur> xhku, I suggest we land the change as it is, and then we think how to split this code cleanly
17:54:34 <JayF> I'm just mainly tired of -2'ing small, non-dangerous patches just because "SNMP is deprecated"
17:54:50 <dtantsur> JayF, I get your point.. but I also don't want to guess each time if the change may break something or not
17:55:00 <mariojv> +1 dtantsur
17:55:06 <NobodyCam> How far off is the CI
17:55:08 <dtantsur> I feel much safer when I see a green CI run
17:55:17 <jroll> let's get non-voting CI and go from there
17:55:24 <mariojv> NobodyCam: a few weeks
17:55:42 <jroll> nah, I think we can get it this week or next if we review the patches xhku mentioned
17:55:48 <lindycoder> NobodyCam, the job is already ready in experimental
17:56:18 <mariojv> why don't we add xhku's patches to the priority ones listed in the etherpad?
17:56:33 <mariojv> then we can be more optimistic about when it will be merged
17:56:35 * dtantsur just reviews the patch in question ~ now
17:56:53 <jroll> mariojv: it isn't a high priority, though, really :)
17:56:58 <jroll> too much to do this cycle
17:57:09 <mariojv> fair enough. i'll just add it to my review list
17:57:20 <galyna1> For the Etags, by the way, the patches- POC are up and need unittests, for now I am blocked by spec review :(
17:57:27 <jroll> 2.5 minute time check btw
17:57:38 <jroll> galyna1: awesome, that should be a fairly simple review
17:58:20 <galyna1> jroll, thanks :)
17:58:51 <jroll> if there's nothing else, let's get one minute back :)
17:58:53 <NobodyCam> thank you everyone.. Great meeting!
17:58:55 <jroll> thanks everyone
17:58:58 <jroll> #endmeeting