Friday, 2025-04-04

opendevreviewJunya Noguchi proposed openstack/ironic master: Add image build method for verified OS.  https://review.opendev.org/c/openstack/ironic/+/94631802:03
opendevreviewVasyl Saienko proposed openstack/ironic master: Allow to use internal APIs during deployment  https://review.opendev.org/c/openstack/ironic/+/94632105:37
opendevreviewVasyl Saienko proposed openstack/ironic master: Allow to use internal APIs during deployment  https://review.opendev.org/c/openstack/ironic/+/94632105:41
fricklerJayF: I'm not sure I understand the result: the issue is still there and unknown? and the learning is that reproduction needs a fresh environment?05:42
AmarachiOrdor[m]Good Morning Ironic! Wishing everyone a good day!06:59
freemanboss[m]Good morning ironic \o/07:12
rpittaugood morning ironic! happy friday ! o/07:17
rpittauJayF:  resnmp: what's the current issue and the status? :)07:40
rpittaucid: when you got a moment can you please rebase https://review.opendev.org/c/openstack/ironic/+/944769 on top of master ?08:01
cidrpittau: Will do that in a moment.08:04
rpittauthanks!08:06
fricklerrpittau: the issue is that ironic unit tests are failing with the most recent upper-constraints updates. I just found the comment https://review.opendev.org/c/openstack/requirements/+/943089/comment/0ef049e2_665e5ca1/ but I'm not sure whether that is the latest status08:17
rpittaufrickler: thanks, checking now08:19
rpittaufrickler, JayF, I think all pysnmp-modules alter than 6.1.4 are simply broken, at least regarding hlapi module, which is basically what JayF found08:29
rpittauI'm adding a comment in the UC change08:29
opendevreviewcid proposed openstack/ironic master: A new 'description' field to the port object  https://review.opendev.org/c/openstack/ironic/+/94476908:33
* cid that was not right.08:34
fricklerrpittau: ah, sorry, I should have mentioned it, (and I hope also JayF wasn't looking only at the wrong issue) pysnmp-lextudio is pinned by https://review.opendev.org/c/openstack/requirements/+/907665/79, but even then there is a failure there https://zuul.opendev.org/t/openstack/build/8ed6f74b8e8b4e4ba3508ba2e0a1164908:46
fricklerso likely the issue is that pyasn1_modules===0.4.2 is no longer working with our pinned pysnmp-lextudio version08:46
fricklerwe can pin both for a while, but maybe sometime during this cycle ironic should either find a real fix or indeed throw the whole thing out. I also have no idea how distros should handle this. zigo might know08:47
opendevreviewHarald Jensås proposed openstack/sushy-tools master: Pass image ID to _attempt_delete_image_local_file  https://review.opendev.org/c/openstack/sushy-tools/+/94632608:48
opendevreviewMerged openstack/bifrost unmaintained/2023.1: Switch to unmaintained/2023.1  https://review.opendev.org/c/openstack/bifrost/+/94554209:02
zigofrickler: I'm not sure I understand, what's the issue exactly?09:03
zigoIn Debian, we have python3-pyasn1-modules 0.4.1 only.09:04
zigoAlso, I'm completely lost with the -lextudio thingy, I'd love it if someone could explain how it went, which packages should be replaced, etc.09:04
fricklerzigo: but you somehow managed to package ironic, right?09:05
zigoYeah.09:05
rpittaufrickler: the issue is different though09:06
frickleriiur lextudio first was a fork because the original asn1 and snmp modules were kind of abandoned. and now they took over the original pkg names and the lextudio versions are deprecated again. 09:06
rpittauI think it's 2 issues here09:06
zigoYeah, the original author passed away.09:07
zigoBut should we get rid of *all* lextudio packages now?09:07
zigoI've read in this channel that some should stay, not sure which ones.09:07
rpittauzigo: the problem is that the lextudio pkgs are good until a certain version, which is newer of the old unmaintained ones09:07
rpittauI will add another comment in the UC patch09:07
fricklerrpittau: it would be nice if you could also update https://etherpad.opendev.org/p/requirements-blockers , there's a mention of asyncio there?09:09
rpittaufrickler: can I just update the UC patch with the "working" versions to verify my tests?09:09
rpittaufrickler: ack09:09
fricklerrpittau: which are the working versions for you09:09
rpittaupyasn1 0.4.1 and pysmp_lextudio 6.1.409:10
fricklerrpittau: you could either update https://review.opendev.org/c/openstack/requirements/+/907665/79 or put another patch on top of that09:10
fricklerah, 0.4.1 is known working, but not latest, yes. if that is what you want to stick to for now, then I can update myelf09:10
rpittauyeah09:10
rpittauI've updated the etherpad09:11
zigoThat's what we have in Debian Unstable.09:11
rpittauzigo: and keep that! :D09:11
fricklerzigo: so latest pyasn1 version would be 0.4.2, but that breaks unit tests. as long as you have no pressure to update, we might be fine09:11
rpittauwe were wondering to deprecate snmp in ironic, I think it's time we act on that unless we find volunteers to maintain the snmp libraries09:12
rpittaupysnmp that's it09:12
zigoWe're in freeze in 11 days, so I don't think anyone will upgrade! :)09:13
rpittaugreat :)09:13
opendevreviewMerged openstack/ironic master: devstack bindep - [platform:rpm]  https://review.opendev.org/c/openstack/ironic/+/89381309:18
opendevreviewVerification of a change to openstack/ironic master failed: [devstack] Allow deploy environment with portgroups  https://review.opendev.org/c/openstack/ironic/+/94061109:18
opendevreviewcid proposed openstack/ironic master: A new 'description' field to the port object  https://review.opendev.org/c/openstack/ironic/+/94476909:20
cidrpittau, ^^ this should be good (?)09:21
queensly[m]masghar: I saw your comment on the patch regarding my message been overwritten. Should I go ahead and edit it?09:37
opendevreviewMerged openstack/ironic-tempest-plugin master: Make sure fixed IPs are different for multitenancy tests  https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/94241410:31
opendevreviewHarald Jensås proposed openstack/sushy-tools master: Pass image ID to _attempt_delete_image_local_file  https://review.opendev.org/c/openstack/sushy-tools/+/94632610:49
opendevreviewVerification of a change to openstack/ironic master failed: [devstack] Allow deploy environment with portgroups  https://review.opendev.org/c/openstack/ironic/+/94061111:32
rpittaucid: yes, thanks :)12:16
JayFfrickler: That's an accurate description of what's actually going on. I chased my own tail for about 2 hours yesterday because I was confused13:07
opendevreviewMerged openstack/ironic master: A new 'description' field to the port object  https://review.opendev.org/c/openstack/ironic/+/94476913:25
TheJuliaGood morning folks13:45
opendevreviewcid proposed openstack/ironic-python-agent master: WIP: Eventlet Removal- Oslo's wsgi server to uWSGI  https://review.opendev.org/c/openstack/ironic-python-agent/+/94609116:38
opendevreviewAmarachi Ordor proposed openstack/bifrost master: docs: updated test guide, improve how-to clarity, add troubleshooting tips  https://review.opendev.org/c/openstack/bifrost/+/94635216:57
opendevreviewMerged openstack/ironic master: [devstack] Allow deploy environment with portgroups  https://review.opendev.org/c/openstack/ironic/+/94061117:11
-opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily for a patch release update17:16
TheJuliaJayF: you around ?17:56
JayFyes17:57
JayFwhat's up?17:57
TheJuliaso I'm toying with this idea that maybe we do just bind the port with a host_id, and then let it the port update/rebind as part of the workflow if we only send along a host_id and nothing else17:57
TheJuliai.e. a blank binding profile, just the host_id17:58
TheJuliano Local Link *should* shortcircuit the ability for an ml2 plugin to successfully bind17:59
JayFI don't have the flow here fully internalized, so sorry if the questions are orthogonal17:59
JayFbut is that an implementation detail or part of the API?17:59
JayFjust thinking if we would use that approach moving forward, do we have assurances that the ml2 behavior we're relying on won't get "fixed" :D 18:00
JayFI can also do this sync on a call if you want, up to you18:00
TheJuliaso18:01
TheJuliaI'm trying to figure out how to put this into words18:02
TheJuliathe tl;dr is when we normally bind a port today, we include a host_id, and a binding profile. That binding profile has a bunch of detail in it.18:02
TheJuliain that detail, is the "physical" aspects18:02
JayFthe binding profile gets a lot of it's information from us, including local_link_connection18:02
TheJuliaso, without the physical, the ml2 plugin just *can't* achieve an attachment18:03
JayFthe OVN VTEP change was all about proxying information into the binding profile18:03
JayFyeah, but my question is more, if that's a nonfatal error today, do we have reason to believe it'll remain that way? because it seems like relying on something someone could see as an 'error' condition may be dangerous18:03
TheJuliato jump to the conclusion, we should be able to send a binding profile which is {}18:03
JayFI'm also thinking about a "moving forward forever" solution and you may be thinking "backportable bugfix", I'm not sure18:04
TheJuliaI think it should because profile in the neutron code explicitly notes that it is an optional field18:04
JayFand I suspect the answer to my concern is going to be just get bhaley to pinky swear :D 18:04
JayFoh, perfect, that's what I was getting at18:04
JayFand we control the ML2 driver we use18:04
TheJuliaeveryone does, but its fine for the ml2 plugin to fail18:05
TheJuliathe net result will be an intermediate bind fail state18:05
TheJuliabut, thats enough to trigger neutron to do address association18:05
JayFwhich we can document, for ironic, as a proper behavior18:05
JayFand if we wanted to "dot the i" on this, maybe even see if we can get neutron to consider adding an intermediate "in progress" state and officially support it18:06
* JayF is trying to avoid cases, where possible, where ironic stuff shows up as "failed" in other services during intermediate states18:06
TheJuliaWe already sort of have, the only *risk* I could see there is networking-baremetal which might think that it was successful and update the state18:07
JayFthat is the exact reason we are trying to get John's patch in18:07
TheJuliabut, even then18:07
JayFfor networking-baremetal18:07
TheJuliaI'm not sure we need to send a vnic type18:07
JayFer, not patch for networking-baremetal, but the attach fail in ironic, so it doesn't just do a thing 18:08
TheJuliaand if we don't, I'm not sure any of the additional code is going to execute since networking-baremetal is focused on the baremetal vnic type18:08
JayFare binding profiles tightly schema'd?18:08
TheJuliajust json18:08
JayFor is it more like driver_info18:08
JayFthen why not be explicit?18:08
TheJuliaI don't understand18:09
JayFinstead of sending {}, send {'status': 'ip_only'} but named better18:09
JayFand have that sentinel be understood by things like n-bm18:09
TheJuliai'd rather just send  {}, to be honest since that is an expected payload by neutron18:09
JayFif we have a dict we can put information in, we can use it to avoid having to rely on implicit behavior in ngs/nbm18:09
JayFfair18:09
TheJuliaoh, where does the vnic type go in18:10
TheJuliaokay, port body18:10
TheJuliawell, just a separate field in the attributes to be updated, binding:host_id is one field we need, binding:vnic_type is another18:11
JayFcool18:11
JayFthis sounds like a good idea; but I'd probably go from 95% to 100% if we got someone neutron-y to agree18:13
TheJuliaI'm going to prototype it real quick since it seems like an easy change we can make and we can run it past some neutron folk next week18:14
JayFand likely backportable for mnaser (and my downstream, eventually)18:14
JayFthat's what's really nice about this18:14
TheJuliayup18:14
TheJuliawell18:14
TheJuliadoes not fix the metadata bits, but ... it might if just do it18:15
TheJuliahi brain, where did you go18:15
JayFI thought the metadata issues were caused by ordering problems18:16
JayFbut I guess that still wouldn't move it to early enough?18:17
TheJuliaohhhhh18:19
TheJuliahmmm18:19
TheJuliathis gets weird with smartnic support18:20
JayFBecause the smartnic gets the binding profile directly (?) 18:23
JayFI know we have some code to wait for bindings to happen if is_smartnic18:23
JayFthis goes back to me wanting a way to tell neutron "we're just reserving this binding please hold" 18:24
JayFbut that changes a potentially contained order of operations change into a bigger project18:24
TheJuliaokay, we don't need to do anything if it is a smartnic, we can fix/reconcile it later if *really* needed18:26
TheJuliabecuase that will be a rebind and the code only triggers if the vnic type is set and the host is set or not set and also matches the unbound state (wut neutron code?!?)18:27
TheJuliabecause the agent on the smartnic is designed to run on the DPU18:27
TheJuliaand so its online, and is on the message bus18:27
TheJuliabut it, in theory, (althhough this goes to cardoe's desire for physical_network to also apply to vxlan)18:28
TheJuliaif it doesn't have any match, it just ends up nooping and logging at the worst18:28
JayFnice18:28
JayFthis sounds like it almost is borderline the right thing to do18:29
TheJuliabasically, at least in the ovs side of the agent, if smartnic's hostname == the agent's hostname, then it considers it work for itself18:29
JayFmakes sense18:30
JayFthe more I think about this, the more I like the idea18:32
JayFI really, really would prefer it if neutron was in on the game (e.g. it knew the bind was fake in the data model) but that's just me liking things to be consistent moreso than anything else, I suspect18:32
*** awb_ is now known as awb18:43
TheJuliaI think the starting state is just empty value fields18:55
TheJuliaso, we end up populating 2 of 3 critical fields18:55
TheJuliaand if we need to change the values we end up doing that later as well18:55
opendevreviewJulia Kreger proposed openstack/ironic master: WIP: provide host_id to neutron early on  https://review.opendev.org/c/openstack/ironic/+/94637818:56
TheJuliaThat is major enough change in the behavior pattern, best to just let CI run to wait and see18:57
TheJuliamnaser: ^18:57
JayFI thought you were explicitly going to avoid sending vnic_type?18:57
TheJuliawithout any backing data to do a binding, it doesn't matter actually18:57
JayFI assume you know better after reading more code, but just saying that outloud18:57
JayFok cool18:57
TheJulialooks like as long as we don't set it to vnic_smartnic we should be good18:58
TheJuliaI think the starting state ends up as "normal" and not "baremetal", but baremetal is also largely nooped in other aspects so it just feels cleaner to send some value along18:58
JayFit goes along with my "make what's going on API-visible in neutron" argument18:59
JayFto send as much valid info as we can without triggering a real binding19:00
TheJuliayeah, in theory, the address already gets set on another call (which feels awkward in the code as well...)19:01
TheJuliawouldn't be awful if the mac was wrong, might actually be better, but the lack of binding information is basically going to prevent anything from actually happening beyond the bare minimum19:02
opendevreviewJulia Kreger proposed openstack/networking-generic-switch master: CI: Fix trunks enabled by default  https://review.opendev.org/c/openstack/networking-generic-switch/+/94608919:09
* JayF stepping away but will check back periodically if you need someone to bounce things off again19:25
TheJuliaack, have a good weekend19:27
TheJuliaso yes, it works. it is a functional noop but does cause the status to go "active"19:41
TheJuliaI guess that is okay, since its going to get re-bound19:41
TheJuliamnaser: Do you happen to be around?19:45
mnaserreading backlog sorry today is double incident day whammy20:11
mnaserTheJulia: so tldr set host_id and then we might potentially need to refresh info when we generate configdrive20:15
TheJuliamnaser: I *think* since it is deferred it might populate on the nova side20:16
TheJuliaI'd have to sift through the nova code again to be sure20:16
mnaserit doesn't, network info doesn't get refreshed anywhere20:16
mnaserThe function to get base metadata just massages it20:16
mnaserThat's why it's also broken for non ironic D:20:17
TheJuliaoh20:17
TheJuliaokay20:17
TheJuliaso, the metadata still needs to be explicitly done then20:18
TheJuliajoy20:18
TheJuliawell, the nova metadata code could refresh it20:21
JayFthat seems like it'd be reasonable to do; if nobody else has by then I might take an hour this weekend tracing down what that'd take20:43
TheJuliawell, sean did note that there was patches in the past but never agreement to actually do so20:49
TheJuliaat least, that is how I took it20:49

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!