TheJulia | So, as far as I'm aware, we never built any framework to get secret data into the agent | 00:30 |
---|---|---|
TheJulia | ... what if we used the secret token as the key to enable secret data to be encrypted on the conductor side, which the agent can then decrypt as needed. Thoughts? | 00:31 |
TheJulia | in a perfect world, the agent is running an https server | 00:34 |
TheJulia | that message then goes over https so it is doubly encrypted, my whole worry is logs and just making it harder to decode it out | 00:34 |
opendevreview | Merged openstack/ironic master: Fix typo calling save_and_reraise_exception https://review.opendev.org/c/openstack/ironic/+/939704 | 01:10 |
JayF | Don't we already have automatic TLS between the agent and the conductor? I thought that was mutual TLS and not just certs on both sides but I'm not 100% sure | 02:12 |
TheJulia | it is auto | 04:09 |
rpittau | good morning ironic! o/ | 07:33 |
kubajj | good morning, rpittau, I have a quick question. For the backport, should I just add the release note to the change, squash the commits together or do some other git magic? | 09:13 |
rpittau | kubajj: you can cherry pick both commits into one, either manually squashing them or letting cherry-pick do that for you, and then remember to check that both commits are mentioned in the commit message as "cherry picked from" | 09:24 |
opendevreview | Jakub Jelinek proposed openstack/ironic-python-agent stable/2024.2: Fix RAID volume name https://review.opendev.org/c/openstack/ironic-python-agent/+/939700 | 10:35 |
opendevreview | Julia Kreger proposed openstack/ironic master: ci: fix ipv6 CI job https://review.opendev.org/c/openstack/ironic/+/939732 | 14:17 |
opendevreview | Jakub Jelinek proposed openstack/ironic-python-agent master: Fix errors in the function erase_devices_express https://review.opendev.org/c/openstack/ironic-python-agent/+/939803 | 14:17 |
kubajj | This ^ is a little bit of a weird error we came across today. I reported the bug and figured out that it can be fixed easily. Let me know if you want me to change anything. I am still a bit confused about that function. | 14:19 |
TheJulia | kubajj: weeeird | 14:27 |
TheJulia | kubajj: I'm super curious how metadata cleaning failed to generate that though | 14:27 |
kubajj | TheJulia: indeed | 14:27 |
TheJulia | I'm like "wait, how did that fail" and got to "oh, the change only makes sense with a pass then fail | 14:28 |
kubajj | TheJulia: exactly, it passes the first try and then it fails the second one | 14:29 |
kubajj | but isn't the first try block doing something only for nvmes? | 14:30 |
TheJulia | Indeed, the only way I could really see it happening is if _is_nvme(dev) returns false | 14:37 |
TheJulia | and destroy_disk_metadata then fails | 14:37 |
TheJulia | I guess I could see that starting to go sideways... if the device is like a read only block device provided by a storage fabric | 14:38 |
kubajj | TheJulia: for us it failed with a hard drive (we think the disk is broken, because it throws wipefs: error: /dev/sda: probing initialization failed: No such device or address) | 15:05 |
TheJulia | Yeah, a detected device which has been offlined. | 15:06 |
TheJulia | we likely need to backport that change then | 15:07 |
TheJulia | Because that is a thing which happens | 15:07 |
kubajj | TheJulia: I was expecting that (learned my lesson and included a release note for this one without a follow up), can do the backport | 15:12 |
TheJulia | cool cool | 15:15 |
TheJulia | that works | 15:15 |
rpittau | good night! o/ | 16:01 |
kubajj | TheJulia: am I safe to recheck? There seems to have been a problem with the cloning of ipmitool (fatal: expected 'packfile') | 16:16 |
TheJulia | first I've heard of this issue, do you have a link? | 16:16 |
JayF | that failure usually indicates a network issue cloning down git for the IPA ramdisk build | 16:18 |
opendevreview | Verification of a change to openstack/ironic-python-agent stable/2024.2 failed: Fix RAID volume name https://review.opendev.org/c/openstack/ironic-python-agent/+/939700 | 16:18 |
JayF | I haven't seen the exact error, but that matches that pattern | 16:18 |
kubajj | TheJulia: https://zuul.opendev.org/t/openstack/build/336fb98a492d40509947af9c600cf934 | 16:20 |
JayF | kubajj: that needs a recheck, it's a network issue | 16:21 |
JayF | HTTP 504 pulling from codeberg.org | 16:21 |
JayF | well, "network issue" I am assuming it's temporary, I haven't tried the clone locally | 16:21 |
TheJulia | yeah | 16:21 |
kubajj | just tried to clone it locally and worked, so hopefully will pass this time | 16:22 |
TheJulia | hmm, ipv6 job is being misbehaving | 16:40 |
opendevreview | Julia Kreger proposed openstack/ironic master: WIP - A very early wip of bootc deployment on the ironic side https://review.opendev.org/c/openstack/ironic/+/937897 | 16:55 |
JayF | jfyi cid and I will be doing a pair review + maybe demo of inspection rules monday after the meeting | 19:25 |
JayF | would be a good time to get context+understanding so we can get this over the line | 19:26 |
cid | ++++++ * 10 | 19:26 |
opendevreview | Julia Kreger proposed openstack/ironic master: ci: fix ipv6 CI job https://review.opendev.org/c/openstack/ironic/+/939732 | 19:56 |
TheJulia | okay, I'm hopeful regarding ^ | 19:56 |
rm_work[m] | during a clean, can you provide multiple steps? like this is my proposed example of a full firmware update run using multiple hardware managers: https://paste.openstack.org/show/bcLs4DoiQkplTVFRRoLI/ | 21:43 |
rm_work[m] | the example on the firmware-updates doc page for some reason is doing multiple node clean / node service commands, even within the same interface, but it seems like given the data types of the schema I could provide them all in one go? | 21:44 |
rm_work[m] | and could I go even further and if I wanted to flash multiple nic or disk firmwares, could I just provide the same component twice in the same settings block, with different urls and other params? | 21:46 |
TheJulia | so, I'm becoming convinced the v6 stuff is just not going to be happy with edk2/ovmf images with defaults, states... and the pile of open issues | 21:48 |
TheJulia | rm_work[m]: yeah, idea wise, it can be a giant list if youw ant | 21:49 |
TheJulia | rm_work[m]: keep in mind, steps have to be available to the state | 21:49 |
rm_work[m] | i'm not totally sure what that second one means | 21:50 |
TheJulia | so, with manual clean you provide a priority, as long as the priorities are separate I don't think it dedupes just by name | 21:50 |
TheJulia | since it is about making a list by step priority when you do manual cleaning | 21:50 |
TheJulia | basically what I meant was the step has to exist and be available in the returned list of steps by the hardware manager for when you trigger it | 21:51 |
TheJulia | so a hardware manager, in theory could say "this is automatic" and "this is manual" based upon this overall phase with cleaning specifically. Service is all user driven | 21:52 |
TheJulia | Deploy wise, a hardware manager could expose additional steps, I just don't think we'ev ever tried it outside of maybe some of the downstream users | 21:52 |
TheJulia | Anyway, I'm going to step away from the computer since I'm almost to the end of my workday and I need to scream about ipv6 | 21:53 |
rm_work[m] | hmm, so as long as you do a clean and specify the hardware manager for at least one step, it will be "triggered" and then we could just do whatever we want without even providing any settings, which, yeah that makes sense | 21:54 |
rm_work[m] | I suppose settings is just arbitrary stuff that gets passed to the step in the manager and parsed in whatever way we code it | 21:54 |
rm_work[m] | anyway cool thanks, screaming about ipv6 is also a hobby of mine periodically so have fun :D | 21:55 |
TheJulia | rm_work[m]: actually, if the hardware manager is loaded, when ironic collects steps, it will poll the additional hardware manager as well for available steps | 21:56 |
rm_work[m] | ah, so even if it isn't provided in the clean json at all, it can still do thing? | 21:56 |
rm_work[m] | which seems... not like something we should be doing likely, but still, interesting | 21:56 |
TheJulia | This is how you can mash in automatic steps for automatic actions, its when your doing manual cleaning or changes is when only what you specify to execute will be triggered, but that step of course has to be available and visible based upon the flow your executing within. Flow being servicing, cleaning, or deploying | 21:56 |
rm_work[m] | OH, so this is how we make things just "always happen" on clean | 21:57 |
TheJulia | all goes back to that balancing the forces :) | 21:57 |
TheJulia | exactly! | 21:57 |
rm_work[m] | ok, very very useful, somehow I didn't think about that | 21:57 |
rm_work[m] | we were trying to figure out how to set up automation to always trigger the right cleaning steps but it's just... this :D | 21:57 |
rm_work[m] | thanks o7 | 21:58 |
TheJulia | The hardware manager can literally make that decision, except for the baked in clean steps | 21:58 |
TheJulia | but you can also override it's default value to deprioritize or disable it | 21:58 |
TheJulia | Think of it like a swiss army knife full of options. | 21:58 |
rm_work[m] | yeah since we'll need to be building a custom IPA image anyway for our custom hardware manager, we can tweak those as well if necessary | 21:59 |
TheJulia | exactly | 21:59 |
rm_work[m] | do you mean code changes to existing hardware managers, or is it actually just a config somewhere even for those as far as priority/enabled? | 21:59 |
TheJulia | There is an ability to put in an ironic.conf entry which overrides the default values which get assigned | 22:01 |
TheJulia | to reprioritize a step value or even disable a step | 22:01 |
TheJulia | I don't have it off the top of my head, but it is in ironic.conf | 22:01 |
TheJulia | so if you look at the example, it will talk about priority values | 22:02 |
TheJulia | for steps specifically | 22:02 |
TheJulia | anyway, wife is now requesting walk time and I still need to use impolite words to describe ipv6 + edk2/ovmf | 22:02 |
opendevreview | Julia Kreger proposed openstack/ironic master: ci: fix ipv6 CI job https://review.opendev.org/c/openstack/ironic/+/939732 | 22:34 |
JayF | rm_work[m]: worth noting the flip is possible: you set zero as the priority, it won't be added to automated cleaning but will still be available for manual cleaning | 22:47 |
-opendevstatus- NOTICE: The Gerrit service on review.opendev.org will be offline momentarily for a restart to put some database compaction config changes into effect, and will return within a few minutes | 22:54 | |
opendevreview | cid proposed openstack/ironic master: DB: inspection rules migration https://review.opendev.org/c/openstack/ironic/+/939318 | 22:54 |
opendevreview | cid proposed openstack/ironic master: Apply Rules: inspection rules migration https://review.opendev.org/c/openstack/ironic/+/939218 | 22:54 |
opendevreview | cid proposed openstack/ironic master: API/Testing: Inspection rules migration https://review.opendev.org/c/openstack/ironic/+/939217 | 22:54 |
opendevreview | Julia Kreger proposed openstack/ironic master: ci: fix ipv6 CI job https://review.opendev.org/c/openstack/ironic/+/939732 | 23:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!