15:00:09 #startmeeting ironic 15:00:10 Meeting started Mon Jun 18 15:00:09 2018 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:14 rloo: agree 15:00:14 The meeting name has been set to 'ironic' 15:00:17 o/ everyone 15:00:23 already meeting time? :o 15:00:26 o/ 15:00:27 o/ 15:00:39 o/ 15:00:40 o/ 15:00:50 o/ 15:01:01 o/ 15:01:15 o/ 15:01:31 Our agenda looks rather quiet today. 15:01:33 #link https://wiki.openstack.org/wiki/Meetings/Ironic 15:01:39 Vladyslav Drok proposed openstack/ironic-specs master: Add synchronize-events-with-neutron spec https://review.openstack.org/343684 15:02:05 #topic Announcements/Reminders 15:02:10 o/ 15:02:26 o/ 15:02:50 Two things. The first is that I believe we're ?R-6? Which means we will need to finish up/polish up things for our release for this cycle relatively soon 15:03:21 o/ 15:03:43 The second... I'm on the road again this week departing tomorrow. I believe the total time shift for me will be 12 hours, so expect odd hour replies if you ping me 15:04:17 Does anyone have anything they would like to announce or remind us of? 15:04:26 did you/we do any releases last week? 15:04:43 * TheJulia looks at dtantsur 15:05:06 (or err are we planning any this week?) 15:05:52 Looks like we only cut queens releases last week 15:06:36 we did, but only queens 15:06:39 yes 15:06:53 ironic is blocked by https://review.openstack.org/575113 from my pov :) 15:06:54 patch 575113 - ironic - Remove the remaining fake drivers 15:07:09 I think that is a reasonable block 15:07:09 I can request releases after that 15:07:19 we also need someone to go over release notes, ideally not me 15:07:42 I can give it a try, but the whole information processing disorder can make that slightly difficult 15:07:57 Then again, I'll be on a plane for how many hours? 15:08:13 dtantsur: I'll try to do a pass on the renos tomorrow 15:08:20 great, thanks! 15:08:26 Anyway, we're at nearly 10 minutes and we should move on 15:09:10 #topic Review Action Items for prior week 15:09:12 #link http://eavesdrop.openstack.org/meetings/ironic/2018/ironic.2018-06-11-15.00.txt 15:09:32 Looks like the only one was for dtantsur for IPA python3 15:10:35 dtantsur: Any update? 15:10:52 nope, lost track of it, sorry 15:11:19 Okay, Are you going to try again for this week? 15:11:21 well, one thing I figured out is that we don't track Pike goals on SB 15:11:27 so we have to track it outselves? 15:11:45 pike goals? 15:12:08 python 3 was from pike, no? 15:12:09 the whiteboard has been what we've been using for the current cycle 15:12:12 oh! 15:12:33 uhh... it was tracked under changesets to the governance repo I believe 15:12:52 yep, but that's not visible for us too much 15:13:01 * dtantsur creates a story right now 15:13:05 ++ 15:13:05 okay 15:13:11 Anyway, moving along! 15:13:15 #topic Review subteam status reports 15:13:31 #link https://etherpad.openstack.org/p/IronicWhiteBoard 15:13:57 Status reports start at line 146 15:14:15 dtantsur: wrt the bugs/stats. what does 'fetching stories from board 83' mean? 15:14:33 rloo: exhaustive copy-paste, sorry 15:14:48 ehmm, excessive? 15:14:59 * dtantsur wonders why all words look so similar 15:15:23 the number of RFEs is catching up to the number of bugs... 15:16:14 i just updated the HIGH bug ... (L160). 15:16:21 #link https://storyboard.openstack.org/#!/story/2002598 IPA python 3 story 15:17:58 TheJulia: wrt nova-flexible-with-ironic-API-version. we need to do a client release first? 15:18:22 * dtantsur suspects yes 15:18:25 rloo: was that the take-away from the notes I added moments ago? 15:18:39 I can request a release once we have everything merged 15:19:04 TheJulia: well, it looks like all the client patches have merged, and it sez 'next logical step is to change nova'. which means it needs a client release, right? 15:19:12 As the rescue patch is presently, it does it non-invasively using what was released last cycle 15:19:19 but yes, we should go ahead and release the client 15:19:47 we have two possible paths we can take that end up in roughly the same place in the grand scheme of the universe. 15:20:09 * rloo confused. why did we make those client changes, if we don't need it for nova. 15:20:38 also confused - do we have a plan written down somewhere on that? 15:21:06 because we had pushback about not following or being able to follow api sig recommendations and doing explicit call level handling 15:21:17 the state of the rescue patch just graefully permits both 15:21:47 which is not ideal to land in nova, but it would reach the same basic result 15:22:21 but don't we want the 'ideal' thing to land in nova. 'ideal' == nova folks are happy with, and to be used as a model for future ironic features? 15:23:06 i haven't looked at nova's rescue patch though, so maybe i shouldn't ask w/o looking... 15:23:51 Ideally, to make everyone as happy as possible, we would do the ideal thing, it would also merge conflict with the rescue patch 15:24:49 Since it requires an API version bump, and the same areas of code will be impacted. I don't think this should prohibit us doing so and writing a nova patch to take the ideal route, but we need to be mindful of the rescue patch in all of that. 15:25:16 this is only going to be used by rescue at first, right? 15:25:24 yes 15:25:47 any reason not to just stack the patches then? 15:26:21 None really, someone just needs to do it 15:26:30 once we have a release that is 15:26:36 mel was pretty supportive of getting the versioning thing in, seems we should just agree with her on the right thing to do, line it up, and go 15:26:38 ok 15:27:20 jroll: yeah, The last time it was discussed in irc, she was pretty much along the same lines of even if it a list of versions, which is what the rescue patch does 15:27:22 currently 15:27:39 ok 15:27:49 we could stack the better way to do it on top of rescue 15:28:24 Yeah, likely would be best to do that that way we merge rescue first and if the version patch doesn't get reviews or land then we're still in a semi-happy place 15:29:02 Anyway, anything else for status updates? Or shall we go to priorities for the next week? 15:29:03 yep, it isn't critical to clean it up this cycle, could merge early in stein 15:29:14 jroll: ++ 15:30:17 dtantsur: i put your storyboard link at L301. We can delete that from the whiteboard before next meeting 15:30:48 #topic Priorities for the next week 15:30:55 * TheJulia cleans up the merged items from the list 15:31:21 rloo: it's also on line 295 15:31:24 dtantsur: oh wait, is that storyboard link only for the IPA python3 jobs? 15:31:39 rloo: well, it's the last remaining bit for python 3 IIRC 15:32:02 dtantsur: all the stuff below your TODO is included in the storyboard? 15:32:26 rloo: not swift, but that's not really an action item for us 15:32:26 does anyone care enough about the secure erase stuff besides myself for it to be a priority for htis week? 15:32:35 TheJulia: I guess we have to 15:32:44 bricking hard drives is not a great thing to do 15:32:48 is that the patch that i just reviewed? 15:32:55 just need to update the reno, right? 15:33:09 i don't care if you put as a priority, after you update, let me know and I'll review :) 15:34:09 rloo: yeah, that one 15:34:38 well, there are a total of four patches all mixed together, seems one of them breaks the gate that needs to be investigated 15:35:16 This seems reasonable to add for python-ironicclient (it is small) 15:35:16 TheJulia: oh, we need all 4 of them? Then yeah, guess it is a priority :) 15:35:17 https://review.openstack.org/#/c/508330/ 15:35:18 patch 508330 - python-ironicclient - Allow to use none auth in functional tests 15:35:28 TheJulia: as for Nova patches, maybe put the patch using "reserved" instead of 0 for inventory? 15:35:53 dtantsur: I'm not mentally aware of that one, got a link handy? 15:36:12 #link https://review.openstack.org/#/c/517921/ 15:36:13 patch 517921 - nova - ironic: Report resources as reserved when needed 15:37:08 Yeah, a few eyes would help for that one I think 15:37:23 Is anyone aware of anything else that must get some eyes this week? 15:37:25 I'll take a look at the failures and recheck if these are temporary issues 15:37:38 vdrok: thanks! 15:38:34 Well, I think the list looks decent if nobody has anyting else that needs to be added 15:39:31 Everyone good with the list for the week? 15:39:34 TheJulia: added a hidden dependency, otherwise LGTM 15:39:54 dtantsur: thanks! 15:40:26 +good 15:40:38 oh, great catch, thanks dtantsur 15:41:26 rloo: Are there any RFE's you wish to discuss today? 15:41:41 TheJulia: nope 15:41:45 okay 15:41:57 Anyone else with RFEs that they would like to discuss today? 15:42:18 Otherwise next stop is Open Discussion 15:42:51 people asked me if we could return 503 instead of 400 if no conductors are alive at all 15:43:06 currently we return "No conductor registered which supports driver " 15:43:14 which is technically correct, but can be misleading in this case 15:43:27 I've always kind of idly wondered the same 15:43:29 could we add logic to catch that, and double check? 15:43:29 the primary case is non-rolling upgrade 15:44:00 I can work on it if there are no objections (no RFE formally posted yet) 15:44:12 I'd treat it as a bugfix to be honest 15:44:12 looks like there are two cases. if there are conductors alive but none support the driver, then 400, if no conductors alive, then 503 15:44:35 rloo++ 15:44:42 and yeah, that seems more like a bug. regardless, i approve :) 15:44:42 TheJulia: bugfix with a microversion? ;) 15:45:00 dtantsur: It is prefectly acceptable to have a bugfix force a microversion increment 15:45:26 I guess the real question is: should we hide the change behind a microversion? 15:45:49 or should we fix all versions? 15:45:52 dtantsur: while we're at it, I wonder if the error should be "No conductor registered which supports driver for this node" or "for node foo". that message has always seemed confusing to me if you aren't interacting with a driver resource 15:45:59 i think we have to. cuz folks might have scripts looking for 400 for those cases. 15:46:02 I'm fairly sure, to address where this error is encountered today in nova, we would need to patch nova regardless 15:46:18 nova? 15:46:20 so a microversion, in my mind seems cleaner 15:46:21 rloo: well, we can return 503 already from any call involving conductor 15:46:32 at least any async call 15:46:39 because of "no free conductor threads" 15:46:53 jroll: the specific case was restart of nova-compute w/o any conductors running.... and nova-compute trying to restand-up networking with no conductors, and thinking everything is broken 15:46:53 dtantsur: true, but we don't know if anyone has some script looking for 400 and then doing something based on no conductors being alive. 15:46:56 I would prefer a microversion, I don't see much reason not to 15:47:07 jroll: nova tries to attach VIFs on nova-compute start-up 15:47:15 ok, thanks for the context 15:47:15 if it fails, it moves instances to ERROR 15:47:18 wait 15:47:20 on startup? 15:47:21 which is.. ugly :( 15:47:22 yup 15:47:23 wat 15:47:23 yep 15:47:28 waaaaaaat 15:47:34 * TheJulia hands jroll a beer 15:47:35 I guess I get it for virt, but... sigh 15:48:00 jroll: some ppl want to fix it and make driver-specific 15:48:01 * jroll accepts and returns the favor 15:48:05 but we have what we have 15:48:21 #topic Open Discussion 15:48:23 yes, this feels like a startup=True on plug_vifs or something 15:48:31 ++ 15:48:37 I do think the 503 thing would still be useful 15:48:52 jroll: long-read for background: https://bugzilla.redhat.com/show_bug.cgi?id=1590297 15:48:54 bugzilla.redhat.com bug 1590297 in openstack-ironic "[UPDATE][SCALE-UP] After update and scale up all origin node are in ERROR status" [Unspecified,New] - Assigned to rhos-maint 15:48:56 since we shouldn't be running that code at startup anyway 15:48:56 That was kind of what I was thinking when I was looking at the nova code earlier this morning 15:49:18 who knows what third party network drivers might break on if they "re-attach" vifs 15:49:51 I'm unaware of any third party network interfaces for ironic, but... yeah :\ 15:50:17 sam has one 15:50:31 :( 15:50:39 he can make NICs from thin air 15:50:48 Magical nics 15:51:11 *poof* 15:51:14 heh 15:51:31 So anything else for us to chat about this week? Anything for me to do on my flights this week? 15:51:40 anyway, I'd like the change to 503. it would be nice to microversion it. I think the nova thing shouldn't rely on that, but rather have some "startup" argument on whatever method does the thing 15:51:50 (I think it already has that, but maybe not at the driver layer) 15:52:12 * jroll has nothing, is still in greenfield land collecting todos for ironic to do wild secureboot things 15:52:59 jroll: is there any discussion upstream needed? I've not gotten to sending out anything from the summit yet 15:53:27 * dtantsur filed https://storyboard.openstack.org/#!/story/2002600 15:53:27 TheJulia: not yet - doing a POC thing outside of ironic, then I'll be working on how we would do it with ironic 15:53:45 jroll: ack 15:55:02 jroll: I wrote up a thing for opencit integration w/r/t attestation, that might also be useful, but it would be interesting to see what your perspective reaches at your scale and needs as opposed to what was created at intel w/r/t secure boot/attestation 15:55:35 TheJulia: cool, will let you know when I have a writeup of sorts. probably on the order of weeks 15:55:42 jroll: cool 15:55:55 Okay, we've got five minutes left, anyone have anything else to discuss? 15:56:38 * TheJulia hears crickets 15:56:44 * rloo thinks i hear crickets in the pouring rain 15:57:10 * TheJulia now hears a chorus of crickets 15:57:10 heh 15:57:21 Thanks everyone! 15:57:24 Have a wonderful week! 15:57:28 ++ thanks TheJulia 15:57:44 TheJulia: Safe travels 15:57:46 thanks TheJulia :) 15:57:47 #endmeeting