17:00:18 #startmeeting ironic 17:00:19 Meeting started Mon Dec 11 17:00:18 2017 UTC and is due to finish in 60 minutes. The chair is dtantsur. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:20 \o 17:00:22 o/ 17:00:23 The meeting name has been set to 'ironic' 17:00:24 \o 17:00:25 o/ 17:00:27 o/ 17:00:32 o/ 17:00:33 hi all (again) :) 17:00:35 o/ 17:00:42 o/ 17:00:44 \o 17:00:49 o/ 17:00:51 o/ 17:00:57 #link https://wiki.openstack.org/wiki/Meetings/Ironic 17:01:11 o/ 17:01:37 okay, looks like enough people remember that our meeting is here now :D 17:01:37 o/ 17:02:15 #topic Announcements / Reminder 17:02:25 #info Tempest plugin migration THIS WEEK Mon - Wed 17:03:00 anything else? 17:03:00 dtantsur: so the inspector patches are failing in stable/pike? do they need to work first before migration? 17:03:14 ironic jobs seem to be working 17:03:24 Good question. Does inspector use the ironic tempest code? 17:03:27 I guess we should work it out in parallel.. 17:03:30 yes, it does 17:03:44 my main concern is that if we delay the migration again, it will slip to mid-Jan 17:03:51 which is a bit too late to destabilize the gate 17:04:07 i guess we also have to get the multinode/nova patch fixed too, before migration? 17:04:11 Okay. Not sure if we want to discuss now (annoucement section) or later... 17:04:12 we can discuss after meeting 17:04:30 rloo: totally, it has 1x +2 already 17:04:39 maybe for open discussion.. 17:04:46 anything else to remind/announce/...? 17:05:50 #topic Review action items from previous meeting 17:06:03 #link http://eavesdrop.openstack.org/meetings/ironic/2017/ironic.2017-12-04-17.00.html 17:06:20 we only have bug triaging effort by etingof and milan_, how did it go? :) 17:06:32 dtantsur, 2 bus 17:06:38 updated the ether pad 17:06:49 I think both are good to implement 17:06:57 * milan_ hopes nothing missed 17:07:20 cool 17:07:52 #topic Review subteam status reports 17:08:06 #link https://etherpad.openstack.org/p/IronicWhiteBoard line 148 17:09:10 dtantsur: remind me, are we trying to get the nova changes for version negotiation done, in queens? 17:09:31 rloo: ideally, because we bumped the hardcoded version again 17:10:13 dtantsur: ok, cuz i think the nova feature freeze is late Jan. is it a nova bug or feature? 17:10:36 rloo: it would be a bug realistically 17:10:40 I see it more as a bug 17:11:19 dtantsur: let us know when you might want reviews on whatever then. i don't remember how/when the deadline is for bugs 17:11:28 never? :) 17:11:36 might be good to verify with nova. that it is a bug... 17:11:53 the only problem with this "bug" is that it'll require an ironicclient version bump 17:11:56 dtantsur: well, for critical, high. but others, who knows.. 17:11:58 did we file a bug with nova? (or a blueprint?) 17:11:59 so it cannot go to a stable branch 17:12:13 jroll: not that I'm aware of. TheJulia? 17:12:31 that's the first step, I seriously doubt nova takes that change without something in LP 17:12:45 would be good to make sure ironic & nova are on the same something on this... 17:12:49 jroll: it is more along the lines of "Hey ,you guys are shooting yourselves in the foot, please fix this" 17:13:09 still, they will want a bug or something. i suspect. 17:13:12 sure. I stand by what I said :) 17:13:16 and really, the whole idea would have been to do it when we bumped a microversion in our virt driver code 17:13:22 just needs to be written down / communicated 17:13:29 this has been contentious before 17:13:34 TheJulia: I guess we can fix the configdrive thing that merged this cycle 17:13:40 (i.e. we tried to do this once already) 17:13:57 jroll: yeah, things change though 17:14:04 dtantsur: That might be a feature then 17:14:21 TheJulia: agree. still 99% sure it needs something in LP, that's all I'm saying 17:14:30 "Fixes compatibility with pre-Queens Ironic" ;) <-- see, a bug fix! 17:14:32 is there an action item here? :) 17:14:37 which will quickly answer the bug/feature question 17:14:57 I can take an action of getting a bug and showing it to folks 17:15:09 #action dtantsur to create a bug against nova for not hardcoding ironic API version 17:15:12 something like ^^ 17:15:18 yay, candidate #1. dtantsur! thx! 17:15:21 I feel like there is actually a bug someplace already, but I don't remember exactly 17:15:37 TheJulia: please throw it my direction if you find it 17:16:40 * rajinir joined 17:16:55 dtantsur: I'll try to take a look later today, but no promises 17:17:07 thnx 17:17:08 mgoddard, johnthetubaguy: any updated status related to traits work? 17:17:58 jroll likes traits, let's make him finish it :D 17:17:59 hi rloo, john is unlikely to be joining, as he has a new human to look after 17:18:06 \o/ 17:18:13 >.> 17:18:21 mgoddard: yay! 17:18:23 jroll: fyi we almost were blocked last cycle on the microversion bump because they wanted to see it more graceful then. We ended up shooting ourselves in the foot with the microversion pin due to grenade testing where they made some major changes, and nova-compute was failing to operate upon restart since ironic had not been updated yet 17:18:26 :) 17:18:27 mgoddard: are you planning on taking over? 17:18:33 I've not done any work on traits and John didn't mention having done any before he left 17:18:54 mgoddard: ok 17:19:01 dtantsur: I know you're joking, but not sure I have time to pick up big things yet. would like to pick it up if I can find time but no promises 17:19:17 no problem man, I was joking indeed :) 17:19:23 I can pick it up, but not in Dec 17:19:25 It's not currently lined up for me but I'm aware it is slipping so I'll talk to stig and see if I can get some time for it 17:19:34 hmmmm 17:20:00 hey 17:20:31 is inspection_dhcp_wait_timeout still a working kernel param during introspection? :x 17:20:37 TheJulia: gotcha 17:20:48 Grenth: it should look differently, but we have a meeting here right now :) 17:20:55 please wait some more time 17:21:08 alright! sorry for bothering... 17:22:36 I keep retyping thoughts on the traits stuff, I'm not sure we have much of a choice other than just getting it done asap 17:22:54 yep, I'd not delay it forever 17:23:02 if not Queens, then early Rocky at the latest 17:23:10 TheJulia: i think we'd like the basic node traits in Queen's, right? 17:23:36 yes 17:23:37 well, when exactly is nova planning on removing processing of properties? 17:23:45 for scheduling purposes? 17:24:00 jaypipes: up for a quick question ^^^? 17:24:01 i don't think they've announced that. 17:24:14 I understood it to be Rocky timeframe 17:24:22 but, I don't think I've heard anything official either 17:24:25 I suspect it's waiting on us 17:24:53 i thought there was a comment in the traits spec, from tubafather, about that not going away until ... i forgot what. 17:25:06 TheJulia: yeah, Rocky is when the ComputeCapabilitiesFilter will be replaced with the traits processing in placement API. 17:25:18 thanks jaypipes 17:25:23 no problemo. 17:25:31 so we have a hard deadline of Rocky. I'd prefer the bits to be in place a bit earlier though.. 17:25:45 yup. 17:26:15 So basically we need client api and rest api and storage done by what, week of January 22nd? 17:26:24 the node traits bit should be 'easy', just a matter of coding :) 17:26:34 TheJulia: ideally, yes 17:26:53 I think this just became the top priority 17:27:01 because otherwise, we're not going tbe bale to deliver it 17:27:17 to be able, silly browser locking up for a moment 17:27:18 I'm all for it, if we find someone with free time to work on it 17:27:22 ok, I've just got the go ahead for some time on traits 17:27:31 nice! mgoddard++ 17:27:36 mgoddard to the rescue! thx! :) 17:27:45 should we vote on making this an essentialy priority for the cycle? 17:27:51 * dtantsur knows rloo likes voting 17:28:15 it is definitely high, is it essential? 17:28:43 it's already high, but I think TheJulia means it's essential 17:28:46 well, yeah, i suppose it is essential. 17:28:48 without it, things are likely goign to be a very hard breaking upgrade if someone goes to queens -> rocky 17:28:52 +1 17:28:57 if they really are going to change filters in rocky. 17:29:08 (let's bet on whether the nova change happens in rocky... just joking) 17:29:12 ok, essential... 17:29:20 let's vote cuz i love that 17:29:22 Hugo Nicodemos proposed openstack/ironic master: Introduce hpOneView and ilorest to OneView https://review.openstack.org/523943 17:29:48 #startvote Should we raise the priority of the traits for to essential? Yes, No 17:29:49 Begin voting on: Should we raise the priority of the traits for to essential? Valid vote options are Yes, No. 17:29:50 Vote using '#vote OPTION'. Only your last vote counts. 17:29:55 #vote yes 17:30:00 #vote yes 17:30:02 #vote yes 17:30:02 #vote yes 17:30:03 #vote yes 17:30:13 mgoddard: fwiw I should be able to help with reviews on this, if not code 17:30:17 feel free to ping 17:30:22 #vote yes 17:30:28 #vote yes 17:30:34 * dtantsur will review as well, me likes API additions :) 17:30:47 jroll: fantastic, thanks 17:31:11 any more votes? 17:31:22 c'mon, somebody vote no just for fun :D 17:31:25 #vote yes 17:31:29 ;) 17:31:41 #vote maybe (for dtantsur) 17:31:41 okay, okay 17:31:41 NobodyCam: maybe (for dtantsur) is not a valid option. Valid options are Yes, No. 17:31:48 lol 17:31:51 lol 17:31:53 :) 17:31:57 #vote yes 17:31:57 #vote no cuz I'm not convinced nova will actually make the switch in rocky 17:31:58 rloo: no cuz I'm not convinced nova will actually make the switch in rocky is not a valid option. Valid options are Yes, No. 17:32:08 i tried :) 17:32:11 that bot is picky :D 17:32:13 anyway 17:32:13 heh 17:32:16 #endvote 17:32:17 Voted on "Should we raise the priority of the traits for to essential?" Results are 17:32:18 Yes (9): TheJulia, vdrok, rloo, jlvillal, jroll, Nisha_Agarwal, etingof, dtantsur, sambetts 17:32:32 #agreed The traits work priority is raised from High to Essential 17:32:40 finished with the statuses now? 17:32:55 +1 finished, that was stressful... :) 17:33:16 it should be, it's hard work! 17:33:24 #topic Deciding on priorities for the coming week 17:33:30 let's see where we are 17:33:43 #link https://etherpad.openstack.org/p/IronicWhiteBoard line 109 17:34:03 the tempest migration. do the rest of us need to do anything or it is in jlvillal and dtantsur ballcourt? 17:34:18 rloo: review things when needed 17:34:25 rloo, Well the inspector stuff needs to get fixed. 17:34:31 esp. since only you, TheJulia and me have core on stable branches 17:34:42 ok 17:34:45 I will work on the new tempest plugin repository when I get the word. 17:35:08 i don't see any changes to what's there for priorities then 17:35:25 but next week, i hope to see traits patches :) 17:35:37 I'm about to block any patches changing the tempest plugin after this meeting 17:35:52 dtantsur: thx 17:35:54 so, how's the list looking? no new additions, except for the split 17:36:31 stepping outside 17:36:47 dtantsur: i think it is good 17:37:02 we need a vote each time :D 17:37:07 * dtantsur is kidding, as usual 17:37:10 yay, more votes! 17:37:16 boo 17:37:20 moving on in 3.. 17:37:22 2.. 17:37:25 1.. 17:37:32 #topic Appointing a bug triaging lead for the coming week 17:37:41 who's up? 17:37:57 * dtantsur wants to appoint jroll :D but he's a kind PTL 17:38:05 crickets? :D 17:38:14 don't make me quit already, I just started! 17:38:17 lol 17:38:18 lol 17:38:27 * milan_ can take it again 17:38:33 jroll: you're stronger than that, you survived being a PTL for 2 cycles 17:38:36 thanks milan_ 17:38:37 I can also do it 17:38:43 #action milan_ to lead bug triaging again 17:38:46 mm 17:38:48 #undo 17:38:49 Removing item from minutes: #action milan_ to lead bug triaging again 17:38:55 #action milan_ and TheJulia to lead bug triaging again 17:39:00 \0/ :D 17:39:01 meh, "again" 17:39:07 okay, I won't fix it the 2nd time :) 17:39:14 lol 17:39:17 #topic Lets discuss a bug: Delete/Creation of ports on active nodes 17:39:24 #link https://bugs.launchpad.net/ironic/+bug/1736373 17:39:26 Launchpad bug 1736373 in Ironic "succeed to delete port and create port when node is active" [High,In progress] - Assigned to wangzhengwei (wangsansui) 17:39:28 TheJulia: the mic is yours 17:39:46 So I ran across this bug in launchpad ?friday? and I'm thinking we need to discuss it 17:40:18 specifically should we be allowing port deletion/creation when a node is in an active state 17:40:32 * TheJulia thoughts we had it blocked long ago, but couldn't remember 17:40:42 I read it as deletion is already allowed 17:40:46 but update is not 17:41:18 i think the bug is 'we currently allow create/delete of ports when a node is active; the bug is that we shouldn't 17:41:41 +1 I agree we shouldn't (unless in maintenance) 17:41:56 yeah, at least deleting should be forbidden 17:42:06 as an aside, i wonder what they were trying to update 17:42:14 given that it's a breaking change, it has to be at least microversioned.. 17:42:31 right I think that is the reason we never did it for delete/create 17:42:40 argh, love/hate microversion 17:42:49 because it only applies from a new microversion onwarfd 17:42:50 nova allows that on an instance? 17:43:09 milan_: nova operates on virtual interfaces, it's natural to create/delete them 17:43:29 most hardware still does not allow creating/deleting interfaces on demand, though we're moving there.. 17:43:32 nova allows attach/detach of neutron ports, but this is for ironic phyical devices which means someone physically added a new NIC card 17:43:40 that makes me wonder if this should depend on the network driver, since some hardware can do that thing, right? 17:43:47 * jroll looks at sam 17:43:54 My concern was the fact that we would have to guard it with a microversion, and I'm not sure we really want to do this at this point 17:43:54 true 17:43:55 * milan_ was just wondering, reconfiguring a switch might not be that hard to imagine 17:43:56 even if they can, doesn't it make sense to put a node in maintenance? 17:44:13 milan_: you're confusing VIF attach/detach with port creation/deletion 17:44:23 dtantsur: I have a case where on vif attach I'll want to create a port in Ironic (I think) 17:44:26 dtantsur, yeah maybe O:-) 17:44:55 sambetts: this is from inside of ironic, right? 17:45:01 not like an operator does it? 17:45:08 dtantsur: yeah from the inside 17:45:14 so not through the API 17:45:32 that's different in my opinion. from inside we can make sure it happens in the right way and with the right hardware 17:45:43 +1 I think that makes sense 17:45:54 what about portgroups 17:46:20 I would htink the vif would have to be detached, ports updated, or portgroup updated, then the vif reattached 17:46:24 in order to do it properly 17:46:25 deleting an active port/port group may make a VIF ID to be lost.. not sure how bad it is 17:46:44 dtantsur: they are stored on the portgroup, not on the port 17:46:46 I think we at least should not allow deleting ports with a VIF attached 17:46:50 TheJulia: on either 17:47:10 dtantsur: right but we can't block that on old API versions right? 17:47:12 depending on what entity a VIF is attached to 17:47:23 sambetts: well, it depends on how broken it is 17:47:23 dttrue, true for ports as well, I was just referring to only portgroups 17:47:40 yep 17:48:31 I think we can and should prevent deletion/update of attached ports/portgroups, even without a microversion 17:48:43 unless in maintenance 17:48:44 I'm not sure it's worth bothering with non-attached ones at all 17:48:54 well, yes. in maintenance you're free to screw up yourself :) 17:49:41 I can agree with this without microversion because it is kind of an edge case where someone is wanting to manipulate a node directly 17:50:29 10 minute warning 17:50:43 are we in agreement? do we want a ML thread? a vote? :) 17:50:54 yeah, I've just thought, do we block someone deleting a port/portgroup while a node is in deploying / other transition states? because that is a seriously breaking change because it might end up with different lists of ports at different point suring deployment 17:51:12 I hope we do... 17:51:18 I feel like we are in agreement, but now is the time for someone to speak up if we are not 17:51:35 maybe before we vote/decide, someone could go through and just verify when we allow what to ports/portgroups... 17:51:37 sambetts: we do not, but interestingly enough the patch also looks at the presence of an instance_uuid 17:51:43 s/patch/proposed patch/ 17:52:55 the instance uuid is only useful if using nova, or does bifrost also use that field? 17:53:34 rloo: it is settable via the ansible modules, it is not used, but bifrost's port support is extremely lacking right now, so I really wouldn't worry about it. It is on my todo list to update support for it all 17:53:42 a standalone deployment does not have to use instance_uuid 17:53:58 ^^^ that 17:54:07 so it makes me wonder about the submitted patch 17:54:29 it shouldn't be looking for presence of the instance uuid 17:54:46 yep 17:54:53 I agree it likely shount, it is an easy way to know if nova is touching the node, but we should be using a list of states 17:54:56 and it should be looking at attached VIF IMO 17:54:57 they are also specifically looking at state == active and blocking it, instead of what we do in port update which is allow if its in manageable/enroll or maintenance 17:55:04 dtantsur: ++ 17:55:23 so i think we need to decide/agree on behaviour. then look at how it is coded :) 17:55:29 submitted patch aside, bug it is, no microversion needed, all agreed? ;) 17:55:34 rloo,++ 17:55:40 * milan_ being productive :P 17:55:49 thx milan_ 17:56:05 I feel like we're kind of agreeing given the riskof a port being deleted while a vif is attached 17:56:15 if i understand, we are relaxing the restriction on 'no updates to ports and possibly portgroups' to allowing if not attached 17:56:33 this is a separate question :) we probably should, but I'm not sure 17:56:35 and we are restricting deletion of ports/portgroups, allowed only if not attached 17:56:41 or maintenance ^^ 17:56:48 and creation of port/portgroups? 17:56:55 rloo: more thought required! 17:56:59 we allow some port updates already, mac address works 17:57:11 can someone please port to openstack-operators/oepnstack-dev? 17:57:13 3 Minute warning 17:57:16 and let's get back to this topic next time 17:57:19 OUCH 17:57:22 so that goes back to it being useful for me to know what we allow for ports & portgroups, and when 17:57:31 #info dtantsur is very likely to be out next Monday (and the Monday after that) 17:57:35 forgot ^^^ 17:57:50 dtantsur: only monday? 17:57:57 rloo: yep, next week only Monday 17:58:06 then out of x-mas starting with 24th 17:58:09 s/of/for/ 17:58:11 TheJulia: you avail to chair next Monday? 17:58:16 rloo: I am 17:58:20 TheJulia: thx 17:58:36 i expect the dec 25 meeting to be cancelled 17:58:43 oh, and jan 1... 17:58:47 yup 17:58:52 Both fall on a monday 17:58:53 Agreed 17:59:05 Pavlo Shchelokovskyy proposed openstack/ironic master: Use adapters for neutronclient https://review.openstack.org/476170 17:59:06 Pavlo Shchelokovskyy proposed openstack/ironic master: Finalize migration to keystoneauth adapters https://review.openstack.org/478825 17:59:09 ok, end of year party next monday then :D 17:59:14 heh 17:59:15 #info TheJulia will chair the meeting on Dec 18th, the ones on Dec 25th and Jan 1st are cancelled 17:59:18 Well likely very little attendance from North America and Europe, I imagine 17:59:36 And probably South America too ;) 17:59:36 +1 17:59:40 anything else before we wrap up? 17:59:54 rloo, crickets ;) 17:59:59 nothing from me 17:59:59 And Oceania 18:00:02 #endmeeting