JayF | but I will say, if we have parent/child nodes and don't use chassis I gotta question why we don't rip it out | 00:00 |
---|---|---|
TheJulia | For modify, we could call it “transmutate” | 00:00 |
JayF | also chassis can be about relationships to nodes... e.g. chassis could contain actual-node and dpu-node | 00:00 |
TheJulia | Very very true | 00:01 |
JayF | TheJulia: /me pokes the sleeping "zapping" verb | 00:01 |
JayF | I'm not saying it's the answer to use chassis; I'm saying we need to know why we can't use it, and enumerate that in the spec | 00:01 |
TheJulia | I think we poured concrete on that verb and left it in Seattle | 00:01 |
JayF | I found it when I moved here | 00:01 |
JayF | and if that's not the use case for chassis, we need to find one or nuke it (even if we can't API-nuke it, we can effectively deprecate/remove it) | 00:01 |
TheJulia | In the immortal name of starbuck, Frak! | 00:02 |
JayF | we can only kick the can down the curb so many times before we run out of curb | 00:02 |
TheJulia | I… do think we should likely nuke chassis. I don’t think I’ve ever chatted with an operator that uses it. | 00:02 |
TheJulia | Likely time for a poll | 00:03 |
JayF | why not get to the end of the dpu stuff | 00:03 |
JayF | make the case or anti-case for using chassis for it there | 00:03 |
JayF | and that can be the platform we jump off of for whatever is next | 00:03 |
TheJulia | Well, we should get a data point of existing use to help guide the decision | 00:04 |
JayF | I'm just saying, if we're getting towards actual-composable-hardware and are still punting it away from chassis, it's clear chassis is the wrong model and we need to fix it | 00:04 |
TheJulia | Well, compositor is not the dpu case at all | 00:04 |
JayF | you didn't read all the dpu abstracts I did then | 00:04 |
JayF | lol | 00:04 |
TheJulia | composible is you ask a central controller to give you some bare metal in a shape/form | 00:04 |
JayF | yep, I think I read something about using one of these to like, supply storage to a server as native (?) | 00:05 |
* JayF is worried he might be mixing multiple things | 00:05 | |
TheJulia | You can absolutely do that with DPUs | 00:05 |
JayF | that's a form of composable hardware | 00:05 |
TheJulia | But you have to configure the dpu to pass it through | 00:05 |
JayF | who are you? | 00:06 |
JayF | are we you? | 00:06 |
TheJulia | Which is a bit separate | 00:06 |
JayF | that's sorta the space we're exploring now, yeah? | 00:06 |
TheJulia | Eh… not actual content/running state configuration since it is dynamic | 00:06 |
TheJulia | Say you attach/detach networks in neutron, the card would be on the message bus | 00:06 |
JayF | lets take it to the spec, you're eod o/ | 00:08 |
TheJulia | O/ | 00:08 |
stevebaker[m] | TheJulia: the docs are a bit vague https://docs.openstack.org/openstacksdk/latest/user/guides/stats.html, here is a paste of /metrics for my fake workload app https://paste.openstack.org/show/bhe4cxcCX4A8ZI53VtNO/ | 00:12 |
TheJulia | The node action stuff in that is confusing | 00:31 |
stevebaker[m] | In hindsight, these metrics are not useful to me, I'll continue publishing my own | 03:19 |
samuelkunkel[m] | <TheJulia> "Say you attach/detach networks..." <- Thats exactly what I will try with mine in the lab once I will find time for it… the guys next to me (which are doing neutron stuff) basically want to run an ovn-controller (+vswitchd / ovsdb) on the dpu itself. Basically terminating the vxlan / geneve tunnel on the dpu and just passing a port of that virtual network to the host system | 06:01 |
samuelkunkel[m] | Just goes a step more into the direction of treating a baremetal Node more like a VM. Also without something alike you are very limited if you are running ovs / ovn in your cloud for the customer networks | 06:03 |
opendevreview | renliang proposed openstack/ironic master: Fix expired links https://review.opendev.org/c/openstack/ironic/+/873896 | 07:52 |
opendevreview | renliang proposed openstack/ironic master: Fix expired links https://review.opendev.org/c/openstack/ironic/+/873896 | 07:53 |
rpittau | good morning ironic! o/ | 08:27 |
rpittau | JasonF, fungi, TheJulia, re virtualpdu: I forwarded the mail/thread to you, the last email has what we need | 08:35 |
opendevreview | Merged openstack/ironic-inspector stable/zed: [zed-only] Fix functional tests https://review.opendev.org/c/openstack/ironic-inspector/+/874488 | 09:20 |
kubajj | Morning everyone | 09:56 |
opendevreview | Riccardo Pittau proposed openstack/ironic master: [WIP] [PoC] A metal3 CI job https://review.opendev.org/c/openstack/ironic/+/863873 | 10:04 |
janders | hey Ironicers o/ | 10:04 |
opendevreview | Michele Costa proposed openstack/sushy-tools master: Ignore FileNotFoundError when ejecting virtual media image https://review.opendev.org/c/openstack/sushy-tools/+/874560 | 11:52 |
opendevreview | Mark Goddard proposed openstack/networking-generic-switch master: Add Fake device type https://review.opendev.org/c/openstack/networking-generic-switch/+/873098 | 12:48 |
TheJulia | rpittau: if you can dump out the headers, that would be good, I think phillip is referring to https://github.com/internap/virtualpdu | 14:09 |
TheJulia | Mathieu remembers opendev :) | 14:10 |
opendevreview | Michele Costa proposed openstack/sushy-tools master: Ignore FileNotFoundError when ejecting virtual media image https://review.opendev.org/c/openstack/sushy-tools/+/874560 | 14:15 |
rpittau | TheJulia: I have the original mail with the headers, let me find a good place to share that | 14:31 |
TheJulia | mgoddard: o/ w/r/t 873098, pity you can't really cleanly inject random sleeps into that as well :) | 14:35 |
TheJulia | mgoddard: well, into _send_commands_to_device you could put a random sleep | 14:35 |
TheJulia | mgoddard: oh, and https://review.opendev.org/c/openstack/networking-generic-switch/+/743283 appears to need to be rebased :( | 14:37 |
rpittau | TheJulia, JasonF, fungi, share a google docs with you, please let me know if that's enough | 14:37 |
mgoddard | TheJulia: I'm open to adding a configurable sleep as a follow up. Being super fast was actually a positive for testing and iterating on the batching feature though | 14:39 |
TheJulia | mgoddard: ahh, that makes sense | 14:40 |
TheJulia | cool cool | 14:40 |
mgoddard | initially I was using a real device for testing, but lost far too much time | 14:40 |
TheJulia | s/time/sanity/ ? :) | 14:40 |
mgoddard | I only have time left to lose :D | 14:40 |
TheJulia | mgoddard: at a high level, is the batching putting entries in etcd, then grabbing them out based upon who can get the lock? | 14:42 |
TheJulia | doing the needful/etc | 14:43 |
TheJulia | mgoddard: nvmd, looks like it kind of does | 14:47 |
rpittau | bifrost CI is broken, I need another coffee | 14:48 |
mgoddard | TheJulia: yes - port/network update requests push changes to an input key, kick off a task processing thread, then wait on the result key | 14:48 |
TheJulia | .. this really pushes me to think that we need to finish the neutron callback stuffs | 14:49 |
mgoddard | TheJulia: the task processing thread tries to get a lock while there is work in the input queue, then processes items, and puts results on the results queue | 14:49 |
mgoddard | original task picks up the result | 14:49 |
mgoddard | there are a few areas for potential improvement in ironic networking | 14:50 |
TheJulia | I guess in theory that might handle multiple neutron services getting requests for the same switch | 14:50 |
mgoddard | right | 14:50 |
mgoddard | did the neutron callback work ever start? | 14:51 |
TheJulia | yes, but it is a noop in ironic's api afaik | 14:53 |
TheJulia | issue is how to convey across the fact the thing has been released | 14:54 |
TheJulia | short of some sort of global data structure | 14:54 |
TheJulia | in the conductor | 14:54 |
* TheJulia thinks that is more up to the implementer to figure out | 14:54 | |
*** JasonF is now known as JayF | 15:15 | |
opendevreview | Riccardo Pittau proposed openstack/bifrost master: Update shim-signed name for ubuntu jammy https://review.opendev.org/c/openstack/bifrost/+/874650 | 15:43 |
rpittau | this ^ should fix bifrost CI | 15:44 |
dtantsur | rpittau: does it also work with previous versions and Debian itself? | 15:47 |
dtantsur | (I guess I could wait for the CI to tell us..) | 15:48 |
rpittau | dtantsur: I realized we're still running focal and looking for a way to change that for jammy only | 15:49 |
rpittau | and yeah, same thing for debian | 15:49 |
TheJulia | This is... the ?3rd? time they've changed the file name? | 15:49 |
dtantsur | rpittau: the required_defaults mechanism allows is, although I'd probably just inline a condition in the defaults | 15:49 |
rpittau | love unannounced breaking changes | 15:50 |
dtantsur | who said backward compatibility? | 15:50 |
TheJulia | Might actually be the 4th | 15:50 |
TheJulia | heh | 15:50 |
TheJulia | dtantsur: I was thinking the same thing | 15:50 |
rpittau | well let's be happy that the package name is still the same at least | 15:52 |
JayF | Iury and I are doing bifrost discussion and demos at my office hours in ~7 minutes @ youtube.com/jayofdoom | 15:53 |
opendevreview | Riccardo Pittau proposed openstack/bifrost master: Update shim-signed name for ubuntu jammy https://review.opendev.org/c/openstack/bifrost/+/874650 | 16:02 |
rpittau | ^ this should work for all the distributions we support, hopefully | 16:02 |
opendevreview | Julia Kreger proposed openstack/ironic-prometheus-exporter master: WIP Support extraction of ironic internal metrics https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/869509 | 16:22 |
espenfl | Dear everyone. I have been working a bit to get serial to work consistently for us (our configured servers sends ttyS1 over SOL so we need serial to go there). Have it all working up until the restart after the deploy ramdisk have copied the image (meaning the ipxe boot script also works over serial). But we have not yet found an easy way to pass kernel parameters to DIB | 16:29 |
espenfl | when building an image. Specifically for instance things related to the console. I think this is needed to make sure the deployed node also gives us serial, not just serial during deployment. Would be very happy for any comments or suggestions here. The element enable-serial-console uses getty etc. and does not give us serial on boot. Thanks in advance. | 16:29 |
opendevreview | Julia Kreger proposed openstack/ironic-inspector master: Use UTC for the timezone in functional tests https://review.opendev.org/c/openstack/ironic-inspector/+/874661 | 16:39 |
TheJulia | I could have sworn I've fixed ^ before | 16:43 |
TheJulia | anyway, with that, plus the already merged db test, I'm able to run python-ironic-inspector-client's functional test suite locally. tl;dr zed ironic-inspector will need to be released before the CI job works | 16:45 |
TheJulia | espenfl: so basically you need to edit the bootloader config on the image | 16:46 |
TheJulia | espenfl: you need something like https://github.com/openstack/diskimage-builder/blob/b4f768117f8805487799829da84883266e5575f2/diskimage_builder/elements/iscsi-boot/finalise.d/51-open-iscsi-config#L14 I think it would be good if you edited the grub element to support adding an argument to the grub command line | 16:48 |
opendevreview | Merged openstack/sushy-tools master: Ignore FileNotFoundError when ejecting virtual media image https://review.opendev.org/c/openstack/sushy-tools/+/874560 | 16:51 |
dtantsur | iurygregory: nice demo, great job! | 16:51 |
JayF | That was excellent iurygregory, and thank you dtantsur for chiming in and being active in chat | 16:51 |
dtantsur | sure thing, I hope I didn't annoy you too much :-P | 16:52 |
opendevreview | Riccardo Pittau proposed openstack/bifrost master: Update shim-signed name for ubuntu jammy https://review.opendev.org/c/openstack/bifrost/+/874650 | 16:55 |
JayF | dtantsur: quite the opposite. Annoying is a white sheet of paper for chat and a 0 viewers number staring back at me :D | 16:56 |
dtantsur | right :) | 16:57 |
rpittau | good night! o/ | 17:00 |
iurygregory | dtantsur, tks! | 17:02 |
fungi | rpittau: TheJulia: JayF: clarkb and i are travelling for meetings all week and ianw is otherwise unavailable, but i'm going to put it on the agenda for next week's opendev meeting to come up with a plan | 17:11 |
JayF | thank you o/ | 17:12 |
fungi | rough plan that i'll propose though is that we'd announce the intent to hand over control of the repository based on preliminary agreement from one of the people who currently has maintainership, and make sure we cc all the maintainer addresses just to give them every chance to object, then if we hear nothing before the scheduled handover we move forward with it | 17:25 |
TheJulia | fungi: ack, thanks | 17:25 |
espenfl | TheJulia: Awesome. Thanks for pointing me in the right direction. So we basically just make a new element based on for instance the bootloader and use that with whatever we need. Right? | 17:26 |
TheJulia | espenfl: I'd add it to the grub element personally and upload it back up to gerrit, you have a couple folks in this channel with core rights on diskimage-builder | 17:26 |
opendevreview | Dmitry Tantsur proposed openstack/ironic master: Restructure the inspector module in preparation for its expansion https://review.opendev.org/c/openstack/ironic/+/874677 | 17:43 |
espenfl | TheJulia: Happy to do so. Also opened this which somewhat on the same topic: https://bugs.launchpad.net/diskimage-builder/+bug/2007836. | 18:03 |
TheJulia | espenfl: ohhh, good find | 18:21 |
TheJulia | espenfl: I'd just propose a change to add the capability. ianw added that line 5 years ago, so I suspect nobody has brought up that case | 18:22 |
espenfl | Okey, I will try to look over the serial things so that it is more consistent when looking into it and submit a suggestion based on that. I also saw similar things here and there. | 18:27 |
TheJulia | diskimage-builder is much more "what works for people" driven | 18:33 |
opendevreview | Julia Kreger proposed openstack/ironic-specs master: WIP: Framework for DPU management/orchustration https://review.opendev.org/c/openstack/ironic-specs/+/874189 | 19:16 |
TheJulia | JayF: added words w/r/t chassis. | 19:16 |
stevebaker[m] | good morning | 19:23 |
JayF | TheJulia: a marked improvement; although admittedly I don't know enough about the hardware to have a strong opinion :/ | 19:25 |
NobodyCam | Good Morning Ironic Folks! | 19:28 |
JayF | o/ | 19:28 |
NobodyCam | hey hey JayF 0/ | 19:29 |
TheJulia | o/ NobodyCam | 19:32 |
TheJulia | NobodyCam: you should go read https://review.opendev.org/c/openstack/ironic-specs/+/874189 | 19:33 |
NobodyCam | 0/ TheJulia | 19:33 |
TheJulia | oh, you already did! | 19:33 |
NobodyCam | has it changed sense I added my +1? | 19:33 |
NobodyCam | ;p | 19:34 |
NobodyCam | hehehehe | 19:34 |
JayF | my +2 will cost a 4090; dm for address /s | 19:34 |
NobodyCam | LoL | 19:35 |
JayF | for, uh, important hardware testing | 19:35 |
TheJulia | KSP2 drops in just a few days | 19:35 |
TheJulia | and apparently, it will demand I get a new machine. | 19:35 |
NobodyCam | hehehehehe | 19:35 |
TheJulia | In regards to modify steps, or maybe I should just call it ?service steps?, is is does basically enable with our plugin model that someone *could* create a snapshot overlay module | 19:39 |
TheJulia | which could do things like "snapshot my stuff" | 19:39 |
JayF | I liked the idea of calling the states servicing/service wait | 19:39 |
TheJulia | The idea is sort of growing on me | 19:41 |
TheJulia | and in part because preventitive maintence or problem identification is still inherently service | 19:41 |
TheJulia | ... Not that I'm going to point the thermal camera at the physical server | 19:41 |
opendevreview | Julia Kreger proposed openstack/ironic-prometheus-exporter master: Support extraction of ironic internal metrics https://review.opendev.org/c/openstack/ironic-prometheus-exporter/+/869509 | 19:47 |
TheJulia | iurygregory: I finally figured out I swapped the conditional. Doh! | 19:47 |
iurygregory | TheJulia, yay! | 20:19 |
TheJulia | iurygregory: woots, passes, and the curl has combined metrics | 21:32 |
TheJulia | I do really like it grabs everything | 21:38 |
iurygregory | TheJulia, Nice! tomorrow I will take a look o/ | 22:42 |
TheJulia | o/ vanou | 23:00 |
vanou | Hi TheJulia o/ | 23:00 |
TheJulia | How are you doing today? | 23:01 |
vanou | Good. I had nice sleep :) | 23:01 |
TheJulia | Always good! :) | 23:01 |
vanou | I'll work on internal task | 23:02 |
vanou | After this review | 23:02 |
vanou | Thanks for review on that backport patch. Let's make sure what the backport means | 23:03 |
vanou | What point is unclear for you? | 23:03 |
TheJulia | What I'm struggling to understand is how the first patch is needed for the second patch. I don't see where it is used | 23:04 |
TheJulia | so I'm wondering if I'm just understanding something, or if there is context which is not making it through | 23:04 |
vanou | Ah. OK. I explain | 23:04 |
vanou | When I make submit first draft on first patch, function of version checking and storing in DB will be used on second patch. However after discussion with you and JayF, such functionality is not needed on second patch because second patch uses try-fallback approach. | 23:07 |
vanou | So there is no functionality/code in first patch which second patch needs to work. | 23:09 |
TheJulia | so we could just detach the second patch from the first? | 23:09 |
vanou | Yes. | 23:10 |
vanou | When we dertermine to do try-fallback approach on second patch, we could decouple these 2 patches. | 23:11 |
vanou | This is context on these 2 patches. | 23:14 |
TheJulia | okay, then yeah, decoupling makes sense in my mind | 23:14 |
TheJulia | the latter patch just makes sense, the first patch.... *really* that is just a verify step which can be considered a feature | 23:15 |
TheJulia | I did a rebase of the second patch locally, and I'll share the diff I got, all which I believe is not needed by the second patch. | 23:15 |
TheJulia | vanou: https://paste.openstack.org/show/bAa8YyvMmdmFwXhAJK9n/ | 23:16 |
vanou | Yes. First patch just provides verify step to check http/https connection and, if fail, warns that failure. | 23:17 |
vanou | Thanks for diff. Yes code of first patch is not needed by second patch | 23:18 |
vanou | However to tell operator the version of bmc firmware doesn't support https, first patch is helpful I think | 23:19 |
vanou | ^sorry s/https/http | 23:20 |
vanou | If you have another things you want to make sure, please tell me. | 23:28 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!