15:01:25 #startmeeting ironic 15:01:25 Meeting started Mon Jan 22 15:01:25 2024 UTC and is due to finish in 60 minutes. The chair is JayF. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:25 The meeting name has been set to 'ironic' 15:01:28 Good morning everyone o/ 15:01:31 o/ 15:01:46 o/ 15:01:49 o/ 15:01:51 o/ 15:01:56 #topic Announcement/Reminder 15:01:58 #info Standing reminder to review patches tagged ironic-week-prio and to hashtag any patches ready for review with ironic-week-prio: https://tinyurl.com/ironic-weekly-prio-dash 15:02:10 No action items from previous meeting; skipping that agenda item. 15:02:22 #topic Caracal Release Schedule 15:02:30 o/ 15:02:32 It is R-10, no notable deadlines, but 10 weeks left :) 15:02:40 #link https://releases.openstack.org/caracal/schedule.html 15:03:02 #topic Potential BM SIG/Ironic meetup at CERN around June 6, 2024 15:03:17 I will be at OpenInfra Days at CERN on June 6. 15:03:19 Is there a nice link with the info for ^^^? 15:03:23 So will a handful of other Ironic contributors 15:03:33 We are looking to see if there is enough interest to schedule a thing, likely on the 5th 15:03:49 If so, it'll become official likely this week or next (I just got my travel approved on Friday) 15:04:06 I'm interested in theory, but cannot commit until I figure out.. many things 15:04:16 I went looking last week, and it seems like not much has been published yet 15:04:41 There is almost zero details published about the OIF Days, and the BM SIG meetup is in the "Jay and others think it's a cool idea" stage 15:04:47 very interested too, it's quite close for me to get to Geneve 15:05:00 Once official, I can ask for budget (and consider if I can self-sponsor if I get a no (likely)) 15:05:06 but Arne asked me to check w/the community for general interest before we put too much effort into an Ironic meetup, specifically 15:05:11 likewise 15:05:51 I'm not even considering based on the prices I saw =( 15:05:57 :/ 15:06:23 So it sounds like "general interest but major logistical concerns" 15:06:31 I'll pass on the strong desire for more documentation about the OIF Days :) 15:07:06 I'm unsure I'll be able to, trying to bring some clarity to my schedule for the year but it is going slow 15:07:44 90% of my orgs travel planning is done a the top of the year, which makes it good for events with this timing, but less good if something pops up in late 2024 :) 15:07:52 Either way, I think this topic is exhausted? 15:08:49 #topic Review Ironic CI Status 15:08:58 I had a separate topic for this, but will bring it up now instead since it's mostly-resolved 15:09:05 Inspector docs jobs are broken on latest eventlet 15:09:20 is that for eventlet or because of the uc update? 15:09:25 it was removed from upper-constraints in requirements project due to minor breakages across openstack and it being late in the cycle 15:09:43 I am talking specifically about eventlet, other breakages (I assume someone tried pillow again based on backlog?) I don't know details about 15:10:11 but we will have to find some kind of solution in eventlet or sphinx autodoc to make things happy if we want to continue to be able to autodoc once we get new eventlet 15:10:19 ack 15:10:36 as of now, I'm working w/infra to get us experimental queue CI tempest/unit test/doc jobs that run against master eventlet so we can easily test 15:10:46 Comments about this or other things to note? 15:12:05 Moving on. 15:12:08 #topic Bug Deputy 15:12:15 Thanks to iurygregory for volunteering to be the bug deputy. 15:12:23 #info Summary: -11 bugs, -2 wishlist items, -2 new, -9 in progress, -1 critical, -2 high. 15:12:40 Any comments iurygregory? Anyone want to volunteer to pick it up for this week? 15:12:42 yw =) 15:13:05 I forgot to update today, seems like we got a new bug =) 15:13:28 zarro boogs found :D 15:13:30 I think I can handle this week considering the great job done by iurygregory :) 15:13:41 #action rpittau is the bug deputy for this week 15:14:06 tks rpittau =) 15:14:20 :) 15:14:37 #topic RFE Review 15:14:52 #link https://bugs.launchpad.net/ironic/+bug/2049913 15:15:01 dtantsur proposed this on Decomposing out-of-band inspection 15:15:43 Yeah. It's honestly somewhat less scary than it sounds :) 15:16:05 The tl;dr is that I want to move oob (!) inspection to the default path 15:16:35 so that we virtually always have access to MAC addresses or CPU architecture (at least as far as Redfish is concerned) 15:17:00 I think my biggest issue with the RFE is that the top line of what it's accomplishing is not super clear (in the bug ticket itself). Right now, we can only do IB or OOB inspection, not both or a combination(?) 15:17:12 * JayF suspects that this issue is based in his lack of inspection knowledge 15:18:46 I think part of it is filling in some of the information gaps to create a easier user experience 15:19:05 Well, an easier user experience *for redfish users* 15:19:09 some paramters we have logic built around is just no longer required 15:19:46 I think oob is already prior art in some other interfaces, fwiw, and IPMI is expected to have rough edges for those who continue to use it 15:19:54 * JayF notes there's almost no way he's a "no" to this RFE, but is just talking through it to understand more 15:20:56 my view is a bit biased because IPMI is going extinct in my world :) 15:21:06 Well that's part of why I'm asking the questions this way 15:21:11 JayF: we cannot officially do a combination of ib and oob 15:21:12 I know the Metal3 lens is redfish tinted :D 15:21:13 BUT 15:21:31 the inspector/agent interface actually is a hybrid interface - see my explanation in the RFE 15:21:35 somewhat similar, only the most die-hard IPMI fans seem to continue to do new deployments with it 15:22:15 we also need to keep in mind that for many consumers ironic today is what they deploy in a year 15:22:28 or two, so yeah 15:22:28 (does not apply to metal3, but we're indeed wearing fishy glasses) 15:23:14 Should we have an end goal (that this would be a step towards) of in-band inspection becoming "baked in" in a sense, too? 15:23:52 I'm not sure there is truly value to forcing it in process wise, but if we can get the data as part of other processes its not a big deal 15:24:05 I'm pondering that.. I guess there may be some sense into re-running oob inspection in some cases? Like, installing a new NIC? 15:24:44 Inspection has always been shaped a little differently than other things in-band, is all I'm thinking. If it could look more like other step-based flows, that'd be neat, but I suspect there are reasons I'm not thinking of that wouldn't be possible/desirable (even beyond the "not enough hours in the day). 15:26:10 Inspection is kinda step-based - the hooks are very similar - but only in terms of processing data 15:26:29 "not enough hours" is always a critical problem tbh 15:27:08 yeah 15:27:47 Either way, I think I'm OK with this. I'm a little skeptical about doing it without a spec, but I suspect the diff is smaller than I realize and my skepticism is just ... lack of knowledge about inspection moreso than any meaningful concern. 15:28:32 heh, I even wrote the RFE in rst format in case you ask for a spec :D 15:28:45 it won't match very well into the template though 15:29:53 Let me put it this way, if I'm an Ironic operator, I'm not sure I understand what that RFE is doing. 15:30:08 And maybe in a world where we primarily communicate about new features via docs and release notes that is OK? 15:30:48 I can write a spec. In this case, I agree that the proposal is not exactly obvious unless you (like me) have spent months pondering it 15:31:38 I am saying ^ that is the problem I would like solved, I don't care if it's a fresh para at the top of an RFE, a spec, or interpretive dance :D 15:31:51 *paragraph 15:32:15 but unless there are objections I am A-OK with approving it since I trust you to do that :D 15:32:48 So folks, to spec or not to spec? :) 15:33:01 spec might be good, tbh 15:33:08 Alright, spec it is. 15:33:15 either way honestly 15:33:17 I kind of understand what your going after though, so I'm a bit easier to convince 15:33:20 Okay, I'll do it. The RFE text is half of the spec already. 15:33:26 I'd say like, a thin spec :) 15:33:44 Many None or N/A lines :) 15:33:52 oh yeah :D 15:33:57 #agreed https://bugs.launchpad.net/ironic/+bug/2049913 needs to have a spec 15:34:11 #topic Open Discussion 15:34:15 I have one thing for here to start 15:34:17 blockdiag! 15:34:43 Bauzas made a suggestion in #openstack-nova I think we should execute on: https://bugs.launchpad.net/tacker/+bug/2026345/comments/11 15:34:46 yeah, we need to burn it down with seqdiag 15:35:11 unless there are moving parts I'm not aware of 15:35:17 One item in my mind is the priorities for the cycle, I suspect some of the items we put on there haven't made progress, or might be a review away. Others just haven't been started. We should likely revisit/discuss explicitly 15:35:28 that suggestion may work for blockdiag, but not sure about seqdiag 15:35:28 I mean we could svg too for sequence diagrams 15:36:32 I can put something together with plantuml in the next week, but we can even remove entirely the dependencies and just use pure images 15:36:32 Some of the sequenec diagrams seem overkill at this point for our documentation 15:36:44 *or* haven't changed/updated/evolved in *ages* 15:37:02 which makes me wonder "is it really needed" and "does it continue to bring value" 15:37:04 And/or are less useful. 15:37:06 the other solution would be remove the sequence diagrams and convert blockdiag to graphviz 15:37:20 which is what other projects are doing 15:37:28 The seqdiag is my favorite, but I know many other folks don't like them and it's outta date 15:37:34 so I don't object if we wanna pull them 15:38:04 I'm thinking the ilo docs used to have tons of them, and it *really* wasn't needed in the end because it was painting a picture beyond the driver interface 15:38:34 most of the seq diags are in the ilo docs indeed 15:38:36 we have a good one for agent deploy flow 15:38:44 that's outdated but can be useful 15:39:07 I still use that when onboarding folks to how IPA works; but that's the only diagram in our docs I've used in years outside of the state machine 15:39:22 and like I said, it's significantly bitrotted and so I'm still +1 to dumping it 15:40:49 If any diagrams can still help newcomers, can we try to update them instead of removing them? 15:41:06 I think this is a thing we need to look at on a case by case basis 15:41:15 I'd rephrase that to a question pointed at you; you have recently been a newcomer: what diagrams have helped you? 15:41:18 and discussing it to a conclusion during a meeting might not be viable 15:41:21 And that can be a good input to the discussion. 15:41:42 The state machine so far :D I havent looked at the IPA diagram you mentioned though 15:42:06 Perhaps all the diagrams cant be discussed in the meeting alone, like Julia said 15:42:14 https://docs.openstack.org/ironic/latest/admin/drivers/ilo.html#id6 :) 15:42:16 ++ I agree, but we will need to take action at some point 15:42:31 yeah, losing the state machine will be undesirable 15:43:18 masghar: that's not seqdiag though, it's a png 15:43:51 or I'm confusing the file :) 15:43:51 state machine has to be regenerated when we make changes (which is *often* also forgotten) 15:43:59 Ah, so only the seqdiag ones are in consideration? 15:44:10 for the migration yes 15:44:23 rpittau: okay 15:44:25 TheJulia: is that code for "nobody check it for SERVICING" 15:44:58 JayF: that had a python2 only dependency for SVG generation, yes 15:45:00 masghar: but your point makes total sense, if there is anything useful we should definitely migrate and update it 15:45:04 which is why it is now a PNG 15:45:14 egad 15:45:30 * TheJulia gets some glue and applies it to jamesdenton__'s irc client 15:45:34 and makes a strong argument against "just punt it to offline" because that is an end state that's unpleasant for that 15:45:44 :| 15:45:59 jamesdenton__: sorry, your not allowed to leave us ;) 15:45:59 am i bouncing? 15:46:09 jamesdenton__: It seems that way 15:46:20 jamesdenton__ meet jamesdenton_ 15:46:21 about every 5-10 minutes :D 15:46:30 had a pretty major storm overnight and some power outages... things settling down 15:46:44 yeah, i think znc is going nuts 15:47:12 So sounds like the summary is: the state of generated diagrams in our docs is generally bad, not just the parts that are blocking u-c bumps, and should probably be a larger topic which involves retiring a large number of them. 15:47:28 I might try to nerd-snipe some of my friends in other communities to find us a replacement library ;) 15:47:46 ispers plantuml 15:47:50 argh 15:47:55 * rpittau whispers plantuml 15:48:02 going back to the sequence diagrams, I think it might make sense to make sure some lower level details are covered elsewhere in our docs in terms of mechanics, but I think the diagrams in the ilo driver can be dropped 15:48:52 ++ 15:49:27 sounds good 15:49:27 masghar: as one of our newer members, would you like to take a look at that? I can, but I may make some assumptions on what actually is documented clearly 15:49:47 I can prepare an example patch to show plantuml 15:49:52 that sounds great 15:50:00 I can! I will ask many many questions though :D 15:50:05 masghar: that is fine :) 15:50:13 Thanks rpittau! 15:50:15 Iury Gregory Melo Ferreira proposed openstack/ironic master: RedfishFirmwareInterface - Unit Tests & More logs https://review.opendev.org/c/openstack/ironic/+/903379 15:50:25 masghar: questions welcome :) 15:50:28 rpittau: is this in regards to the sequence diagrams? 15:50:34 yes 15:50:37 okay 15:50:54 Alright then, I will start with the ilo diagrams 15:51:23 perfect 15:51:39 Anything else we need to chat about in Open Discussion? :) 15:51:53 I brought up our published priorities 15:52:14 I have some little questions 15:52:42 k_romanenko: for our open discussion section of our meeting? 15:53:11 I guess so. Since I left Mirantis I have a batch of incomplete Ironic-related changes on review. 15:53:20 Over last years I completed two of them. So far there are some changes pending. Here are questions related: 15:53:35 TheJulia: I suggest we encourage, here and on ML, people review that and take a dedicated agenda item next meeting to go over priorities, is that good for you? 15:53:45 TheJulia: that way we don't spend time here looking over it sync in meeting? 15:54:02 JayF: fair, in the past I would have just told folks "update the whiteboard" 15:54:25 k_romanenko: okay 15:54:26 In this case, the whiteboard is the attached bugs, which has the same effect here 15:54:31 but I think a zoomed out view is valuable 15:54:44 1. Is ML2 Neutron Events Fail Fast feature still actual? 2. Are Ironic_tempest_plugin tests still necessary? 3. Are the functional tests for ironicclient OSC plugin still needed? 15:55:09 If yes all three, then I will continue on those topic. I just have some time. 15:55:09 If you have links to the reviews those questions are contextually related to that'd be useful too :D 15:55:33 1) Neutron events processing work stalled, basically the issue was "how to pause/resume" where we need to in way that is non-breaking 15:55:40 ML2 Fail Fast: https://review.opendev.org/c/openstack/ironic/+/370016 15:56:04 2) Depends, for api contract stuffs yes, if you have specific questions happy to look/discuss after the meeting. 15:56:12 3) I have no idea :) 15:56:26 Tempest plugin, here I renewed the patch already https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/906078 15:57:40 I hashtagged 906078 for you with ironic-week-prio 15:57:41 so I think the original stance was not to do negative testing in tempest, because largely those items should already be covered in overall unit tests. That being said, at a glance I suspect your additional tests make sense 15:57:58 ironicclient OSC plugin tests like this: https://review.opendev.org/c/openstack/python-ironicclient/+/382496 15:59:00 I just approved that one 15:59:42 Thank you 16:00:12 Ok, then I will put aside the ML2 stuff and continue updating points 2 and 3. 16:00:48 And just in time; because we're at time for the meeting. 16:00:51 Thank you so much everyone 16:00:55 and welcome back k_romanenko o/ 16:00:56 #endmeeting