15:00:25 #startmeeting ironic 15:00:26 Meeting started Mon Jun 22 15:00:25 2020 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:28 Good morning everyone 15:00:29 o/ 15:00:29 o/ 15:00:30 o/ 15:00:30 The meeting name has been set to 'ironic' 15:00:31 o/ 15:00:34 \o 15:00:38 o/ 15:00:41 o/ 15:00:58 o/ 15:01:06 o/ 15:01:33 Our agenda can be found on the wiki, as always 15:01:35 #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting 15:02:21 I've noticed someone keeps putting in release countdown related stuff for openstack and I'm honestly feeling like it is a bit of noise for us. 15:02:43 If someone wants to talk to me about that, I would be happy to have that chat 15:02:46 Anyway! 15:02:48 #topic Announcements / Reminder 15:03:03 Someone apparently wishes us to know where we are in the release countdown. 15:03:10 was not me this time 15:03:15 TheJulia: that was me 15:03:28 what I do want to point out is that next week we need to do our first coordinated releases 15:03:33 I understand it's not important for us, ok 15:03:35 #info This week is R-16, Vitoria-2 milestone (which doesn't really apply to us), is July 30th 15:03:44 o/ 15:03:49 \o rloo 15:03:50 rpittau: ok 15:04:29 o/ 15:04:31 The cycle priorites change is still up in review, I believe we'll merge it today since it has had +2's for over a week now. 15:04:34 #link https://review.opendev.org/#/c/720100/ 15:04:35 patch 720100 - ironic-specs - Victoria Cycle Priorities - 9 patch sets 15:04:51 ++ 15:04:56 #info The partition discussion from last week generated some notes. 15:04:58 #link https://etherpad.opendev.org/p/ironic-disk-partitioning-2020 15:05:12 Does anyone have anything to remind us of this week? Anything to announce? 15:05:32 the opendev event next week? 15:05:40 Oh yes! 15:05:55 #link https://www.openstack.org/events/opendev-2020/opendev-schedule 15:06:01 #info The first virtual OpenDev event starts next week! 15:06:12 There is a topic for bare metal scaling on Wednesday 15:06:29 One _does_ need to register 15:06:58 #link https://www.openstack.org/events/opendev-2020/ 15:07:11 Anything else? 15:08:14 Shall we move on? 15:08:44 yes 15:08:58 #topic Review action items from previous meeting 15:09:17 We had one action item from last week, for dtantsur to go talk to the release team. Dmitry can you summarize that for us? 15:09:23 Kaifeng Wang proposed openstack/ironic-inspector master: Fix incorrect pxe-enabled was set during introspection https://review.opendev.org/737129 15:09:42 yep 15:10:06 The biggest outcome, they don't believe it's necessary for us to change the release model to 'independent' to achieve what we agreed on 15:10:25 They have been doing certain preparations in the release tooling to permit additional branches 15:10:51 We do need to update it again to accommodate the desire to use 'bugfix/X.Y' naming rather than the currently implemented 'stable/X.Y' 15:11:23 when you say it, do you mean the release tooling or the plan? 15:12:46 Well, both? 15:13:02 The current plan states stable/X.Y, there are pretty reasonable objections to doing it 15:13:25 objections with-in the openstack release model confines? 15:13:33 not to conflate the intentions between the traditional stable branches and we're going to add 15:13:46 it's less of a tooling or model problem, more of people expectations 15:14:07 from solely an openstack perspective I guess? 15:14:16 the new branches, per our plan, are not going to be such an LTS things 15:14:23 where as someone from the outside may be confused 15:14:34 This is true 15:15:05 a concern that ttx (?) voiced is that if we treat them similarly, there may be a confusion when some (minor) fixes are merged into stable/ branches, but not into bugfix/ branches 15:15:35 which is fine, but needs a clear delineation between the goals 15:15:49 a bugfix/ branch is not something you spend years consuming 15:15:56 like it is the case with stable/ branches now 15:16:06 it's just a way for us to produce bugfix (hence the name) releases 15:16:09 Okay, that makes sense and that will surely happen at some point no matter what we do 15:16:53 * dtantsur needs to amend the spec with this clarification 15:17:03 okay, sounds good. Thanks dtantsur! 15:17:26 Moving on! 15:17:30 #topic Review subteam status reports 15:17:39 #link https://etherpad.opendev.org/p/IronicWhiteBoard 15:17:49 Line 256 15:18:17 I do anticipate changing this up sometime this week for our next meeting based on the priorities document 15:22:16 dtantsur: w/r/t the deploy steps work, I saw your comment on interface compatability, and I left a comment regarding maybe posting a release note to current and prior branches so there is sufficient heads-up. 15:22:40 mmmm, I'll definitely add a note for master 15:22:56 not sure how to make a note on stable branches actionable 15:23:33 "Coming soon to the next release" would at least provide a heads up that the next release, if your inheriting internal interfaces, things may require additional work. 15:24:00 iurygregory: only two patches left \o/ At least Ironic side 15:24:26 TheJulia, yes 15:24:30 \o/ 15:24:56 I will probably need to rebase if we merge the autospec for the tests (I saw rpittau comment) 15:24:56 hjensas: Any update w/r/t the notifier? 15:25:46 derekh: We have a v6 job now, is the only thing we really need to do at this point is make it voting? 15:26:49 iurygregory: is the multinode grenade job still disliking us? 15:26:55 TheJulia: yup, I made it non voting, I havn't looked at its reliability but can check it out to see if it could be voting 15:27:05 derekh: Sounds good! 15:27:16 ack will do 15:28:03 TheJulia, yes =( 15:28:17 I think that is it, at least for me. Are we ready to move ahead to deciding priorites? 15:28:47 iurygregory: I think it would be worth to merge the autospec first, or rebase the patch on top of that, we're going to enforce autospec anyway 15:29:22 rpittau, yup (but since I didn't got any feedback on the patch I will wait before rebasing on top) 15:29:41 the multinode fails on the tests with "'Unable to complete operation on network 31ae582c-98fd-4b35-a03b-dbea589e8cee. There are one or more ports still in use on the network.'," =( 15:29:46 still trying to debug that 15:30:30 are we expecting the ports to be torn down immediately or are we retrying? 15:31:20 going to double check the way the test is done, because we run the same set of tests in the multinode job 15:31:23 and its fine 15:32:22 We already know neutron may take some time to tear down ports/networks 15:32:42 yeah 15:33:04 Are we good to proceed? 15:33:28 ++ 15:33:31 ++ 15:33:35 #topic Deciding on priorities for the coming week 15:33:40 #link https://etherpad.opendev.org/p/IronicWhiteBoard 15:33:52 Starting at line 123 15:33:57 * TheJulia removes merged items 15:34:56 Should we remove the oslo.privsep change for now? 15:36:11 yes 15:36:13 Verification of a change to openstack/ironic failed: Add function definition handling https://review.opendev.org/704488 15:36:14 Line 171-172 15:36:14 okay 15:36:27 this week Im working more on downstream 15:36:42 okay 15:37:00 Is there anything that we should add this week? 15:37:20 WSME patches seem good to try and move forward on 15:37:22 i have one: https://review.opendev.org/737129 15:37:23 patch 737129 - ironic-inspector - Fix incorrect pxe-enabled was set during introspec... - 4 patch sets 15:37:59 Added 15:38:06 thanks :) 15:39:26 Anything else? 15:39:35 I noticed a few more items were added to improvements 15:39:41 yep, added 2 fixes 15:40:00 Do we formally want to call them bug fixes? 15:40:21 I'm not sure if it matters too much 15:40:25 ok 15:40:39 well, things explicitly called bug fixes are easier to track to backport if needed 15:41:44 done 15:41:52 \o/ 15:42:02 Anything else? Are we good with the list? 15:42:08 Or shall we move on to take over the world? 15:42:33 take over the world \o/ 15:42:38 * kaifeng wants to take over machines by unified images 15:42:44 take over the world =D 15:43:11 kaifeng: unified images? how so? 15:43:58 I am expecting a pointer for uefi/bios compatible image :) 15:44:07 Ahh, yes 15:44:12 we can discuss in the open discussion 15:44:17 Okay 15:44:31 Moving on, since we don't have any explicit discussion items, I guess we'll stop by the Baremetal SIG 15:44:36 #topic Baremetal SIG 15:44:42 yes! 15:44:43 arne_wiebalck: news to report? :) 15:44:50 the white paper is submitted! 15:45:06 the foundation sends their thanks to all contributors! 15:45:14 \o/ 15:45:21 great job on the paper everyone! 15:45:33 That is great news! Thanks everyone! 15:45:34 I think it has turned out quite well in the end 15:45:39 Thanks! 15:45:57 That was it for the SIG I think[ 15:46:10 thx arne_wiebalck and everyone else for doing that! 15:46:14 nice :) 15:46:37 Awesome, Well then I believe our *checks notes* next section is Open Discussion since we have no items under RFE review. 15:46:46 TheJulia Do you have any cycles available to check out https://review.opendev.org/#/c/557051/? Added a few more tests based on your last feedback. 15:46:47 patch 557051 - networking-generic-switch - Support multiple links in link_local_information d... - 11 patch sets 15:46:53 #topic Open Discussion 15:46:59 jamesdenton: Awesome, thanks! 15:47:09 kaifeng: so unified images! 15:47:46 TheJulia arne_wiebalck if memory serves, it seems Arne is doing so already 15:47:55 https://techblog.web.cern.ch/techblog/post/bios_uefi_cloud_image/ 15:48:16 this is a post where we share what we do to have a single image 15:48:51 The thing is when I wrongly deploy a bios image to the uefi machine, it appears like a bmc issue since there is harddisk in the boot option 15:49:23 arne_wiebalck: many thanks! 15:49:43 s/there is/there is no/ 15:50:47 even with the single image we still need to make sure the boot node is correct, at least in our deployment 15:51:33 correct meaning, the node and the pxe infra need to agree (and Ironic is the mediator, kind of) 15:51:34 kaifeng: no hard disk option at all? 15:51:46 I guess it is looking for a UEFI partition? 15:51:49 so it can't boot in both mode? 15:52:14 TheJulia: yep, 17 boot devices but no hard disk, it seems uefi firmeware is quite smart 15:52:21 kaifeng: you mean after the installation? 15:52:36 kaifeng:... "impressive" 15:53:09 kaifeng: like, dump the BIOS/UEFI image and then it does not matter how the node boots? 15:53:12 arne_wiebalck: yes, it's technically possible for an image boot from bios or uefi after installation? 15:53:43 kaifeng: tbh, I never tried, but it is an interesting question 15:54:05 for sure this does not work with s/w RAID, since it installs only one bootloader 15:54:31 but for non s/w RAID, this should actually work, I don't see why not 15:54:35 arne_wiebalck: I thought so when I heard the unified image, but maybe I am thinkg it wrong, will take a look on the post first. 15:55:04 Merged openstack/ironic-specs master: Victoria Cycle Priorities https://review.opendev.org/720100 15:55:23 Well, do we have anything else to discuss this week? 15:55:27 kaifeng: it works for VMs, so it should work for BM as well, I just never tried to switch after installation 15:55:52 Merged openstack/ironic-python-agent-builder master: Run ensure-pip in the build/check jobs https://review.opendev.org/737264 15:56:08 arne_wiebalck: got it, i'll try and feedback if there is something new 15:56:17 kaifeng: +1, thanks! 15:57:18 Well, seems like we're winding down. Thanks everyone! 15:58:01 Thanks, TheJulia 15:58:11 #endmeeting