| rpittau | good morning ironic! o/ | 07:50 |
|---|---|---|
| masghar | Good morning! | 10:29 |
| iurygregory | good morning Ironic | 11:12 |
| TheJulia | good morning | 13:33 |
| rpittau | good morning TheJulia :) | 13:49 |
| iurygregory | good morning TheJulia =) | 13:51 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Redfish UefiHttp boot support https://review.opendev.org/c/openstack/ironic/+/900964 | 14:22 |
| opendevreview | Julia Kreger proposed openstack/ironic master: DNM: Add redfish https CI job https://review.opendev.org/c/openstack/ironic/+/901090 | 14:23 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Add HTTP versions of network boot interfaces https://review.opendev.org/c/openstack/ironic/+/900965 | 14:23 |
| opendevreview | Julia Kreger proposed openstack/ironic master: DNM: CI test for httpboot jobs https://review.opendev.org/c/openstack/ironic/+/901182 | 14:23 |
| TheJulia | sigh, since recheck didn't want to get picked up :\ | 14:23 |
| dtantsur | JayF, kubajj, hey, how are the by_arch options going to work when the node does not have CPU arch? | 14:36 |
| dtantsur | also: your config samples in the docs seem invalid to me.. I wonder if anyone has even tested it? | 14:37 |
| kubajj | dtantsur: let me have a look | 14:37 |
| dtantsur | I'm this -->.<-- close to undeprecating deploy_kernel/ramdisk. | 14:38 |
| dtantsur | yep, the config is not a valid dict format in oslo.config | 14:43 |
| kubajj | dtantsur: isn't that tested by openstack-tox-docs? | 14:46 |
| dtantsur | kubajj: no, it was supposed to be tested by the person submitting the patch... | 14:46 |
| dtantsur | Let alone the fact that deploy_kernel cannot be replaced by deploy_kernel_by_arch when cpu_arch is absent | 14:49 |
| dtantsur | Let alone the consistency with other options | 14:49 |
| kubajj | dtantsur: do you mean the format in the docs or the one defined in the actual code? | 14:49 |
| dtantsur | kubajj: the format in the docs is plainly wrong - it's not a python dict | 14:49 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Fix *_by_arch documentation and un-deprecate the options without it https://review.opendev.org/c/openstack/ironic/+/901958 | 14:53 |
| dtantsur | JayF, kubajj ^^^ | 14:53 |
| JayF | oof, will review | 14:57 |
| JayF | Would someone mind moderating the meeting this morning? I can if there are no volunteers | 14:57 |
| dtantsur | I think TheJulia volunteered the last time | 14:57 |
| dtantsur | or.. hmm.. rpittau | 14:57 |
| dtantsur | I may be confusing everything, sorry | 14:57 |
| TheJulia | I got rpittau to volunteer :) | 14:57 |
| JayF | Well I wasn't here last week :) | 14:57 |
| JayF | I am here now, but with zero context | 14:58 |
| TheJulia | Figuring exactly this :) | 14:58 |
| TheJulia | excellent, welcome Mr. Zero Context | 14:58 |
| kubajj | dtantsur: I am sorry, that is my fault, I did not know that the cpu_arch property can be missing and I thought the docs were tested by tox. If cpu_arch is missing then it would use the %mode_kernel/ramdisk | 14:58 |
| JayF | Just call me 0CXT for short, it's my rap name :P | 14:58 |
| TheJulia | JayF: no idea about uniforms for htis new zero context role, speak with the budget folks ;) | 14:58 |
| rpittau | I"m here! I'm here! | 14:58 |
| TheJulia | heh | 14:58 |
| rpittau | oh it's not late | 14:58 |
| rpittau | #startmeeting ironic | 15:00 |
| opendevmeet | Meeting started Mon Nov 27 15:00:07 2023 UTC and is due to finish in 60 minutes. The chair is rpittau. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:00 |
| TheJulia | o/ | 15:00 |
| rpittau | Welcome to our weekly meeting! | 15:00 |
| rpittau | The meeting agenda can be found here: | 15:00 |
| rpittau | #link https://wiki.openstack.org/wiki/Meetings/Ironic#Agenda_for_next_meeting | 15:00 |
| iurygregory | o/ | 15:01 |
| masghar | o/ | 15:01 |
| kubajj | o/ | 15:01 |
| rpittau | #topic Announcements / Reminders | 15:02 |
| JayF | o/ | 15:02 |
| rpittau | we have only the usual reminder to review the patches tagged as priority on our board https://tinyurl.com/ironic-weekly-prio-dash | 15:02 |
| rpittau | anyone has other announcements / reminders ? | 15:03 |
| dtantsur | Release time soon? | 15:03 |
| rpittau | oh yeah, I put that topic later :) | 15:04 |
| rpittau | but I guess I can say it here | 15:04 |
| rpittau | the new bugfix branches proposals are up | 15:04 |
| rpittau | https://review.opendev.org/c/openstack/releases/+/901957 | 15:04 |
| rpittau | https://review.opendev.org/c/openstack/releases/+/901956 | 15:04 |
| rpittau | https://review.opendev.org/c/openstack/releases/+/901955 | 15:04 |
| rpittau | anything else to announce or remind ? | 15:06 |
| JayF | There is a call on the list | 15:06 |
| JayF | for projects for a UNM class | 15:06 |
| rpittau | mm haven't seen it | 15:07 |
| JayF | If we have Ironic-related items, it wouldn't hurt for one of us to put up a proposal -- I think last time something like this came up, we proposed ARM CI (basically ARM VM support for sushy-tools) | 15:07 |
| JayF | deadline is this week, so if someone wants to action that it has to be nowish | 15:07 |
| rpittau | JayF: do you have the permalink to the thread ? | 15:07 |
| * JayF stalls for time | 15:08 | |
| rpittau | we can add it later, it's ok :) | 15:08 |
| rpittau | thanks for mentioning that! | 15:08 |
| dtantsur | We have a lot of work items that could be taken | 15:08 |
| dtantsur | e.g. Mahnoor and myself could use some help with the inspector merger | 15:08 |
| dtantsur | (we're dragged into other downstream priorities) | 15:09 |
| masghar | ++ | 15:09 |
| rpittau | the deadline is quite close | 15:10 |
| dtantsur | yeah, and I probably won't be able to mentor anyone in the near future... | 15:11 |
| JayF | I can't find the link; and search on ML archives appears brokenish(?) | 15:11 |
| JayF | But I don't have time to mentor either; so it may be a moot point anyway | 15:11 |
| rpittau | ok, let's see how the start of the week goes and think about it, if we can make time for some mentoring | 15:12 |
| rpittau | it's a shame otherwise but we're all quite busy with downstream stuff in the near future | 15:12 |
| JayF | I honestly spent a large portion of my last 2-3 months on softer stuff like governance and mentorship and need to point more time at technical focuses for productivity and personal sanity :) | 15:13 |
| dtantsur | Mentorship are no longer popular among companies, at seems.. | 15:13 |
| dtantsur | except for maybe JayF :D | 15:13 |
| JayF | Well, I've run myself past-empty trying to fill in the gaps, I can't do that anymore. | 15:13 |
| rpittau | :) | 15:13 |
| rpittau | shall we move on? | 15:13 |
| JayF | ++ | 15:14 |
| rpittau | #topic Review action items from previous meeting | 15:14 |
| rpittau | I have an action item from last time | 15:14 |
| rpittau | change the launchpad ownership for virtualpdu to | 15:14 |
| rpittau | us | 15:14 |
| rpittau | it was done | 15:14 |
| rpittau | iurygregory: how was your week as bug deputy ? :) | 15:15 |
| iurygregory | hey o/ | 15:15 |
| iurygregory | status from the bug deputy week | 15:15 |
| iurygregory | Ironic: 169 bugs (-20) + 182 wishlist items (-7). 20 new (-9), 77 in progress (-19), 3 critical , 26 high (+3) and 13 incomplete | 15:15 |
| rpittau | any bug that needs immediate action/attention ? | 15:16 |
| iurygregory | I was able to triage a few bugs, the unassigned In Progress is empty now \o/ | 15:16 |
| rpittau | great :) | 15:16 |
| iurygregory | and I've clean up some old In Progress Bugs | 15:16 |
| iurygregory | we have 3 critical bugs | 15:17 |
| iurygregory | 2 were created this year, so we should try to look at them to see what we can do I would say | 15:17 |
| iurygregory | #link https://bugs.launchpad.net/ironic/+bug/2026757 | 15:17 |
| iurygregory | #link https://bugs.launchpad.net/ironic-python-agent-builder/+bug/2043112 | 15:17 |
| rpittau | thanks! | 15:18 |
| rpittau | TheJulia: you're still up for bug deputy this week ? | 15:18 |
| iurygregory | While working as bug deputy I think it would be good to have some sort of guide on the procedure we should take for old bugs specially | 15:18 |
| TheJulia | yeah, I'll give it a shot, but I won't be around on monday to report | 15:18 |
| rpittau | #action TheJulia is the bug deputy this week | 15:19 |
| rpittau | iurygregory: probably worth adding something to the bug deputy docs | 15:19 |
| TheJulia | my focus is likely going to be really old bugs which should have long been closed out | 15:19 |
| iurygregory | rpittau, yeah | 15:19 |
| rpittau | thanks TheJulia :) | 15:19 |
| rpittau | alright, let's move on if there's nothing more on bugs | 15:21 |
| rpittau | #topic Caracal release schedule | 15:21 |
| rpittau | #link https://releases.openstack.org/caracal/schedule.html | 15:21 |
| rpittau | caracal milestone 2 is January 11th | 15:22 |
| rpittau | in 1 month and a half | 15:22 |
| rpittau | #topic Review Ironic CI status & update whiteboard if needed | 15:22 |
| rpittau | CI is particularly silent recently, should we worry? :) | 15:23 |
| TheJulia | seems to be working at the moment :) | 15:23 |
| rpittau | good :) | 15:23 |
| rpittau | #topic Bug Deputy role proposal has merged | 15:24 |
| rpittau | it's official now! :) | 15:24 |
| rpittau | I've spoke already about the bugfix branches, and I don't see new RFEs to discuss | 15:25 |
| rpittau | #topic Open Discussion | 15:25 |
| rpittau | anything up to discuss? | 15:25 |
| dtantsur | I did have an RFE to discuss, but I forgot to add it :D | 15:25 |
| rpittau | oh! | 15:26 |
| dtantsur | if you have any time | 15:26 |
| rpittau | I think so :) | 15:26 |
| dtantsur | #link https://bugs.launchpad.net/ironic/+bug/2044561 Dynamic boot configuration API | 15:26 |
| dtantsur | TheJulia: you commented on ^^^ | 15:27 |
| dtantsur | Actually, making it not tied to iPXE was one of the design goals | 15:27 |
| TheJulia | Yes, I guess I have two thoughts. I'd love for it to be generic upfront, instead of there being an ipxe flavor explicitly tied to parameters | 15:27 |
| dtantsur | I'm using iPXE as the reference implementation because I don't know anything else | 15:27 |
| TheJulia | I also kind of wonder if it needs a spec (sorry!) | 15:27 |
| dtantsur | Possibly, except that it risks ending up one of my many unfinished items | 15:28 |
| TheJulia | ahh, okay, luckily the vast majority of the code under the hood is used by both ipxe/pxe | 15:28 |
| JayF | That needs a spec IMO as well. | 15:28 |
| TheJulia | the base challenge is that anytime we built explicit logic around one, we've made the underlying code more and more complicated too :\ | 15:28 |
| TheJulia | not insurmountable by any means, some cleanup is needed there too | 15:28 |
| TheJulia | but existing pxe parameters have kind of been lingering, so I'd personally try to avoid using ipxe in the name, I guess | 15:29 |
| dtantsur | I can draft a quick spec if that's actually something of interest | 15:29 |
| dtantsur | The question is "it needs a spec" means "we want to discuss details" or more of "Dmitry, please go away with your crazy ideas" :D | 15:29 |
| * dtantsur is ready to accept the latter | 15:29 | |
| JayF | Mine is more | 15:30 |
| TheJulia | I could see it being a stepping stone to helping avoid the shared cluster conductor case | 15:30 |
| JayF | "oh god lets not encode ipxe implementation details in to an Ironic API definition without having at least a ?mode=ipxe" | 15:30 |
| JayF | but I love the idea :) | 15:30 |
| dtantsur | Hold on, where is this assumption coming from? | 15:30 |
| TheJulia | I guess the internal thing I'm wondering, where do we store the information to give it the correct up to date information | 15:30 |
| JayF | I guess if the filename is boot.ipxe, that is telling us it's an ipxe file, eh | 15:31 |
| TheJulia | grub will hunt for grub.cfg first | 15:31 |
| TheJulia | but you only get one bounce with that too... | 15:31 |
| dtantsur | grub with the ipxe boot interface? | 15:31 |
| TheJulia | so... maybe explicitly out of the box might not work, dunno | 15:31 |
| TheJulia | dtantsur: grub with boot_interface set to pxe | 15:31 |
| dtantsur | ipxe will expect boot.ipxe, grub will expect grub.cfg I guess | 15:31 |
| dtantsur | the file name is just a hint to the boot interface | 15:32 |
| TheJulia | yup | 15:32 |
| dtantsur | so that we don't corner itself with an inability to support more than one file per interface | 15:32 |
| TheJulia | I'm *not* entirely sure it would completely work with grub, I'd have to go look at the code to see how many times it lets you chain | 15:32 |
| dtantsur | so yeah, tl;dr: I did not expect the generic parts to have any references to iPXE | 15:32 |
| TheJulia | ipxe is much more flexible in that regard | 15:32 |
| TheJulia | cool | 15:33 |
| JayF | The other potential headache with something like this... we haven't hit this before, so probably YAGNI | 15:33 |
| JayF | but what if ipxe syntax were to change? | 15:33 |
| JayF | we need any concept of versioning for this? | 15:33 |
| dtantsur | That affects us now as well, no? | 15:33 |
| TheJulia | JayF: if it uses the same templates/config as the conductor... | 15:33 |
| JayF | Hmm. I guess so. | 15:33 |
| dtantsur | We already generate iPXE scripts | 15:33 |
| dtantsur | so, I will write a spec if there are people who will read it :) | 15:33 |
| JayF | Fair. | 15:33 |
| JayF | This is API ergonomics for a thing we already do | 15:33 |
| JayF | I need to stress less and just let it happen :) | 15:34 |
| dtantsur | (keeping in mind that we're otherwise stuck with a single conductor in metal3) | 15:34 |
| TheJulia | I'd honestly just use as much of the existing mechanims as possible, maybe generate the response on the fly if we can get the ip address of the place to grab the files from | 15:34 |
| dtantsur | TheJulia: my RFE proposes starting with just reading the existing files from disk | 15:34 |
| dtantsur | it's silly, but it will get us going really quickly | 15:34 |
| TheJulia | yeah, on the fly is far better for multi-conductor cases, but we can always iterate to it | 15:35 |
| JayF | GET /v1/boot/<node>/../../../etc/passwd.ipxe /s | 15:35 |
| dtantsur | JayF: see, so many cool features possible! | 15:35 |
| TheJulia | we're not a general server | 15:35 |
| dtantsur | the key for multi-conductor is the hash ring integration. my proposal gives that. | 15:35 |
| TheJulia | only static file names based upon registered interfaces and deconstruct from there ;) | 15:35 |
| JayF | So question | 15:36 |
| TheJulia | yeah, we would likely need to store the ip address | 15:36 |
| JayF | if we added this API | 15:36 |
| TheJulia | addresses | 15:36 |
| TheJulia | and urls | 15:36 |
| JayF | we have all the pieces we need to do basically ... externally orchestrated Ironic, yeah? | 15:36 |
| dtantsur | please elaborate | 15:36 |
| JayF | Because we'd have the ability to change power, boot mode, and do static boot configs | 15:36 |
| JayF | you could basically use Ironic as an API-controlled fancy pxe server | 15:36 |
| JayF | without any of our other features | 15:37 |
| dtantsur | Could be. We're even adding a way to attach virtual media (please review it!) | 15:37 |
| JayF | which makes me a little sad, but also is a thing I've had multiple people say they wish they could do with an existing Ironic install (yeah, I've reviewed many of those and have +1s, I don't +2 redfish stuff unless nobody else is b/c I don't have hardware) | 15:37 |
| dtantsur | JayF: you can use sushy-tools :D | 15:38 |
| dtantsur | honestly, "I don't +2 things I don't have hardware for" may not be a sustainable idea | 15:38 |
| JayF | I, bluntly, do not think that is sufficient testing to land a new hardware-supporting feature. | 15:38 |
| dtantsur | someone has to review Fujitsu's patches | 15:38 |
| JayF | dtantsur: I've never once in my life logged into a redfish BMC. Ever. | 15:38 |
| JayF | dtantsur: and upon request I upgrade my votes. | 15:38 |
| JayF | dtantsur: just a default not a strict personal policy :) | 15:39 |
| dtantsur | How do you manage to avoid Redfish nowadays? :) | 15:39 |
| JayF | I have no hardware at all :) | 15:39 |
| dtantsur | haha, fair | 15:39 |
| JayF | I work in Tacoma, WA, my employer is in London, UK :) | 15:39 |
| dtantsur | This hardware thing, it only causes headaches, right? | 15:39 |
| JayF | even when I'm in the UK I don't get to touch the gear lol | 15:39 |
| rpittau | so going back to the RFE, dtantsur going to write a spec? | 15:39 |
| dtantsur | I am | 15:40 |
| rpittau | then I'll read it :D | 15:40 |
| dtantsur | btw https://github.com/dtantsur/ironic-operator/issues/3 is the tracker for multi-conductor metal3 | 15:40 |
| dtantsur | in case anyone wants to jump on the discussion | 15:40 |
| rpittau | it's open in my browser since last week :) | 15:40 |
| rpittau | alright, anything else we need to discuss about ? | 15:41 |
| dtantsur | so speaking of Fujitsu.. | 15:41 |
| rpittau | oh yeah | 15:41 |
| * dtantsur needs to find the RFE | 15:41 | |
| dtantsur | #link https://bugs.launchpad.net/ironic/+bug/2040236 BMC certificates | 15:42 |
| dtantsur | I probably missed that meeting, but I'm puzzled by its outcome | 15:42 |
| dtantsur | JayF: could you check my comment? | 15:42 |
| dtantsur | Not that I mind a spec there, but it's really one of the things we tend to consider quite obvious | 15:43 |
| JayF | I read the emails over the holiday. Upon reflection... 🤷 | 15:43 |
| JayF | we should probably look the meeting log up | 15:43 |
| JayF | 10-30 is when I commented, looking | 15:43 |
| dtantsur | https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-10-30-15.00.log.html I assume | 15:43 |
| JayF | looks like that was a proxied concern mostly from Julia | 15:44 |
| JayF | I can link the meeting logs into the bug | 15:44 |
| dtantsur | TheJulia: ^^ | 15:45 |
| JayF | I was unsure, there was agreement on the uncertainty | 15:45 |
| dtantsur | I'm even more puzzled by the logs to be honest | 15:45 |
| dtantsur | The problem is: Ironic is currently *normally* operated with verify_ca=False | 15:45 |
| dtantsur | we need to change that | 15:45 |
| JayF | I wonder if we misread something meaningful in the bug, or if there's context I had then which is missing now | 15:45 |
| JayF | I'm unsure, but that uncertainty makes me feel more like I want a spec, which may not be fair either :\ | 15:46 |
| dtantsur | Let me give it a try | 15:46 |
| TheJulia | dtantsur: is the thought a boolean field value on a node? | 15:46 |
| dtantsur | TheJulia: the boolean field on a node exists already, it's not helpful | 15:46 |
| TheJulia | I can go for that, as a migration means | 15:46 |
| TheJulia | we can't permit paths | 15:46 |
| dtantsur | the only practical way to use it now is to set it to False | 15:46 |
| TheJulia | realistically | 15:46 |
| dtantsur | we can and should | 15:46 |
| dtantsur | but not on the node level because it makes little sense | 15:47 |
| dtantsur | (although we probably do allow that now already) | 15:47 |
| TheJulia | I'm not sure I'm really comfortable with that, but I guess it boils down to implementation details and access rights | 15:47 |
| dtantsur | this is really a site-specific setting | 15:47 |
| TheJulia | i.e. don't let any member set the field | 15:47 |
| JayF | My thought on the node-level stuff is | 15:47 |
| dtantsur | that's why it has to go to ironic.conf | 15:47 |
| JayF | if it's something shipped *in a ramdisk* paths in node level makes sense | 15:47 |
| JayF | if it's something shipped *in a conductor*, you can't do it via API | 15:47 |
| dtantsur | yep, the latter | 15:48 |
| JayF | because ramdisks are accessible/changable via API; conductor files-on-disk are not | 15:48 |
| dtantsur | it seems that we're in a full agreement, so what's the blocker? | 15:48 |
| JayF | dtantsur: the suggested code in the example | 15:48 |
| JayF | provides a node level override, I think? | 15:48 |
| JayF | dtantsur: so the prose does not match the example code | 15:49 |
| JayF | that is likely what the disconnect is | 15:49 |
| dtantsur | the example code is weird, I agree. that's why I tell people not to include code in proposals.... | 15:49 |
| TheJulia | ++ | 15:49 |
| JayF | (and again, inconsistency in an RFE is more of a reason to have a spec IMO; but as long as we have a correct end state documented *somewhere* I don't care where that somewhere is) | 15:49 |
| dtantsur | the idea is to have a conductor-level verify_ca for BMCs | 15:49 |
| JayF | I think our two questions were primarily: | 15:50 |
| dtantsur | I don't really mind a spec, just making sure the proposal is correctly understood from the beginning | 15:50 |
| JayF | 1) it's [conductor]verify_ca being proposed for iRMC driver; we wanna be sure it's respected everywhere | 15:50 |
| * dtantsur nods | 15:50 | |
| JayF | 2) the example code has a node-level override, which is (for reasons discussed here) not awesome | 15:50 |
| JayF | which I think is what my comment is trying to say, badly | 15:50 |
| JayF | I'm going to re-post that comment with more verbosity | 15:51 |
| dtantsur | yeah, I agree. thanks! | 15:51 |
| dtantsur | I have a nagging desire to just junk the code examples from the RFE | 15:51 |
| dtantsur | yank? I cannot do words today | 15:51 |
| rpittau | well that was a good discussion :) | 15:52 |
| rpittau | I think we're good or we have something more to discuss? | 15:53 |
| JayF | #link https://bugs.launchpad.net/ironic/+bug/2040236/comments/4 | 15:53 |
| JayF | that's the updated comment in summary | 15:53 |
| rpittau | thanks JayF | 15:54 |
| rpittau | I think we can close here | 15:54 |
| rpittau | thanks everyone! | 15:54 |
| rpittau | #endmeeting | 15:54 |
| opendevmeet | Meeting ended Mon Nov 27 15:54:21 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:54 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-11-27-15.00.html | 15:54 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-11-27-15.00.txt | 15:54 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2023/ironic.2023-11-27-15.00.log.html | 15:54 |
| kubajj | dtantsur: I figured out what was the problem. I am pretty sure I tested it in bifrost, but then did not update the docs. | 15:58 |
| dtantsur | I see. Well, I have an update now. | 15:59 |
| dtantsur | Does not change the fact that we need the old options for the case when cpu_arch is not there. | 15:59 |
| kubajj | dtantsur: Yeah, I thought it was automatic and so deprecated the original options | 16:00 |
| dtantsur | Only automatic with inspection which not everyone uses | 16:00 |
| JayF | or if you wanted to keep the options deprecated, you'd have to add/document a "None"/"unknown" key or some kind of cpu_arch_default | 16:01 |
| JayF | I don't hate the idea of cpu_arch_default to solve this problem TBH | 16:01 |
| JayF | because I think we'll have more by_arch stuff in the future | 16:01 |
| dtantsur | we already have a lot of them, and we've never deprecated the non-arch variants | 16:02 |
| JayF | but I do not have strong opinions about if the original deploy_* gets deprecated or not; more thinking about wanting to ensure we don't keep single-arch assumptions moving forward | 16:02 |
| JayF | ack | 16:02 |
| dtantsur | so at least I want to restore both functionality and consistency before we think how to proceed | 16:02 |
| JayF | ++ | 16:03 |
| JayF | I haven't looked at your patch yet, but I doubt I disagree with it in any principle | 16:03 |
| JayF | I'm just talking about moving forward after it | 16:03 |
| JayF | and thinking through other alternate paths that could've been taken | 16:03 |
| JayF | (sorta part of a mental RCA for how I let it land broken-ish) | 16:04 |
| kubajj | dtantsur: you've mentioned that you need help with inspector merger, is there anything smaller/medium sized I could look into? | 16:16 |
| dtantsur | kubajj: are inspection rules small in your book? :) | 16:16 |
| dtantsur | masghar: I assume you haven't started with ^^^? | 16:16 |
| dtantsur | https://specs.openstack.org/openstack/ironic-specs/specs/approved/inspection-rules.html | 16:16 |
| masghar | No I haven't started with them | 16:17 |
| kubajj | dtantsur: I mean more something like a change I could work on during evenings just to keep in touch with Ironic | 16:19 |
| dtantsur | Probably not in the inspector field then.. | 16:19 |
| JayF | kubajj: I've been trying to tag bugs low-hanging-fruit | 16:20 |
| JayF | Might be something there worth a look | 16:20 |
| kubajj | JayF: oh, this is helpful. I'll have a look | 16:21 |
| opendevreview | Julia Kreger proposed openstack/sushy master: Remove version field from iLO error https://review.opendev.org/c/openstack/sushy/+/901989 | 16:43 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic master: Fix *_by_arch documentation and un-deprecate the options without it https://review.opendev.org/c/openstack/ironic/+/901958 | 17:13 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Deprecate configuration molds https://review.opendev.org/c/openstack/ironic/+/901502 | 17:21 |
| rpittau | good night! o/ | 17:37 |
| opendevreview | Mahnoor Asghar proposed openstack/ironic master: Fix Redfish request collecting storage drives https://review.opendev.org/c/openstack/ironic/+/901994 | 17:40 |
| -opendevstatus- NOTICE: Zuul build urls should be working again (browser refresh may be required) | 18:31 | |
| TheJulia | \o/ | 18:31 |
| opendevreview | Merged openstack/ironic master: Multiple driver related deprecations https://review.opendev.org/c/openstack/ironic/+/901501 | 19:01 |
| opendevreview | Julia Kreger proposed openstack/ironic master: DNM: Change to enforced policy by default https://review.opendev.org/c/openstack/ironic/+/902009 | 21:46 |
| TheJulia | gah, looks like I have another issue with the parsing in sushy-tools :( | 22:01 |
| stevebaker[m] | TheJulia: Hey can you cast your mind back to this fix? https://review.opendev.org/c/openstack/ironic-python-agent/+/879897 It looks like in CI the output for efibootmgr is not utf-16, see https://zuul.opendev.org/t/openstack/build/b1b917d216c0429dbcdf133d8c08f7b3/log/controller/logs/ironic-bm-logs/node-0_console_2023-11-26-20:29:04_log.txt#3177 | 22:03 |
| stevebaker[m] | I wonder if we should just set use_standard_locale=True on that execute call instead | 22:03 |
| opendevreview | Merged openstack/sushy master: Remove version field from iLO error https://review.opendev.org/c/openstack/sushy/+/901989 | 22:06 |
| *** dmellado206 is now known as dmellado20 | 22:08 | |
| TheJulia | so binary=True should mean nothing gets parsed | 22:13 |
| TheJulia | but... that is just biza | 22:13 |
| TheJulia | stevebaker[m]: oh, you rgetting an exception trying to convert to string outright | 22:15 |
| TheJulia | so if it the line is binary, and it didn't know the type, wouldn't it fail trying to re-encode it to str? | 22:17 |
| TheJulia | and thus we would get some funky result? | 22:17 |
| stevebaker[m] | TheJulia: isn't the error on the decode line? I can add some logging to clarify that | 22:19 |
| stevebaker[m] | TheJulia: but my thought is, so many commands are executed with use_standard_locale=True, wouldn't doing that here too avoid any encoding issues? | 22:20 |
| stevebaker[m] | and its not like we need any non-ascii characters from that output, setting LC_ALL=C would be fine | 22:23 |
| opendevreview | Jay Faulkner proposed openstack/sushy stable/2023.2: Remove version field from iLO error https://review.opendev.org/c/openstack/sushy/+/901937 | 22:26 |
| JayF | Is the limitation of Redfish HTTP(s) Boot to not allow configdrive something we expect to lift at some point? | 22:38 |
| JayF | oh, it doesn't support *IPA configdrives* | 22:38 |
| JayF | at least aiui | 22:39 |
| JayF | ah; redfish https boot + ramdisk = no configdrive; redfish https boot for provisioning = no node network data for ipa | 22:40 |
| TheJulia | stevebaker[m]: not on the decode line, your logging after the decode, decode can fail and that is okay, I think your getting a decoded stream != string | 22:41 |
| TheJulia | stevebaker[m]: of course, what your getting in that output overall is downright bizarre | 22:41 |
| TheJulia | JayF: bingo | 22:42 |
| TheJulia | and thus we won't be able to lift it since DHCP will be required by the endpoint anyway | 22:42 |
| JayF | I suspect there are technical ways to get configdrive along for the ride in the ramdisk iso | 22:43 |
| JayF | if we're assembling the iso at provision time | 22:43 |
| JayF | kernel+ramdisk+configdrive -> stuff into iso, somehow | 22:43 |
| TheJulia | JayF: depends on how much of that "iso" stays in memory | 22:43 |
| JayF | ISO 9660.1, CD ISOs plus like, some partitions | 22:43 |
| JayF | (I made that up as a joke to be clear; anyone seeing this in a google result) | 22:44 |
| TheJulia | bootloader drop everything else from the ISO from ram that is not the loaded kernel+ramdisk | 22:44 |
| TheJulia | so, even if it was there, you would be in a "oh, it just went poof" situation | 22:44 |
| JayF | oooh so that virtual media iso is not accessible at all from the OS side? | 22:44 |
| TheJulia | The ISO crafted as virtual media would no longer be acessible | 22:44 |
| TheJulia | correct | 22:44 |
| TheJulia | same limitation with the ramdisk deploy interface | 22:45 |
| TheJulia | so, the ramdisk would need to be "appended to" to make it work | 22:45 |
| TheJulia | that would be the "only way" | 22:45 |
| JayF | you'd have to do something like we did in the old coreos ramdisk | 22:45 |
| TheJulia | yup | 22:45 |
| JayF | in the initrd, spin something up to get some data out | 22:45 |
| TheJulia | you can do multi-layered initrds | 22:45 |
| JayF | write it to some sorta loopback file (probably?) and mount it as a loopback | 22:45 |
| TheJulia | just is a total PITA to take apart and reassemble | 22:46 |
| JayF | or just dump a loopback ISO FS inside the initramfs and copy it into a reasonable place | 22:46 |
| TheJulia | like.. you really need to write a script to do it | 22:46 |
| JayF | yeah, I'm just reviewing it and trying to get the shape of the limitations | 22:46 |
| JayF | this conversation has been very helpful | 22:46 |
| TheJulia | you can't because cpio explodes on the delimiter | 22:46 |
| TheJulia | at least, the easy route | 22:46 |
| JayF | you base64 encode it | 22:46 |
| TheJulia | not on the current multi-layered initrd stuffs | 22:46 |
| TheJulia | it is like a file with multiple distinct chunks which get recursively extracted | 22:47 |
| JayF | I'm not even thinking about the actual stuff built into linux so much as I am just harkening back to the hacky ways we made this kinda thing work back at Rackspace | 22:47 |
| TheJulia | you have to get something linux can upack in ram, otherwise there is nothing because you only get the bytes in ram until it frees them | 22:47 |
| JayF | we had, at one point, an initrd which would, mid-boot, pull down the IPA container and boot (trying to separate the OS/ramdisk shell from the IPA code, it was unwise but we got it working) | 22:48 |
| TheJulia | once it frees the original address space with the initrd load from initial boot, that is all gone too | 22:48 |
| TheJulia | you can sort of do that in part of boot, but with a single without network, it all has to unwind right then and there | 22:48 |
| JayF | I was assuming we'd do something like setup a ramfs or tmpfs to dump the configdrive in on boot | 22:48 |
| JayF | to preserve it | 22:48 |
| JayF | (this is all just sorta conjecture anyway; I don't know if there's a use case for this; like I said I was just trying to find the shape of the limitations to inform my review so you can bail on the conversation if you aren't having fun LOL) | 22:49 |
| TheJulia | heh | 22:52 |
| TheJulia | I was more so starting a pie for dessert | 22:52 |
| JayF | oooh I have an evil idea | 23:00 |
| JayF | I wonder if Ironic could swap the virtual media somehow | 23:00 |
| JayF | If you ignore the timing issues (e.g. assume someone has glean setup with udev rules to run if a new block device of the proper metadata is attached), Ironic could late-attach a configdrive to a ramdisk interface node | 23:01 |
| JayF | it would be an awful idea *if* not for the new redfish thing which can tell us when an OS has booted | 23:01 |
| JayF | which moves it from "awful idea" to "maybe only a little bad" | 23:01 |
| TheJulia | only for full blown virtual media | 23:04 |
| TheJulia | not for httpboot stuffs | 23:04 |
| TheJulia | since your not dealing with a device there | 23:04 |
| JayF | Ah, so there's a matrix | 23:04 |
| JayF | that is the entirety of the flaw in my thinking, I think | 23:05 |
| TheJulia | and the full blown virtual media has the ability to try a second device aiui | 23:05 |
| JayF | I assumed http boot == it had some kinda virtual media | 23:05 |
| TheJulia | nah, its not at all | 23:05 |
| JayF | but it not makes the limitations you lay out make a *lot* more sense | 23:05 |
| TheJulia | its just telling software "go boot from this" | 23:05 |
| TheJulia | and the same software limitations come into play | 23:05 |
| TheJulia | ... what has me stumped at the moment is why sushy-tools worked once, but didn't work after the latest rebase | 23:06 |
| JayF | dtantsur: please take a look at https://review.opendev.org/c/openstack/ironic/+/890411 | 23:30 |
| JayF | Is it OK if https://review.opendev.org/c/openstack/ironic/+/900846 would permit any Ironic user with access to console to kick any other Ironic user off the console? that's the effective change? | 23:33 |
| JayF | I'm worried if there are security implications there | 23:33 |
| JayF | https://review.opendev.org/c/openstack/ironic/+/900846/2#message-7a8c9b24165f991880aeaeda6bb501e514d99cdf -1'd for lack of a release note anyway; but I think we should think about the black hat potential of this change | 23:35 |
| TheJulia | I think I'm going to go exercise, I'm feeling stumped by my redfish https boot failure at the moment :( | 23:40 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!