| rpittau | good morning ironic! o/ | 08:17 |
|---|---|---|
| dtantsur | TheJulia: I feel quite strongly against writing any of our client code, unless we can prove, objectively, that shelling out to oras is a no-go for our case. | 08:55 |
| dtantsur | Do you really have capacity to implement all these subtle details? Do we have capacity to review and maintain it? | 08:55 |
| dtantsur | And again, are we ready to fix bugs stemming from users using oras to upload artifacts and our code doing something subtly incompatible? | 08:56 |
| dtantsur | Because it's not enough to implement our side of equation: we need to think about the users too. | 08:57 |
| dtantsur | Not following the de facto industry standard in this regard will be immediately seen as a UX problem | 08:58 |
| dtantsur | On the tag question, I think I understand why they went this way: tags are very familiar to any user of container tooling | 08:59 |
| dtantsur | TheJulia: https://oras.land/docs/commands/oras_manifest_fetch <-- this command is architecture-aware, so if we're okay with something a bit more low-level, it could be the way to go | 09:00 |
| dtantsur | Folks, does anyone remember if we had a resolution for the RAID size problem in https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/raid_utils.py#L31 (apparently, too small for some DIB images)? | 09:42 |
| dtantsur | Thought dump: https://bugs.launchpad.net/ironic-python-agent/+bug/2090993 | 09:56 |
| dtantsur | if anyone has time ^^^ this will help a noticeable number of our users to not mess with DIB images | 09:58 |
| iurygregory | good morning ironic | 10:44 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: Update Node Cache after Successful Clean/Service https://review.opendev.org/c/openstack/ironic/+/936009 | 12:06 |
| iurygregory | if any cores are around this patch should be simple to review https://review.opendev.org/c/openstack/ironic/+/936009 | 14:59 |
| cardoe | TheJulia: what's today's networkign zoom link? | 15:01 |
| cardoe | I've got the Nov 20th one. | 15:01 |
| rpittau | iurygregory: reviewed :) | 15:03 |
| dtantsur | cardoe: the one in the etherpad seems to work for me | 15:03 |
| iurygregory | rpittau, ack going to update | 15:04 |
| adam-metal3 | hello Ironic, what is the passcode for the networking meeting? | 15:05 |
| dtantsur | adam-metal3: doesn't link at https://etherpad.opendev.org/p/ironic-networking work? | 15:08 |
| adam-metal3 | I copy that and it asks for passcoe | 15:08 |
| adam-metal3 | okay for some reason if I clicked it in chromium it worked but if I copied it to the zoom app then it didn't | 15:11 |
| mbrandt | Hi, I wanted to ask if there is still something to do from my side or is that ok? :) https://review.opendev.org/c/openstack/ironic-python-agent/+/934330 | 15:21 |
| opendevreview | Iury Gregory Melo Ferreira proposed openstack/ironic master: Update Node Cache after Successful Clean/Service https://review.opendev.org/c/openstack/ironic/+/936009 | 15:23 |
| *** tosky_ is now known as tosky | 15:40 | |
| TheJulia | dtantsur: honestly, from what I've seen it is relatively simple and I've already forklifted prior session client which was in openstack. The missing piece to be written is speicalized file handling which is likely to be larger if we want to support deploying machine-os. Ideally, UX wise, part of this work is lined up for me to support bootable container work, but that becomes entirely disjointed then if we cannot support | 15:54 |
| TheJulia | the same container in another form when it is packaged multiple ways. | 15:54 |
| TheJulia | Shelling out raises two concerns off the top of my head. Performance wise, because we would end up with similar issues like we see with ipmitool, although that should be relatively minor. The major one is authentication because were going to need to initiate a login. We appear to be able to semi-securely pass data in.. however we would need to isolate it out because we don't want different user's requests to mix | 15:54 |
| TheJulia | credentials together. That means we need to track oras development and code as well, where as in a python client we're just plumbing data.... | 15:54 |
| TheJulia | And truthfuly for IPA, we could just tell it what it's authenticate string is directly so it's "client" is at the end of a day just a straight "get" request and post handling, i.e. having to un-zstream or convert it depending on what the image actually is | 15:54 |
| TheJulia | dtantsur: the model I'm starting to mentally head down is Ironic can do the heavy lifting in terms of authenticate, navigate, item identification to boil things down to being super specific, and then IPA can just go "oh, coool". The same model is actually necessary to handle blobs for kernel/ramdisks, as you noted earlier, just have the user define the entire reference to the manifest (via stating the sha256 hash) If a | 16:05 |
| TheJulia | user doesn't define the needful or is not specific enough, then the only reasonable thing at some level is to fail and tell the user "you need to be more specific" | 16:05 |
| * dtantsur nods | 16:06 | |
| dtantsur | I'm fine even with doing image_download_source==local and extracting the image fully on the Ironic side (presenting the resulting qcow2/raw to IPA) | 16:06 |
| TheJulia | so, that is actually the area of the code I'm presently at | 16:07 |
| TheJulia | and... what led me down the last thought, of a user has to be specific, but maybe doesn't need to be absolutely specific | 16:07 |
| TheJulia | and the different modeling. So i'm sort of at the same basic point in the flow. Because glance and a container registry have similar functions in terms of blob storage and thus it is not just a file on a disk or a remote url outright, we have an opportunity to do additional metadata extraction | 16:08 |
| TheJulia | Just like we do with glance as well | 16:08 |
| TheJulia | which leads us to selection and all | 16:08 |
| TheJulia | But that is really minor in the grand scheme of things | 16:08 |
| TheJulia | And is also largely dependent upon how data gets into the thing | 16:09 |
| TheJulia | the thing in that last statement is the container registry and in what form the data is | 16:09 |
| TheJulia | and if we need to download and convert once, or twice | 16:09 |
| TheJulia | We need to make it "easy" to be usable. :) | 16:09 |
| * TheJulia laughs at that idea | 16:10 | |
| dtantsur | Absolutely true | 16:10 |
| TheJulia | Anything with computers, easy | 16:10 |
| TheJulia | I'm so funny | 16:10 |
| dtantsur | Well, at least we'll be asked "which command do I use to prepare an image for Ironic" | 16:10 |
| TheJulia | That is a *super* good point | 16:10 |
| dtantsur | if we can point at oras or podman - great | 16:10 |
| TheJulia | ... honestly I think the ideal place to be is if we can point to both and sort of handle both models | 16:11 |
| dtantsur | true | 16:11 |
| dtantsur | except that the podman tooling is still an idea, while oras exists and allegedly works | 16:11 |
| TheJulia | which also is why I'm just thinking "oooh, json" "oh, what is this file, can we use it... oh it is zstd compressed, okay lets fix that!" | 16:11 |
| TheJulia | just don't look too deeply at oras-py | 16:12 |
| dtantsur | I won't :D | 16:12 |
| opendevreview | Riccardo Pittau proposed openstack/ironic-python-agent master: Silence modprobe loading errors for IPMI drivers https://review.opendev.org/c/openstack/ironic-python-agent/+/937042 | 16:12 |
| JayF | One thing that could be argued in either direction is if the protocol changes over time. An ironic branch that we might support for 5 years, are we ever going to have to worry about the CLI tool changing its API or the actual protocol itself changing its API in that time period? | 16:18 |
| TheJulia | That was kind of what I was thinking about needing to follow and track the tool itself. The API is really not changing/evolving quickly, 1.1 being ratified this year. 1.0 in ?2018?. The client on the otherhand we have to sort of track, because what if they add/change authentication handling, since they are modeled around a user on a cli using it | 16:23 |
| TheJulia | not a service with differeing users, trying to use the cli | 16:23 |
| rpittau | good night! o/ | 17:10 |
| JayF | yeah; I didn't know which route would be more static than the other | 18:14 |
| JayF | but just wanted to make sure that was a consideration | 18:15 |
| opendevreview | Merged openstack/python-ironicclient master: Add support to set 'disable_power_off' https://review.opendev.org/c/openstack/python-ironicclient/+/934741 | 18:17 |
| TheJulia | The other aspect which has me leaning to a "lets just walk the json" is also the nature of differing tools and approaches on the input side | 18:23 |
| TheJulia | harder to get a clear view when you don't control the lower level logic | 18:24 |
| opendevreview | Merged openstack/ironic master: Use OVN and OVS from OS packages in CI https://review.opendev.org/c/openstack/ironic/+/935628 | 18:40 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!