| TheJulia | yeah hold + hold states shoudl be super easy | 00:28 |
|---|---|---|
| TheJulia | although... testtools.matchers._impl.MismatchError: 'clean hold' != 'available' | 00:32 |
| TheJulia | but it is likely the test itself | 00:32 |
| arne_wiebalck | Good morning, Ironic! | 07:13 |
| rpittau | good morning ironic! o/ | 07:24 |
| opendevreview | Mohammed Boukhalfa proposed openstack/sushy-tools master: Add fake_ipa inspection, lookup and heartbeater to fake system https://review.opendev.org/c/openstack/sushy-tools/+/875366 | 09:38 |
| kaloyank | hello ironic o/ | 10:13 |
| iurygregory | morning Ironic | 11:05 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-python-agent master: Trivial: formatting issue in the inventory docs https://review.opendev.org/c/openstack/ironic-python-agent/+/879040 | 11:34 |
| *** sean-k-mooney1 is now known as sean-k-mooney | 11:40 | |
| opendevreview | Merged openstack/ironic-python-agent master: Trivial: formatting issue in the inventory docs https://review.opendev.org/c/openstack/ironic-python-agent/+/879040 | 11:52 |
| dtantsur | that was quick :) | 12:21 |
| iurygregory | well, very trivial fix XD | 12:45 |
| iurygregory | just had to check the output =) | 12:46 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-python-agent master: Report system firmware information in the inventory https://review.opendev.org/c/openstack/ironic-python-agent/+/879049 | 13:50 |
| * iurygregory looks | 13:54 | |
| TheJulia | good morning | 13:58 |
| dtantsur | is it actually good today? :) | 14:04 |
| TheJulia | ... I think so | 14:04 |
| TheJulia | I have hold steps like half written | 14:05 |
| TheJulia | and for the fun of it I'll likely do sleep steps next | 14:05 |
| dtantsur | nice! | 14:09 |
| TheJulia | it feels slightly hacky in a sense, through use of reserved step names | 14:12 |
| TheJulia | but I think that is what we would have built consensus on anyway | 14:12 |
| TheJulia | and making a general handler to do that sort of stuff, so we can bolt on to it easily | 14:12 |
| iurygregory | nice | 14:18 |
| iurygregory | good morning TheJulia | 14:18 |
| * TheJulia goes and finds cold meds again because sleep without them was okay, sitting up is not | 14:19 | |
| iurygregory | I would go back to bed | 14:19 |
| TheJulia | eh, the corgi captures my side of the bed when I get up | 14:20 |
| iurygregory | ops .-. | 14:21 |
| * TheJulia wonders how we're ending up in the -ing state now | 14:21 | |
| JayF | https://review.opendev.org/c/openstack/sushy-tools/+/869379/3#message-88060d8aca36c337cddb1ada3a18dceb790766ce | 14:23 |
| JayF | tl;dr: someone is using sushy-tools to provision VMs with MAAS. | 14:23 |
| dtantsur | fun | 14:23 |
| JayF | the irony is strong :) | 14:24 |
| * TheJulia feels like we need a pixie boots in a cloke with an "the irony is strong with this one" text | 14:32 | |
| iurygregory | omg | 14:44 |
| kaloyank | TheJulia: do you think you´ll be able to spare some time writting down the IPA comms change today? | 14:44 |
| kaloyank | I can help | 14:44 |
| TheJulia | ... I wasn't thinking of doing that, but I can likely make an hour or two in a few hours | 14:45 |
| JayF | Did we decide what changes exactly to make? | 14:46 |
| JayF | I thought there was still some research to happen | 14:46 |
| TheJulia | well, I was thinking we could do said research then, maybe | 14:48 |
| JayF | I will not doubt your ability to rapidly figure things out :D | 14:48 |
| * TheJulia grumbles about how painful writing clean step tests can be | 14:49 | |
| * TheJulia suspects she is experiencing zane's same complaint with unit tests | 14:52 | |
| JayF | BTW; the answer from releases team re: the question in PTG: independent releases can create branches; release teams tooling cannot release from those branches (meaning you'd have to manually release) | 14:56 |
| JayF | I think our decision to keep the sushy status quo is the correct one | 14:56 |
| * TheJulia raises an eyebrow | 14:57 | |
| JayF | (the intersection of 'need to manually release' and 'pypi maintainer cleanup' is not one I'd like to navigate) | 14:59 |
| TheJulia | muahhaha unhold works | 15:01 |
| kaloyank | \m/ | 15:02 |
| dtantsur | JayF: the maintainer cleanup does not influence that | 15:09 |
| dtantsur | manual tagging for opendev projects works by pushing a tag to gerrit | 15:09 |
| dtantsur | then the infra automation takes care of it | 15:09 |
| dtantsur | (it works this way even for projects outside of the governance) | 15:09 |
| JayF | ack; good to know | 15:09 |
| JayF | so we'd have to manually tag but pypi is magic | 15:09 |
| dtantsur | (I'm not advocating for the independent model, just clarifying) | 15:09 |
| JayF | I'm going to write up a doc for our call-for-contributors for ARM support for here -> https://governance.openstack.org/tc/reference/upstream-investment-opportunities/ | 15:12 |
| dtantsur | great idea | 15:12 |
| JayF | apparently we have some folks coming in via foundation who are looking for ways to help, that'll be the way to get it surfaced to them | 15:12 |
| JayF | eh, it's not my idea just stolen from the tc ptg topic ;) | 15:13 |
| dtantsur | I did not say it's your idea, I said it's a great idea! | 15:13 |
| dtantsur | jk :D | 15:13 |
| JayF | the silly assumed nuances of the english language | 15:13 |
| JayF | I am amazed that it never occurred to me that the attribution in "great idea" is 1000% implied | 15:14 |
| dtantsur | no languages I know follow "explicit is better than implicit" | 15:14 |
| clarkb | dtantsur: and the release automation pushes tags to trigger the automation too. Under the hood the implementation should be basiclly identical post tag push | 15:17 |
| dtantsur | yep | 15:19 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic-specs master: Firmware Interface https://review.opendev.org/c/openstack/ironic-specs/+/878505 | 15:33 |
| iurygregory | ready for reviews o/ | 15:33 |
| rpittau | good night! o/ | 15:54 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Add hold steps https://review.opendev.org/c/openstack/ironic/+/879060 | 16:18 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Add sleep step https://review.opendev.org/c/openstack/ironic/+/879061 | 16:18 |
| TheJulia | ka-boom | 16:18 |
| * TheJulia is actually curious how the state machine graph will change | 16:20 | |
| opendevreview | Kaifeng Wang proposed openstack/ironic master: Remove instance image after deployment https://review.opendev.org/c/openstack/ironic/+/878680 | 16:26 |
| iurygregory | wow Kaifeng patch \o/ | 16:33 |
| TheJulia | kaloyank: so... call flow. hmmm | 17:03 |
| kaloyank | you said there are some things left to research, shall we start from there or you have something else in mind? | 17:04 |
| JayF | https://governance.openstack.org/tc/goals/selected/migrate-to-privsep.html we gotta do this still :/ | 17:05 |
| TheJulia | kaloyank: maybe a starting point is to reach shared context | 17:20 |
| TheJulia | kaloyank: have you reviewed the original specification document on one way ipa communication? | 17:21 |
| kaloyank | yes | 17:26 |
| TheJulia | kaloyank: did you, by change, leave any thoughts or percpetions on it? | 17:46 |
| kaloyank | I haven´t commented on the spec. My overall impression is that it looks simpler to use and to support from an operators´ standpoint of view | 17:57 |
| TheJulia | simpler communication flow, more complicated process logic | 18:01 |
| kaloyank | can you elaborate a bit how does it get more complicated? I presume you´re referring to the fact that the conductor will have to track which steps are completed? | 18:03 |
| TheJulia | today, when we have a heartbeat, we connect out to the agent and check on it's status | 18:04 |
| TheJulia | instead, we'll need to be told, and then act upon that along with cache and process everything we would have just asked for | 18:04 |
| opendevreview | Julia Kreger proposed openstack/ironic-specs master: Framework for DPU management/orchustration https://review.opendev.org/c/openstack/ironic-specs/+/874189 | 18:12 |
| sean-k-mooney | JayF: os as an aside if we were going to do breaking change once a year i would actully prefer ot only do breaking changes in teh non slurp release and only do deprecations in the slurp | 18:18 |
| sean-k-mooney | rahter then avoiding removing code in the non slurps | 18:19 |
| sean-k-mooney | that way when you finish an upgrade to a slurp release. you read the deprecations in that release and know thos are the things you need to sop using before the next slup upgrade | 18:21 |
| JayF | We don't deprecate a lot of stuff in Ironic, and tend to let it sit for more than the minimum number of cycles | 18:23 |
| sean-k-mooney | same | 18:23 |
| sean-k-mooney | its acully 3-4 cycles in most cases | 18:24 |
| JayF | so regardless of what I argued for TC policy, we might just by accident implement the only-deprecate-things-on-slurp and make life easier | 18:24 |
| sean-k-mooney | i just want to do some cleanup this cycle | 18:24 |
| JayF | but I don't like when those kinda decisions are made at TC level; I prefer TC outline the outcome and let projects figure out how to get there | 18:24 |
| JayF | I'll curate release notes if I have to, or we'll just punt on deprecations in SLURP-1 :) | 18:24 |
| JayF | lots of ways to do it :D | 18:24 |
| TheJulia | the key is always the outcome, the exact how to get there is situational | 18:25 |
| sean-k-mooney | ya so we annoched oru next min version of libvirt/qemu in wallaby and i ment to push to get this bumped in antelope | 18:25 |
| sean-k-mooney | but when we went to do it in january the gate exploded | 18:25 |
| sean-k-mooney | so i dont want to punt again | 18:25 |
| JayF | What does new libvirt get you all? | 18:26 |
| sean-k-mooney | we can remove conditional code that makes feautre work only on relase that meet that version | 18:27 |
| sean-k-mooney | and avoid adding more of that code | 18:27 |
| JayF | ah, so you opportunisitcally get the new features already | 18:27 |
| sean-k-mooney | yep | 18:27 |
| JayF | yeah that's all good to get the old compat code reduced then | 18:27 |
| sean-k-mooney | realisticaly we are also not testign that old libvirt version | 18:27 |
| sean-k-mooney | we test what we get form ubuntu and ocationally centos | 18:27 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/reference/libvirt-distro-support-matrix.html#os-distribution-versions | 18:28 |
| sean-k-mooney | so our current min qemu i 4.2 | 18:28 |
| sean-k-mooney | centos 8 ships 5.2 | 18:28 |
| sean-k-mooney | so tecnically we still supprot the qemu in ubuntu 20.04 or rhel 8.2 | 18:29 |
| kaloyank | TheJulia: I see. And the concerns are that the conductor code will be more complex, ergo harder to maintain? | 18:30 |
| sean-k-mooney | anyway enjoy the rest of your evening o/ | 18:30 |
| JayF | o/ | 18:31 |
| TheJulia | kaloyank: well, the fun thing is we would have to continue to support the old mode for some period of time | 18:37 |
| TheJulia | which means the transition and all actions need to be evaluated | 18:37 |
| JayF | Cross post for a review: https://review.opendev.org/c/openstack/governance/+/879080 Add Contibution Opportunity: Ironic ARM support | 18:59 |
| kaloyank | TheJulia: yes, I assumed dual comms should be supported for some time | 19:08 |
| kaloyank | do you have any ideas regading supporting both ways ? | 19:09 |
| TheJulia | kaloyank: I *think* we would need to basically buffer data/commands back and forth | 20:20 |
| TheJulia | ... but not on the node object if we can avoid it | 20:20 |
| kaloyank | a table in the database? MySQL is not my strength but afaik you can use it like a cache | 20:22 |
| JayF | TheJulia: I wonder if making `steps` a fully formed column would make this much easier to deal with in the Node object... if you're going to have to cache some stuff, putting it in a separate field is 1000x better than driver_info | 20:23 |
| JayF | I'm trying to think if there would be a way to normalize steps into it's own DB table, but that is likely overengineered given the freeform nature of that api | 20:23 |
| TheJulia | yeah, data design is not as important at the moment, but I guess conceptually if the interchange would work with everything on heartbeat across an intermediate flow | 20:24 |
| TheJulia | I'm personally shy from putting more columns on node from the standpoint of iterations to return any piece of data, but I made as much of that as smart as minimialistic as possible to help the user experience anyway | 20:25 |
| TheJulia | as such, I should just shrug | 20:25 |
| TheJulia | :) | 20:25 |
| JayF | that's more or less how I implemented heartbeat-only downstream | 20:26 |
| JayF | on heartbeat, still trigger everything, but I subclassed agent client to instead just abuse node.something to populate what the response would've been | 20:27 |
| JayF | so on the next heartbeat, there'd be a response pending, and we'd put that reponse into the payload we sent to the agent in response to heartbeat | 20:27 |
| JayF | and then just extracted it and fed it to the same existing codeflows in IPA | 20:27 |
| TheJulia | so basically we would have to unwind agent_client.py logic as well | 20:28 |
| JayF | this had major downsides, mainly: 1) your total length of steps is limited by the size of the DB column and 2) every command required two heartbeats to succeed (hb1 causes conductor to queue response; hb2 actually recieves and acts on response) | 20:28 |
| JayF | there are almost certainly better ways to structure this, but I was unable to find one at the time | 20:28 |
| TheJulia | yeah, I was thinking the #2 item unless we could stack up multiple commands by node | 20:28 |
| JayF | the second downside was primarily because I didn't wanna to make heartbeats sync | 20:29 |
| JayF | because that has a seismic impact on the codebase | 20:29 |
| TheJulia | but then the interchange might still delay things | 20:29 |
| JayF | I was thinking if I did it upstream; I might introduce /heartbeat/sync or similar | 20:29 |
| JayF | which would be a different endpoint that IPA would stay connected to while conductor formulated and fed it a response | 20:29 |
| JayF | but given I was just able to clobber existing behavior, and the "two hbs per action" downside wasn't impactful to the requirements in that environment, I didn't go that far | 20:30 |
| opendevreview | Julia Kreger proposed openstack/ironic master: WIP: Add hold steps https://review.opendev.org/c/openstack/ironic/+/879060 | 22:07 |
| opendevreview | Julia Kreger proposed openstack/ironic master: Enable vendor interfaces to be called as steps https://review.opendev.org/c/openstack/ironic/+/879089 | 22:07 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!