opendevreview | Junya Noguchi proposed openstack/ironic master: Add image build method for verified OS. https://review.opendev.org/c/openstack/ironic/+/946318 | 02:03 |
---|---|---|
opendevreview | Vasyl Saienko proposed openstack/ironic master: Allow to use internal APIs during deployment https://review.opendev.org/c/openstack/ironic/+/946321 | 05:37 |
opendevreview | Vasyl Saienko proposed openstack/ironic master: Allow to use internal APIs during deployment https://review.opendev.org/c/openstack/ironic/+/946321 | 05:41 |
frickler | JayF: 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 |
rpittau | good morning ironic! happy friday ! o/ | 07:17 |
rpittau | JayF: resnmp: what's the current issue and the status? :) | 07:40 |
rpittau | cid: when you got a moment can you please rebase https://review.opendev.org/c/openstack/ironic/+/944769 on top of master ? | 08:01 |
cid | rpittau: Will do that in a moment. | 08:04 |
rpittau | thanks! | 08:06 |
frickler | rpittau: 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 status | 08:17 |
rpittau | frickler: thanks, checking now | 08:19 |
rpittau | frickler, JayF, I think all pysnmp-modules alter than 6.1.4 are simply broken, at least regarding hlapi module, which is basically what JayF found | 08:29 |
rpittau | I'm adding a comment in the UC change | 08:29 |
opendevreview | cid proposed openstack/ironic master: A new 'description' field to the port object https://review.opendev.org/c/openstack/ironic/+/944769 | 08:33 |
* cid that was not right. | 08:34 | |
frickler | rpittau: 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/8ed6f74b8e8b4e4ba3508ba2e0a11649 | 08:46 |
frickler | so likely the issue is that pyasn1_modules===0.4.2 is no longer working with our pinned pysnmp-lextudio version | 08:46 |
frickler | we 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 know | 08:47 |
opendevreview | Harald Jensås proposed openstack/sushy-tools master: Pass image ID to _attempt_delete_image_local_file https://review.opendev.org/c/openstack/sushy-tools/+/946326 | 08:48 |
opendevreview | Merged openstack/bifrost unmaintained/2023.1: Switch to unmaintained/2023.1 https://review.opendev.org/c/openstack/bifrost/+/945542 | 09:02 |
zigo | frickler: I'm not sure I understand, what's the issue exactly? | 09:03 |
zigo | In Debian, we have python3-pyasn1-modules 0.4.1 only. | 09:04 |
zigo | Also, 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 |
frickler | zigo: but you somehow managed to package ironic, right? | 09:05 |
zigo | Yeah. | 09:05 |
rpittau | frickler: the issue is different though | 09:06 |
frickler | iiur 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 |
rpittau | I think it's 2 issues here | 09:06 |
zigo | Yeah, the original author passed away. | 09:07 |
zigo | But should we get rid of *all* lextudio packages now? | 09:07 |
zigo | I've read in this channel that some should stay, not sure which ones. | 09:07 |
rpittau | zigo: the problem is that the lextudio pkgs are good until a certain version, which is newer of the old unmaintained ones | 09:07 |
rpittau | I will add another comment in the UC patch | 09:07 |
frickler | rpittau: 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 |
rpittau | frickler: can I just update the UC patch with the "working" versions to verify my tests? | 09:09 |
rpittau | frickler: ack | 09:09 |
frickler | rpittau: which are the working versions for you | 09:09 |
rpittau | pyasn1 0.4.1 and pysmp_lextudio 6.1.4 | 09:10 |
frickler | rpittau: you could either update https://review.opendev.org/c/openstack/requirements/+/907665/79 or put another patch on top of that | 09:10 |
frickler | ah, 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 myelf | 09:10 |
rpittau | yeah | 09:10 |
rpittau | I've updated the etherpad | 09:11 |
zigo | That's what we have in Debian Unstable. | 09:11 |
rpittau | zigo: and keep that! :D | 09:11 |
frickler | zigo: 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 fine | 09:11 |
rpittau | we were wondering to deprecate snmp in ironic, I think it's time we act on that unless we find volunteers to maintain the snmp libraries | 09:12 |
rpittau | pysnmp that's it | 09:12 |
zigo | We're in freeze in 11 days, so I don't think anyone will upgrade! :) | 09:13 |
rpittau | great :) | 09:13 |
opendevreview | Merged openstack/ironic master: devstack bindep - [platform:rpm] https://review.opendev.org/c/openstack/ironic/+/893813 | 09:18 |
opendevreview | Verification of a change to openstack/ironic master failed: [devstack] Allow deploy environment with portgroups https://review.opendev.org/c/openstack/ironic/+/940611 | 09:18 |
opendevreview | cid proposed openstack/ironic master: A new 'description' field to the port object https://review.opendev.org/c/openstack/ironic/+/944769 | 09:20 |
cid | rpittau, ^^ 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 |
opendevreview | Merged openstack/ironic-tempest-plugin master: Make sure fixed IPs are different for multitenancy tests https://review.opendev.org/c/openstack/ironic-tempest-plugin/+/942414 | 10:31 |
opendevreview | Harald Jensås proposed openstack/sushy-tools master: Pass image ID to _attempt_delete_image_local_file https://review.opendev.org/c/openstack/sushy-tools/+/946326 | 10:49 |
opendevreview | Verification of a change to openstack/ironic master failed: [devstack] Allow deploy environment with portgroups https://review.opendev.org/c/openstack/ironic/+/940611 | 11:32 |
rpittau | cid: yes, thanks :) | 12:16 |
JayF | frickler: That's an accurate description of what's actually going on. I chased my own tail for about 2 hours yesterday because I was confused | 13:07 |
opendevreview | Merged openstack/ironic master: A new 'description' field to the port object https://review.opendev.org/c/openstack/ironic/+/944769 | 13:25 |
TheJulia | Good morning folks | 13:45 |
opendevreview | cid proposed openstack/ironic-python-agent master: WIP: Eventlet Removal- Oslo's wsgi server to uWSGI https://review.opendev.org/c/openstack/ironic-python-agent/+/946091 | 16:38 |
opendevreview | Amarachi Ordor proposed openstack/bifrost master: docs: updated test guide, improve how-to clarity, add troubleshooting tips https://review.opendev.org/c/openstack/bifrost/+/946352 | 16:57 |
opendevreview | Merged openstack/ironic master: [devstack] Allow deploy environment with portgroups https://review.opendev.org/c/openstack/ironic/+/940611 | 17:11 |
-opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily for a patch release update | 17:16 | |
TheJulia | JayF: you around ? | 17:56 |
JayF | yes | 17:57 |
JayF | what's up? | 17:57 |
TheJulia | so 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 else | 17:57 |
TheJulia | i.e. a blank binding profile, just the host_id | 17:58 |
TheJulia | no Local Link *should* shortcircuit the ability for an ml2 plugin to successfully bind | 17:59 |
JayF | I don't have the flow here fully internalized, so sorry if the questions are orthogonal | 17:59 |
JayF | but is that an implementation detail or part of the API? | 17:59 |
JayF | just 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 |
JayF | I can also do this sync on a call if you want, up to you | 18:00 |
TheJulia | so | 18:01 |
TheJulia | I'm trying to figure out how to put this into words | 18:02 |
TheJulia | the 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 |
TheJulia | in that detail, is the "physical" aspects | 18:02 |
JayF | the binding profile gets a lot of it's information from us, including local_link_connection | 18:02 |
TheJulia | so, without the physical, the ml2 plugin just *can't* achieve an attachment | 18:03 |
JayF | the OVN VTEP change was all about proxying information into the binding profile | 18:03 |
JayF | yeah, 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 dangerous | 18:03 |
TheJulia | to jump to the conclusion, we should be able to send a binding profile which is {} | 18:03 |
JayF | I'm also thinking about a "moving forward forever" solution and you may be thinking "backportable bugfix", I'm not sure | 18:04 |
TheJulia | I think it should because profile in the neutron code explicitly notes that it is an optional field | 18:04 |
JayF | and I suspect the answer to my concern is going to be just get bhaley to pinky swear :D | 18:04 |
JayF | oh, perfect, that's what I was getting at | 18:04 |
JayF | and we control the ML2 driver we use | 18:04 |
TheJulia | everyone does, but its fine for the ml2 plugin to fail | 18:05 |
TheJulia | the net result will be an intermediate bind fail state | 18:05 |
TheJulia | but, thats enough to trigger neutron to do address association | 18:05 |
JayF | which we can document, for ironic, as a proper behavior | 18:05 |
JayF | and 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 it | 18:06 |
* JayF is trying to avoid cases, where possible, where ironic stuff shows up as "failed" in other services during intermediate states | 18:06 | |
TheJulia | We already sort of have, the only *risk* I could see there is networking-baremetal which might think that it was successful and update the state | 18:07 |
JayF | that is the exact reason we are trying to get John's patch in | 18:07 |
TheJulia | but, even then | 18:07 |
JayF | for networking-baremetal | 18:07 |
TheJulia | I'm not sure we need to send a vnic type | 18:07 |
JayF | er, not patch for networking-baremetal, but the attach fail in ironic, so it doesn't just do a thing | 18:08 |
TheJulia | and 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 type | 18:08 |
JayF | are binding profiles tightly schema'd? | 18:08 |
TheJulia | just json | 18:08 |
JayF | or is it more like driver_info | 18:08 |
JayF | then why not be explicit? | 18:08 |
TheJulia | I don't understand | 18:09 |
JayF | instead of sending {}, send {'status': 'ip_only'} but named better | 18:09 |
JayF | and have that sentinel be understood by things like n-bm | 18:09 |
TheJulia | i'd rather just send {}, to be honest since that is an expected payload by neutron | 18:09 |
JayF | if we have a dict we can put information in, we can use it to avoid having to rely on implicit behavior in ngs/nbm | 18:09 |
JayF | fair | 18:09 |
TheJulia | oh, where does the vnic type go in | 18:10 |
TheJulia | okay, port body | 18:10 |
TheJulia | well, just a separate field in the attributes to be updated, binding:host_id is one field we need, binding:vnic_type is another | 18:11 |
JayF | cool | 18:11 |
JayF | this sounds like a good idea; but I'd probably go from 95% to 100% if we got someone neutron-y to agree | 18:13 |
TheJulia | I'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 week | 18:14 |
JayF | and likely backportable for mnaser (and my downstream, eventually) | 18:14 |
JayF | that's what's really nice about this | 18:14 |
TheJulia | yup | 18:14 |
TheJulia | well | 18:14 |
TheJulia | does not fix the metadata bits, but ... it might if just do it | 18:15 |
TheJulia | hi brain, where did you go | 18:15 |
JayF | I thought the metadata issues were caused by ordering problems | 18:16 |
JayF | but I guess that still wouldn't move it to early enough? | 18:17 |
TheJulia | ohhhhh | 18:19 |
TheJulia | hmmm | 18:19 |
TheJulia | this gets weird with smartnic support | 18:20 |
JayF | Because the smartnic gets the binding profile directly (?) | 18:23 |
JayF | I know we have some code to wait for bindings to happen if is_smartnic | 18:23 |
JayF | this goes back to me wanting a way to tell neutron "we're just reserving this binding please hold" | 18:24 |
JayF | but that changes a potentially contained order of operations change into a bigger project | 18:24 |
TheJulia | okay, we don't need to do anything if it is a smartnic, we can fix/reconcile it later if *really* needed | 18:26 |
TheJulia | becuase 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 |
TheJulia | because the agent on the smartnic is designed to run on the DPU | 18:27 |
TheJulia | and so its online, and is on the message bus | 18:27 |
TheJulia | but it, in theory, (althhough this goes to cardoe's desire for physical_network to also apply to vxlan) | 18:28 |
TheJulia | if it doesn't have any match, it just ends up nooping and logging at the worst | 18:28 |
JayF | nice | 18:28 |
JayF | this sounds like it almost is borderline the right thing to do | 18:29 |
TheJulia | basically, at least in the ovs side of the agent, if smartnic's hostname == the agent's hostname, then it considers it work for itself | 18:29 |
JayF | makes sense | 18:30 |
JayF | the more I think about this, the more I like the idea | 18:32 |
JayF | I 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 suspect | 18:32 |
*** awb_ is now known as awb | 18:43 | |
TheJulia | I think the starting state is just empty value fields | 18:55 |
TheJulia | so, we end up populating 2 of 3 critical fields | 18:55 |
TheJulia | and if we need to change the values we end up doing that later as well | 18:55 |
opendevreview | Julia Kreger proposed openstack/ironic master: WIP: provide host_id to neutron early on https://review.opendev.org/c/openstack/ironic/+/946378 | 18:56 |
TheJulia | That is major enough change in the behavior pattern, best to just let CI run to wait and see | 18:57 |
TheJulia | mnaser: ^ | 18:57 |
JayF | I thought you were explicitly going to avoid sending vnic_type? | 18:57 |
TheJulia | without any backing data to do a binding, it doesn't matter actually | 18:57 |
JayF | I assume you know better after reading more code, but just saying that outloud | 18:57 |
JayF | ok cool | 18:57 |
TheJulia | looks like as long as we don't set it to vnic_smartnic we should be good | 18:58 |
TheJulia | I 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 along | 18:58 |
JayF | it goes along with my "make what's going on API-visible in neutron" argument | 18:59 |
JayF | to send as much valid info as we can without triggering a real binding | 19:00 |
TheJulia | yeah, in theory, the address already gets set on another call (which feels awkward in the code as well...) | 19:01 |
TheJulia | wouldn'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 minimum | 19:02 |
opendevreview | Julia Kreger proposed openstack/networking-generic-switch master: CI: Fix trunks enabled by default https://review.opendev.org/c/openstack/networking-generic-switch/+/946089 | 19:09 |
* JayF stepping away but will check back periodically if you need someone to bounce things off again | 19:25 | |
TheJulia | ack, have a good weekend | 19:27 |
TheJulia | so yes, it works. it is a functional noop but does cause the status to go "active" | 19:41 |
TheJulia | I guess that is okay, since its going to get re-bound | 19:41 |
TheJulia | mnaser: Do you happen to be around? | 19:45 |
mnaser | reading backlog sorry today is double incident day whammy | 20:11 |
mnaser | TheJulia: so tldr set host_id and then we might potentially need to refresh info when we generate configdrive | 20:15 |
TheJulia | mnaser: I *think* since it is deferred it might populate on the nova side | 20:16 |
TheJulia | I'd have to sift through the nova code again to be sure | 20:16 |
mnaser | it doesn't, network info doesn't get refreshed anywhere | 20:16 |
mnaser | The function to get base metadata just massages it | 20:16 |
mnaser | That's why it's also broken for non ironic D: | 20:17 |
TheJulia | oh | 20:17 |
TheJulia | okay | 20:17 |
TheJulia | so, the metadata still needs to be explicitly done then | 20:18 |
TheJulia | joy | 20:18 |
TheJulia | well, the nova metadata code could refresh it | 20:21 |
JayF | that 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 take | 20:43 |
TheJulia | well, sean did note that there was patches in the past but never agreement to actually do so | 20:49 |
TheJulia | at least, that is how I took it | 20:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!