| shermanm | ran into a bit of a *fun* bug, it seems that federated accounts can't auth with system scope in keystone right now. https://review.opendev.org/c/openstack/keystone/+/979789 | 02:35 |
|---|---|---|
| TheJulia | shermanm: are you planning on attending the PTG? Asking because we have been talking of maybe non-keystone backends | 03:17 |
| shermanm | maybe, it's unfortunately a travel-heavy week for me but I can try to drop in | 03:19 |
| opendevreview | Jacob Anders proposed openstack/sushy master: settings: use SettingsObject ETag for updates https://review.opendev.org/c/openstack/sushy/+/1008742 | 05:49 |
| opendevreview | Jacob Anders proposed openstack/sushy master: settings: use SettingsObject ETag for updates https://review.opendev.org/c/openstack/sushy/+/1006671 | 05:52 |
| kubajj | Good morning Ironic! o/ | 06:16 |
| *** kukacz_ is now known as kukacz | 08:18 | |
| kukacz | hi folks, does anyone have experience with Dell iDRAC 8 blades incomplete loading ISO image of IPA using virtual media mount from remote share? The issue looks so that the boot process on server starts, loads some bytes from Ironic httpd (visible in Ironic logs) and then stops. Both UEFI and legacy BIOS. | 10:46 |
| mnasiadka | kukacz: I’ve seen the same some time ago, iDRAC 8 doesn’t seem to be state of the art ;-) | 11:38 |
| kukacz | @mnasiadka, sure it doesn't. I understand Redfish was just introduced into iDRAC in that relase. Do you maybe remember any hints or workarounds that could potentially help to bring redfish/vmedia working there? | 11:50 |
| mnasiadka | kukacz: I ended up retrying provisioning forever and it worked after Nth time, but I only had 3 servers with idrac 8 to provision (and sort of one time) - so it wasn’t that problematic | 11:50 |
| kukacz | thanks! Well, repeated provisioning does not seem to work in my case. | 11:58 |
| kukacz | it seems to be somehow related to http requests with large offset seeks in the remote image | 11:59 |
| kukacz | AI helped build a single-use ISO with all content ordered in the access sequence, which worked for legacy BIOS boot | 11:59 |
| kukacz | the same did not work with UEFI though. Anyway, that's far from a reliable permanent solution. | 12:01 |
| TheJulia | good morning | 13:01 |
| TheJulia | kukacz: When booting, does the reading start after the OS gets booted? | 13:02 |
| TheJulia | kukacz: what version of firmware on the idrac8 ? | 13:02 |
| TheJulia | kukacz: another question: do you have keepalive enabled or disabled in the endpoint serving up the iso? Wait, you said remote share, are you using some other backing protocol? | 13:03 |
| TheJulia | shermanm: fyi, https://etherpad.opendev.org/p/ironic-ptg-2027.1 | 13:06 |
| kukacz | TheJulia, good morning! It's latest available idrac8 fw 2.86.86.86. Keepalive disabled. It's IrSO managed Ironic instance I am using as part of metal3/BaremetalOperator setup for CAPI k8s clusters. | 13:10 |
| sathieu | Hello, | 13:11 |
| kukacz | TheJulia, and it's standard Ironic httpd endpoint serving the image using redfish-controlled vmedia setup. It's basically http URL the idrac uses for accessing the image, sending series of http request. | 13:11 |
| TheJulia | I've heard some odd things from 2.86.86.86, but given idrac8s also all exited support windows back in ... 2020-2021 afaik and they announced EoS for updates, I wouldn't expect any new releases either, known version being >=2.70.70.70. | 13:12 |
| TheJulia | hello sathieu | 13:12 |
| TheJulia | kukacz: I'd honestly look to see if keepalive changes the behavior at all, but UEFI on dell gear with idrac8 is also super weird and painful. :( | 13:13 |
| sathieu | I plan to use Ironic Standalone Networking. Is it possible to shut an interface while in tenant network, and shut another one when in -for example- provisioning network ? | 13:14 |
| kukacz | TheJulia, sure I was afraid of that. Just asking if someone here might have a known workaround. So you mean the version 2.70.70.70 has been confirmed to work in similar setup? | 13:14 |
| sathieu | I'm asking this, because we have different network switches for admin stuff (like provisioning) and end-user traffic. I want to use only one at a time. | 13:15 |
| TheJulia | kukacz: 2.70.70.70 was the first known and dell validated version. It was also announced to be the very last idrac8 drop at one point, and they have done a couple more since then for some unknown reasons. | 13:15 |
| TheJulia | I know in that, some oddities have appeared as well | 13:16 |
| TheJulia | sathieu: That is basically a entirely different model of use. I guess one might be able to achieve it with trait based networking, but provisioning/clearing is largely geared at reconfiguring all ports while moving vlans around where it sounds like you want a model where your maintaining separate staticly configured vlans and wanting toggle the machine back and forth utilizing "shut/no shut", which is just not in the model today. I | 13:18 |
| TheJulia | guess I'd more so want to understand why maintaining separate network fabrics that way when why not just use a specific vlan? | 13:18 |
| kukacz | TheJulia, what do you expect from enabling the keepalived? I am not very familiar with that component - I thought of keepalived only as an VRRP implementation handling LB IP assignment to healthy endpoint. | 13:19 |
| TheJulia | kukacz: not keepalived, http keepalive | 13:19 |
| TheJulia | https://en.wikipedia.org/wiki/HTTP_persistent_connection | 13:20 |
| kukacz | TheJulia, aha, sorry. missed that. I'll check that. | 13:20 |
| TheJulia | I don't know if it supports it, but apps can get weird if they are expecting keepalive to work and sockets are getting closed | 13:20 |
| * TheJulia did some work on an early WAF where we found browsers and proxies which would do fun things like "expect keepalive to always work" | 13:21 | |
| TheJulia | (so, very, much fun. | 13:21 |
| TheJulia | ) | 13:21 |
| sathieu | we have different network fabric to physically isolate networks. If a vulnerability is found on a network fabric that can allow to send a packet to another network. | 13:22 |
| TheJulia | so, I guess what you need then is enhancement to be able to do specific filtering for such port selection then, unfortunately I don't think that exists today | 13:23 |
| TheJulia | alegacy: clif: ^^ | 13:24 |
| sathieu | I think we'll create an unrouted vlan, and move the port there | 13:24 |
| TheJulia | ironic-cores, if you have any questions/concerns about the schedule for the PTG, raise it before the meeting if possible: https://etherpad.opendev.org/p/ironic-ptg-2027.1 | 13:25 |
| TheJulia | sathieu: that should work, fwiw, clif and alegacy are deep in the networking areas, but its also a little early for them still | 13:26 |
| clif | TheJulia: I'm not fully awake, but you could set the category on every port to distinguish between tenant/provisioning/etc and then TBN can filter based on that? | 13:28 |
| clif | or is this port selection taking place at a point where tbn does not currently apply? | 13:29 |
| TheJulia | clif: dunno, its not in my memory recall, which is why I tagged you :( | 13:30 |
| TheJulia | clif: sathieu likely needs to explore TBN | 13:31 |
| TheJulia | (Trait Based Networking) | 13:31 |
| sathieu | ok, thanks. I will read more about TBN. | 13:32 |
| * TheJulia attempts to wake up with more coffee | 13:33 | |
| kukacz | TheJulia, did you have any specific keepalive enabling parameter on mind? I am not finding any real switch or parameter in Ironic and iDRAC docs and interfaces. | 13:35 |
| TheJulia | kukacz: I was thinking in the http server. If not encrypted you *could* likely take a look at a packet capture and see if its trying to use a socket the server has closed out | 13:36 |
| kukacz | TheJulia, it is TLS encrypted actually. Though I did not find any TLS/certificate related issues in the http traffic (httpd logs only), I haven't tried disabling TLS yet. | 13:39 |
| TheJulia | Might be worth a try, and would allow you to take a look under the "http cover" | 13:47 |
| alegacy | sathieu: just want to make sure I understand... you want to only program and enable nic1 during provisioning (w/ nic2 disabled at the switch), and then later only program and enable nic2 while then node is active (with nic1 disabled at the switch)? whereas today, nic1 and nic2 are programmed/enabled for provisioning, and also for final deployment. | 13:47 |
| TheJulia | fwiw, it feels like a fundimentally different network_interface model to me | 13:49 |
| TheJulia | since its sort of toggling from one side to another | 13:49 |
| alegacy | I could see maybe a middle ground where we could say only the primary nic is used for prov/insp/rescue/servicing/etc... but secondary nics are also used for tenant networks. | 13:55 |
| opendevreview | Michal Nasiadka proposed openstack/bifrost master: Add experimental arm support for Ubuntu/CentOS https://review.opendev.org/c/openstack/bifrost/+/1008804 | 14:02 |
| opendevreview | Michal Nasiadka proposed openstack/bifrost master: Add experimental arm support for Ubuntu/CentOS https://review.opendev.org/c/openstack/bifrost/+/1008804 | 14:03 |
| opendevreview | Michal Nasiadka proposed openstack/bifrost master: Add experimental arm support for Ubuntu/CentOS https://review.opendev.org/c/openstack/bifrost/+/1008804 | 14:04 |
| opendevreview | Michal Nasiadka proposed openstack/bifrost master: Add experimental arm support for Ubuntu/CentOS https://review.opendev.org/c/openstack/bifrost/+/1008804 | 14:12 |
| opendevreview | Michal Nasiadka proposed openstack/bifrost master: Add experimental support for ARM64 hosts on Ubuntu/CentOS https://review.opendev.org/c/openstack/bifrost/+/1008804 | 14:13 |
| TheJulia | alegacy: I guess it all boils down to the overall expected operating model | 14:14 |
| opendevreview | Michal Nasiadka proposed openstack/bifrost master: Experimental support for ARM64 hosts on Ubuntu/CentOS https://review.opendev.org/c/openstack/bifrost/+/1008804 | 14:14 |
| alegacy | TheJulia: agreed. | 14:16 |
| JayF | TheJulia: fwiw tbn is entirely in the neutron network interface | 14:35 |
| JayF | You don't need inference magic for standalone networking since you can just declaratively say what you want, how ironic | 14:35 |
| JayF | **in Ironic | 14:35 |
| TheJulia | true, I guess as long as shutdown is set, one could manually toggle it all out in standalone just as long as you never allow non-administrative access to ironic | 14:36 |
| JayF | It certainly is an interesting idea to use left-side and right-side interfaces for this. It's probably a pretty cheap way to retrofit something that doesn't have smart switches. | 14:37 |
| JayF | Certainly not something that any of our models currently cover | 14:37 |
| JayF | But even if you were trying to do this without smart switches, someone in-band being able to "up" the provisioning interface would kill any security benefit | 14:38 |
| TheJulia | ... switches which are not smart these days?! | 14:45 |
| TheJulia | looks like there are some limited SMB 16-ish port switches which are not considered "unmanaged", 2.5g line rate, so semi-reasonable I guess | 14:48 |
| opendevreview | Takashi Kajinami proposed openstack/networking-generic-switch master: Drop sys_platform marker for win32 system https://review.opendev.org/c/openstack/networking-generic-switch/+/1008812 | 14:51 |
| sathieu | alegacy: yes | 14:56 |
| sathieu | I want nic1 for prov/insp/rescue/servicing/... and nic2 for tenant network. But one at a time | 14:57 |
| JayF | sathieu: What is the motivational factor behind wanting to use the separate NICs? Security? Performance? | 14:58 |
| sathieu | Security | 14:59 |
| sathieu | Actually, this is a recommandation of our security experts to have a physically different network | 15:00 |
| TheJulia | There is a class of user who doesn't view logical delineation as sufficient security controls for switch, but even in the environment I worked like a decade we finally got vlans to be acceptable approaches | 15:00 |
| TheJulia | We meeting today? | 15:01 |
| JayF | Yeah, this is one of those things where picking that kinda architecture would make it different enough I'd worry more about the gaps it creates than the ones it closes | 15:01 |
| JayF | yup, idr who is running it | 15:01 |
| TheJulia | #startmeeting ironic | 15:01 |
| opendevmeet | Meeting started Mon Oct 5 15:01:40 2026 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:01 |
| opendevmeet | The meeting name has been set to 'ironic' | 15:01 |
| kubajj | o/ | 15:01 |
| TheJulia | I think, it might be me? Or someone else want to? | 15:01 |
| JayF | #topic Announcements/Reminders | 15:02 |
| Mahnoor | o/ | 15:03 |
| JayF | #note We released OpenStack 2026.2 last week. Good job. | 15:03 |
| TheJulia | #chair JayF | 15:03 |
| opendevmeet | Current chairs: JayF TheJulia | 15:03 |
| JayF | #topic Announcements/Reminders | 15:03 |
| JayF | #note We released OpenStack 2026.2 last week. Good job. | 15:03 |
| JayF | #note Thanks to cardoe for repping Ironic at the OpenInfra Live | 15:03 |
| JayF | #note PTG is next week! Please take time to rest up this week, review the etherpad, and bring your brains! | 15:03 |
| JayF | #link https://etherpad.opendev.org/p/ironic-ptg-2027.1 | 15:03 |
| cid | o/ | 15:04 |
| estherd[m] | o/ | 15:04 |
| JayF | I'd especially ask core reviewers and approvers, or generally anyone who is expert in a subsystem, to look at the architectural sharing portion scheduled for 1400 UTC Wednesday | 15:04 |
| JayF | and volunteer to teach a short 10 minute session on that subsystem | 15:04 |
| JayF | feel free to add one if you think it's needed, either as one you can give or one you need to hear | 15:05 |
| JayF | TheJulia: fwiw IDK who was signed up to run the meeting, but I'd rather JFDI than figure it out :D | 15:05 |
| JayF | Any other comments about PTG? | 15:05 |
| TheJulia | JayF: I appreciate it, I'm dealing with very unhappy sinuses | 15:05 |
| JayF | TheJulia: we had a special meeting of the unhappy club at 4am this morning over here, when the smoke alarm ran low on battery and the dog ran high on panic :D | 15:06 |
| JayF | I'm going to hope folks read the PTG notes even though it [crickets] in here :D | 15:07 |
| Mahnoor | I read your Friday msg about architectural session, Jay, I will add any questions/topics I can upfront | 15:07 |
| JayF | #topic Working Group Updates | 15:07 |
| JayF | I doubt there's a meaningful update for anything here. | 15:07 |
| JayF | Async IO working group is likely doing PTG planning | 15:07 |
| JayF | Ironic coresec team has nothing public to report; I'll note that the moratorium on advisories is lifted since the release is done | 15:07 |
| JayF | speak up quickly if you have something to add here | 15:08 |
| * TheJulia calls for proceeding | 15:09 | |
| JayF | No discussion topics, skipping. | 15:09 |
| JayF | #topic Bug Deputy Updates | 15:09 |
| JayF | TheJulia: is listed as the bug deputy | 15:09 |
| TheJulia | I think Mahnoor took care of the past week, I took a look at items the week before | 15:09 |
| Mahnoor | Yep, I took a look on Friday, updated the agenda notes | 15:10 |
| TheJulia | Thanks Mahnoor! | 15:11 |
| Mahnoor | Julia was looking at older items to try and lighten the backlog, I believe? | 15:11 |
| Mahnoor | No problem :) | 15:11 |
| TheJulia | Yup, I closed out some older items which didn't get closed out | 15:11 |
| Mahnoor | Thats nice, thank you! | 15:11 |
| JayF | I suggest we just forgo a bug deputy the next two weeks | 15:12 |
| JayF | so contributors can focus on ptg | 15:12 |
| TheJulia | ++ | 15:12 |
| cid | ++ | 15:13 |
| JayF | #note No bug deputy assigned until post PTG. | 15:13 |
| JayF | There are two RFEs listed for review; unsure if they are old? | 15:14 |
| JayF | #link https://bugs.launchpad.net/ironic/+bug/2168519 | 15:14 |
| TheJulia | 1-2 weeks, accordingly | 15:14 |
| JayF | 2168519 seems like an obvious enhancement | 15:14 |
| JayF | but I do think we should talk some about the shape of the change in that RFE, moreso than we have been | 15:15 |
| TheJulia | I think that one is reasonable, however... its an entirely different tool/operator model and I'm unsure if any of us can just magically do so | 15:15 |
| JayF | is this another interface? Making container interface different in all cases? | 15:15 |
| TheJulia | likely different runtime interface driver which dicates local configuration modeling | 15:15 |
| JayF | I would suggest we put off officially approving the RFE until those questions are answered; I think this config is already pretty complex and am nervous about which dimension this would grow off of | 15:15 |
| TheJulia | since its local networking, which is a bit weird. | 15:15 |
| TheJulia | yeah, without a bit more detail, that one is... difficult | 15:16 |
| JayF | yeah if it's a different implementation of the interface, I'm +2 | 15:16 |
| JayF | if it's container with 15 flags to flip just right to make it more secure... eh | 15:16 |
| TheJulia | Different networking style on the host, where kolla launches containers directly from a runtime | 15:16 |
| JayF | ack, I'll mark it approved and make a comment saying this should be a net-new interface | 15:17 |
| JayF | (and we're OK with it being kolla-specific, I'd assume) | 15:17 |
| TheJulia | likely, I don't remember offhand the slicing of the driver | 15:17 |
| TheJulia | but yeah, If they want to post a patch, I'm good with that | 15:17 |
| JayF | #link https://bugs.launchpad.net/ironic/+bug/2168956 | 15:18 |
| JayF | This one... (sorry kubajj) -- I am kinda -1 on | 15:18 |
| kubajj | I understand your point | 15:19 |
| JayF | oh, this isn't the one I thought it was? | 15:19 |
| kubajj | I think it is | 15:19 |
| JayF | I think this desc was edited to be more palatable :) | 15:19 |
| JayF | and it is more palatable now lol | 15:19 |
| kubajj | yes, John has made some changes | 15:19 |
| JayF | I would prefer a model where we actually set cleaning and provisioning network *to the same neutron network* | 15:20 |
| TheJulia | its actually super similar to what rackspace did ages ago, except it doesn't pre-bake an image automatically | 15:20 |
| JayF | if that security boundary is being broken, why erect it at all in this use case? | 15:20 |
| kubajj | yes, that would be great, but apparently, we have to deal with cleaning network as dirty | 15:20 |
| JayF | TheJulia: clif actually wrote that code, and it was quite a bit different (mainly because Ironic would just let agents heartbeta forever regardless of state) | 15:21 |
| TheJulia | I sort of like the idea, your staging the hosts as on, heartbeating, waiting for the deploy request on the provisioning network, which better aligns with GPU capacitors | 15:21 |
| JayF | oh yeah | 15:21 |
| * JayF is really anchored to that original writing | 15:21 | |
| JayF | this never puts an unclean machine on the provisioning network | 15:21 |
| * TheJulia hands JayF moar coffee | 15:22 | |
| TheJulia | yup | 15:22 |
| JayF | so it actually preserves the security barrier | 15:22 |
| kubajj | I hope it doesn't - that's what I tried to go for :D | 15:22 |
| JayF | this feels OK? but I am nervous about something like this which can have serious security impacts | 15:22 |
| JayF | and bluntly is a feature so shiny everyone will want it yesterday | 15:23 |
| JayF | I wonder if we should spec it just so we can get a best case "1.0" release on it | 15:23 |
| JayF | because this is a switch half of our users are gonna wanna flip | 15:23 |
| JayF | kubajj: I review a smidge more aggressively when I know my downstream is gonna love a feature b/c it means I'm gonna be subjected to a finger-waggle if it doesn't work :D | 15:23 |
| kubajj | JayF: that's why we wanted to discuss it at the PTG - spec is also up for review, happy to take your feedback | 15:25 |
| JayF | i really do need coffee, it's linked from the bug too | 15:25 |
| JayF | I'll leave that tab open to review it. After I've had coffee and breakfast. /me points to earlier message about 4am wakeups as a lame excuse | 15:26 |
| kubajj | no worries | 15:26 |
| JayF | since that's got a spec, no decision to be made in meeting | 15:26 |
| JayF | #topic Open Discussion | 15:26 |
| kubajj | thanks for having a look | 15:26 |
| JayF | Anything for Open Discussion? | 15:26 |
| JayF | One note: goes without saying there's no meeting next week | 15:26 |
| JayF | I'll email about it | 15:26 |
| TheJulia | I sent a note to the mailing list regarding the ptg etherpad | 15:26 |
| TheJulia | separately, I also added two items to the ops etherpad (https://etherpad.opendev.org/p/ops-devs-qanda-2026) | 15:27 |
| JayF | thanks | 15:27 |
| JayF | Anyone wanna volunteer to chair the October 19th 2026 meeting (post-PTG) | 15:28 |
| TheJulia | I think the schedule is fairly solid, I had to shuffle things a little because of timing with Cinder and proposed what seemed to be a possible time window | 15:29 |
| TheJulia | I can | 15:29 |
| JayF | #action TheJulia to chair October 19 meeting. October 12 meeting cancelled. | 15:29 |
| JayF | Thanks all for coming to the meeting, gonna close it up. | 15:31 |
| JayF | #endmeeting | 15:31 |
| opendevmeet | Meeting ended Mon Oct 5 15:31:20 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:31 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-10-05-15.01.html | 15:31 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-10-05-15.01.txt | 15:31 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/ironic/2026/ironic.2026-10-05-15.01.log.html | 15:31 |
| cardoe | clif: trying to mess further with TBN and I'm stuck... | 16:41 |
| cardoe | So if I've manually created a port group before and I wanna attach it... I'm not sure how to do that. | 16:41 |
| cardoe | https://www.irccloud.com/pastebin/YOuRNQFO/ | 16:42 |
| cardoe | That's the entirety of my TBN config right now. | 16:42 |
| cardoe | openstack baremetal node vif attach be5191a4-3001-475b-adb2-3ea37cc21b2b db4a3edf-a4b1-4297-9d88-c83308ab5989 --portgroup-uuid e14bf067-ace0-439b-8c32-e185a18227c9 | 16:43 |
| cardoe | Is what I'm running | 16:43 |
| cardoe | https://www.irccloud.com/pastebin/h0L0g2eA/ | 16:43 |
| cardoe | It's only ever selecting one of the two ports that make up that port group and never the port group itself. | 16:44 |
| cardoe | Also looking at https://docs.openstack.org/ironic/latest/references/trait-based-networking/tbn-config-file.html#trait-layout the documented example is impossible for it to work. port groups don't have a vendor field which is what lead to the bug I reported. | 16:45 |
| JayF | cardoe: attach_portgroup is a separate action IIRC | 16:45 |
| * JayF checks docs | 16:46 | |
| JayF | > attach_portgroup - Attach (portgroup, network) pairs that pass this action’s filter expression. | 16:46 |
| JayF | yep, just below your link there | 16:46 |
| cardoe | hrm.. okay well the documented example couldn't ever work then. Cause the example has you using attach_port for a portgroup. | 16:46 |
| JayF | lol | 16:46 |
| JayF | valid | 16:46 |
| clif | :( | 16:46 |
| clif | let's fix the docs! | 16:46 |
| cardoe | That works for me. | 16:47 |
| cardoe | I pointed my folks at the docs. | 16:47 |
| cardoe | fwiw https://review.opendev.org/c/openstack/ironic/+/1008516 is what I even needed to run to not hit the 500 error | 16:47 |
| cardoe | So we're testing stable/2026.1 plus that patch right now. | 16:47 |
| cardoe | Just trying to iterate through how we can roll out TBN. | 16:48 |
| clif | I'm +2 on it, let's get someone else on it | 16:48 |
| * cardoe pokes JayF | 16:48 | |
| clif | I'm excited | 16:48 |
| JayF | cardoe: I don't think we have a way to express (when reviewing 100851), I want a portgroup consisting of ports made by $vendor | 16:48 |
| clif | I'll fix those docs, the example *is* wrong now that I re-read it | 16:49 |
| JayF | cardoe: which is a design issue we can address, but is a downside of the fix path chosen | 16:49 |
| JayF | (another fix path could be: evaluate port.vendor as the vendor of the ports that are members, with an error if the port vendors mismatch) | 16:49 |
| cardoe | You don't have a way to express that. | 16:49 |
| cardoe | But right now it throws a 500 error even if you're not using a vendor at all. | 16:49 |
| cardoe | We only use category right now. We have some ports with a category of "network" and others that are unset. | 16:50 |
| cardoe | That's our only test case | 16:50 |
| cardoe | or I should say... dip of our toe in the TBN waters | 16:50 |
| JayF | yeah really if you need to care about vendor of the individual nics | 16:52 |
| JayF | you should be using group-and-attach | 16:52 |
| JayF | otherwise you can just put some metadata on your portgroup to match | 16:52 |
| clif | dynamic portgroups ~_^ | 17:01 |
| cardoe | Yeah I haven't even gotten to dynamic portgroups with the team. | 17:02 |
| cardoe | https://www.irccloud.com/pastebin/lKP1f6dV/ | 17:04 |
| cardoe | That's what I'm gonna have them re-test with. | 17:04 |
| cardoe | My intention is to have them update the docs and work with dynamic portgroups. | 17:06 |
| opendevreview | Merged openstack/ironic master: Fix TBN Portgroup creation accessing nonexistent vendor field https://review.opendev.org/c/openstack/ironic/+/1008516 | 17:46 |
| cardoe | would something like "openstack baremetal port group add/remove" make sense as commands to add a port to a port group? | 17:51 |
| cardoe | Apparently it wasn't apparently that "openstack baremetal port set --port-group <uuid> <uuid>" was the process. | 17:51 |
| cardoe | I'm not talking about replacing just in addition to for user experience. | 17:52 |
| cardoe | add/remove could take 1 port group and 1 or more ports to add | 17:53 |
| cardoe | what about "openstack baremetal node list --instance-id <uuid>" or should it be --instance-uuid? We've got a --instance-name flag. | 18:02 |
| JayF | I think --instance <uuid-or-name> works, iirc? | 18:06 |
| opendevreview | Merged openstack/ironic master: Make TBN comparisons against unset variables never match https://review.opendev.org/c/openstack/ironic/+/1008517 | 18:15 |
| cardoe | JayF: nope the flag is --instance-name and it doesn't filter uuid | 18:34 |
| cardoe | Well getting closer with TBN and port groups... Unable to complete operation on port 06edec49-b86b-4359-b61a-32e996c44c9e, port is already bound, port type: other, old_mac fa:16:3e:98:28:d2, new_mac 14:23:f3:f5:24:a1 | 18:35 |
| cardoe | That's what you get back from the vif attach call | 18:35 |
| cardoe | But it actually did work in the end. | 18:35 |
| cardoe | it just returns an error message. | 18:36 |
| cardoe | And nova treats the error as a failure. | 18:36 |
| JayF | that usually means the vif had already been attached or something | 18:36 |
| JayF | I would be 100% sure that wasn't an enviornmental leftover from previous failures | 18:36 |
| JayF | TheJulia: sorry, I -1'd https://review.opendev.org/c/openstack/ironic/+/1008314/1#message-9c7a254416d30720dc83aff53db59be1385f01a1 -- if you want me to execute the change to the error message I request, I can | 19:27 |
| JayF | I'm basically thinking: if I have access to start deployments in ironic, I can extract the key_id for any image I want | 19:28 |
| TheJulia | The assumption there is that the risk is someone somehow can't see the field, I guess it maeks sense to yank the bit in the error, if you have time that woudl be awesome since I'm about to jump on a meeting and honestly I'd rather be in bed since I've got a cold/evil sinus thing going on | 19:29 |
| JayF | yep I'll patch it, that's why I offered | 19:30 |
| TheJulia | much appreciated | 19:30 |
| * TheJulia goes and joins last call of the day | 19:30 | |
| JayF | it's mildly farfetched but at this point I don't wanna add any more potential shenanigans | 19:30 |
| TheJulia | fair | 19:30 |
| opendevreview | Jay Faulkner proposed openstack/ironic master: Reject Glance encrypted images during validation https://review.opendev.org/c/openstack/ironic/+/1008314 | 19:36 |
| *** darmach5 is now known as darmach | 21:04 | |
| *** Unknown123 is now known as Mike-- | 21:04 | |
| opendevreview | Doug Goldstein proposed openstack/ironic stable/2026.2: Fix TBN Portgroup creation accessing nonexistent vendor field https://review.opendev.org/c/openstack/ironic/+/1008887 | 23:36 |
| opendevreview | Doug Goldstein proposed openstack/ironic stable/2026.1: Fix TBN Portgroup creation accessing nonexistent vendor field https://review.opendev.org/c/openstack/ironic/+/1008888 | 23:37 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!