| rpittau | good morning ironic! o/ Happy PTG week | 07:59 |
|---|---|---|
| kaloyank | morning everyone o/ | 08:08 |
| dtantsur | arne_wiebalck: morning, does https://storyboard.openstack.org/#!/story/2010479 ring any bells? (from what jrosser mentioned above) | 09:31 |
| ade_lee | dtantsur, TheJulia hey - who is in charge of the PTG schedule? | 11:17 |
| dtantsur | ade_lee: primarily JayF, but we may be able to help | 11:17 |
| ade_lee | dtantsur, sorry for the late notice, but I added a topic to the end of the etherpad to talk about fips | 11:18 |
| ade_lee | dtantsur, I was hoping maybe to add it to the schedule during the lightning rounds on wednesday? | 11:18 |
| dtantsur | ade_lee: Update on in-progress Antelope items 1400-1500 UTC | 11:19 |
| dtantsur | will it fit there? | 11:19 |
| dtantsur | or in the end of Wendesday, yes | 11:19 |
| dtantsur | but make sure to chat with TheJulia first, I know she has been looking into something-something FIPS | 11:19 |
| ade_lee | looking - certainly the topic she has about md5 is relevant | 11:19 |
| dtantsur | ade_lee: the usual question about PTG items: is there something to discuss or is it more of Just Do It? | 11:20 |
| ade_lee | (a bit of both :)) | 11:20 |
| dtantsur | ade_lee: I've injected FIPS into the md5 topic, let's see if JayF agrees | 11:21 |
| ade_lee | dtantsur, sounds good | 11:21 |
| iurygregory | good morning Ironic | 11:56 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-specs master: Merge Inspector into Ironic https://review.opendev.org/c/openstack/ironic-specs/+/878001 | 13:22 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-specs master: Migrate inspection rules from Inspector https://review.opendev.org/c/openstack/ironic-specs/+/878230 | 13:22 |
| dtantsur | arne_wiebalck: also please check the rules one ^^^ since it may have impact on you | 13:22 |
| opendevreview | Dmitry Tantsur proposed openstack/ironic-specs master: Migrate inspection rules from Inspector https://review.opendev.org/c/openstack/ironic-specs/+/878230 | 13:42 |
| TheJulia | sooo many emails | 13:58 |
| JayF | dtantsur: ade_lee: I mean, that's more julia's topic. If she's OK sharing time, I am. | 14:04 |
| TheJulia | one is follow-up, quick and easy, the other is "adding another ci job" | 14:05 |
| TheJulia | the latter might require the former though | 14:05 |
| TheJulia | so... *shrugs* | 14:05 |
| ade_lee | JayF, TheJulia I'm open to talking fips stuff later in the week if we wont have enough time | 14:06 |
| ade_lee | but yeah, if we're going to trip up on md5 issues, then certainly the topics are related | 14:06 |
| JayF | Is there an openstack-wide goal of FIPs jobs? Or some Ironic user asking for them? | 14:07 |
| opendevreview | Merged openstack/ironic master: Enables boot modes switching with Anaconda deploy for ilo driver https://review.opendev.org/c/openstack/ironic/+/860821 | 14:07 |
| JayF | Just trying to make sure I fully grasp the 'why' | 14:07 |
| ade_lee | this is the openstack-wide fips goal | 14:07 |
| JayF | Is there a spec or policy link I could read about it at? | 14:07 |
| ade_lee | https://github.com/openstack/governance/blob/master/goals/selected/fips.rst | 14:08 |
| JayF | yeah we'll need the hashlib.md5(usedforsecurity=false) in a few places I'm sure | 14:09 |
| JayF | thanks for the link | 14:09 |
| arne_wiebalck | o/ | 14:10 |
| JayF | TheJulia: i'll go to the UTC 1500 keystone meeting if you can clue me into concerns I should bring | 14:10 |
| * arne_wiebalck realises he is not late but early, DST FTW | 14:12 | |
| JayF | No Ironic sessions until Weds anyway :) | 14:13 |
| arne_wiebalck | dtantsur: thanks for pointing me to the specs | 14:13 |
| arne_wiebalck | dtantsur: re ESP size, I remember we discussed this at the time and followed ESP expert advice to make it 550MiB | 14:20 |
| TheJulia | JayF: no concerns really, just need to reach the same page | 14:20 |
| * dtantsur dislikes magic numbers.. | 14:20 | |
| arne_wiebalck | dtantsur: dtantsur https://github.com/openstack/ironic-python-agent/blob/master/ironic_python_agent/raid_utils.py#L28-L30 | 14:21 |
| dtantsur | JayF: I think previously we could not use usedforsecurity because of the Python version | 14:21 |
| arne_wiebalck | dtantsur: there seems to be no limit for the ESP, so it could always be bigger than what we set | 14:21 |
| dtantsur | arne_wiebalck: I wonder if we switch to 1G.. unless we can determine it in advance? | 14:21 |
| dtantsur | I wonder what they put there though.. my /boot/efi is 42M | 14:22 |
| dtantsur | maybe it's a just a large partition on the image because they never put any thoughts into it :) | 14:22 |
| arne_wiebalck | yes, exactly my thinking ... what is in there? | 14:22 |
| dtantsur | even if it's empty, dd'ing will fail anyway, right? | 14:22 |
| dtantsur | maybe we need to rsync instead :D | 14:23 |
| arne_wiebalck | we should probably make it 1025GB to be ultra-safe :-D | 14:23 |
| arne_wiebalck | I remember I was surprised to see one could use cp this way | 14:23 |
| arne_wiebalck | probably rsync is even more efficient | 14:23 |
| arne_wiebalck | since it copies 42MB, not 550MB | 14:24 |
| dtantsur | Right. But then we need to deal with selinux stuff.. | 14:24 |
| JayF | https://storyboard.openstack.org/#!/story/2010479 while you all are looking at that | 14:24 |
| dtantsur | ah, it's VFAT, so no selinux | 14:24 |
| JayF | it seems like we need to make the partition slightly larger in raid cases? | 14:24 |
| dtantsur | JayF: we're literally discussing this issue | 14:25 |
| JayF | okay, I wasn't 100% sure | 14:25 |
| dtantsur | the problem is: there is no reasonable upper limit | 14:25 |
| JayF | Can we inspect the image and glean it? | 14:25 |
| dtantsur | someone can create an image with 10G EFI partition just because | 14:25 |
| dtantsur | streaming :( | 14:25 |
| JayF | GPT is still in the first "X" bytes of the stream, right? | 14:26 |
| dtantsur | yeah, but we need to pre-create the partition before streaming the root device, I assume? | 14:26 |
| JayF | yeah, that's what I was thinking as I went down that path | 14:26 |
| JayF | Could we allow metadata to be set in glance or ironic (if no glance) indicating the esp side? | 14:26 |
| JayF | **size | 14:26 |
| dtantsur | that's probably the way to go in the end.. | 14:27 |
| * dtantsur dislikes too many options, but too many options are chasing him anyway | 14:27 | |
| arne_wiebalck | how would metadata help in the case at hand? try, fail, get the size, set the meta data, retry? | 14:28 |
| JayF | If you create an image in glance with a 42 gigabyte ESP, you set some metadata | 14:28 |
| JayF | that gets passed down thru to the ipa paritioning code | 14:28 |
| JayF | and taht metadata-value is used to size the ESP | 14:28 |
| arne_wiebalck | I get that | 14:29 |
| JayF | (+add enough room for a raid superblock) | 14:29 |
| arne_wiebalck | but you would need to do this when you download/upload an image | 14:29 |
| JayF | IMO there are two problems being conflated here, which is OK since they are solved similarly: | 14:29 |
| JayF | 1) we aren't adding in extra size for raid metadata when raid is being used (to ensure ESP size remains expected usable) | 14:29 |
| dtantsur | well, a conductor can inspect the image | 14:29 |
| JayF | 2) ESP size is hardcoded in Ironic making it impossible for larger ESPs | 14:30 |
| TheJulia | ... larger ESPs... eek | 14:30 |
| arne_wiebalck | TheJulia: ++ | 14:30 |
| arne_wiebalck | there should be a use case for a larger ESP | 14:30 |
| dtantsur | imagine installers that only accept Gigabytes as units :D | 14:30 |
| JayF | I run all my machines with a 1GB combined ESP+Boot partition | 14:31 |
| JayF | it's not that weird of a setup for a desktop | 14:31 |
| arne_wiebalck | well, you combine two use cases | 14:31 |
| JayF | Whose to say some operator won't build their images in the same way :) I sorta feel this is reverse, we're hardcoding a value, we have to justify that as a project vs justifying odd values | 14:32 |
| dtantsur | Is it hard for us to inspect an image on the conductor side | 14:32 |
| JayF | we are the project that allows you to literally write deployment steps to do crazy crap during your deployment, and >.5GB ESP is a bridge too far? LOL | 14:32 |
| dtantsur | I know virt-* stuff actually launches a VM, but maybe there is something more lightweight? | 14:32 |
| JayF | dtantsur: my concern would be more about if there's a security door opened doing that | 14:32 |
| TheJulia | I guess my concern is increasing/changing the size is going to ripple. Steve changed some downstream image stuff only by a half gig and it has been a world of hurt | 14:33 |
| dtantsur | like, buffer overflow in an image parsing code? | 14:33 |
| JayF | dtantsur: I bet we can find a partition reading program that'd work on an image, second best case would be qemu-nbd loopback mounting it and feeding that to a fdisk | 14:33 |
| JayF | dtantsur: more if whatever inspection method we used actually mounted it | 14:33 |
| dtantsur | I'd really, really want to stop having root operations in ironic | 14:33 |
| jrosser | ^ this is exactly what we did when debugging it, using qemu-nbd + fdisk | 14:33 |
| dtantsur | jrosser: but that requires root, right? | 14:34 |
| JayF | `fdisk -l /path/to/disk.img` works | 14:34 |
| JayF | but I assume maybe only works on raw images? | 14:34 |
| dtantsur | JayF: for raw images | 14:34 |
| dtantsur | right | 14:34 |
| dtantsur | we do convert to raw images by default | 14:34 |
| jrosser | according to my notes we did it on a qcow2 | 14:35 |
| dtantsur | qemu-nbd will work, but will it work without root? | 14:35 |
| * dtantsur is looking at qemu-img map | 14:35 | |
| dtantsur | okay, so there is `qemu-img dd`, which we can probably use to extract the MBR/GPT metadata | 14:36 |
| * dtantsur is messing around with CLI | 14:41 | |
| dtantsur | I must say, the tools dislike only having the first part of the image.. | 14:49 |
| dtantsur | fdisk outputs nonsense. gdisk outputs seemingly real information, but does not strictly match virt-filesystems Oo | 14:52 |
| dtantsur | took the first 4MiB of a debian qcow2, got https://paste.opendev.org/show/bhgcMlkiCXPGe6Fs5c3m/ | 14:56 |
| dtantsur | EF00 is the code of a EFI partition | 14:56 |
| dtantsur | it's size is consistent with virt-filesystems btw. so we can use max(550, <this size>) | 14:59 |
| dtantsur | arne_wiebalck, jrosser ^^^ | 15:01 |
| dtantsur | the command was $ qemu-img dd -O raw count=100 if=debian-11-genericcloud-amd64.qcow2 of=/tmp/gpt | 15:02 |
| dtantsur | (so it was not 4M, I cannot count today) | 15:03 |
| jrosser | dtantsur: here is the same thing from an image created with dib https://paste.opendev.org/show/bY9EmqAjeoMYUKH2yNtm/ | 15:30 |
| dtantsur | jrosser: okay, so 550M. but it's not enough? | 15:32 |
| jrosser | for the error we had it's not a case of enough, it's that 550M is greater than 550M - 64K | 15:33 |
| jrosser | and 550M is hardcoded into ironic and also dib | 15:33 |
| jrosser | so short of hacking the source code to one of those, it doesnt fit | 15:34 |
| dtantsur | 64K - where does it come from? | 15:35 |
| dtantsur | we even seem to be using 551M in reality | 15:37 |
| jrosser | well i don't know - i'm assuming that it's some md superblock or something like that | 15:41 |
| JayF | 64k is the size of the md raid superblock | 15:42 |
| JayF | so that's what I assumed | 15:42 |
| dtantsur | okay, so the first and foremost fix, we need to account for that | 15:47 |
| JayF | One way is "if raid; add 64k" (really, probably just add a Meg or something to be safe) which could break existing assumptions from operators about what the math looks like on the rest of their drive | 15:49 |
| JayF | or we can raise the default ESP size slightly to avoid this particular error (quick fix), and then have some more complex logic for the metadata sizing and all moving forward like we talked about ^^ (long-term fix) | 15:49 |
| clarkb | fwiw I think dib lets you set all the partition sizes? The default is 550MiB per https://opendev.org/openstack/diskimage-builder/src/branch/master/diskimage_builder/elements/block-device-efi/block-device-default.yaml but ou can provide a different layout: https://docs.openstack.org/diskimage-builder/latest/user_guide/building_an_image.html#disk-image-layout | 15:55 |
| clarkb | there is probably something that can be chagned to make this a better user experience but ^ should work as a workaround in the interim? | 15:55 |
| jrosser | clarkb: oh my - all the time we spent trying to figure this out and didnt find that we could do that :/ | 16:05 |
| jrosser | you are right it really does boil down to needing a better user experience | 16:06 |
| prometheanfire | it looks like ramdisk deploys still require an image_source to be defined? https://github.com/openstack/ironic/blob/master/ironic/common/pxe_utils.py#L685-L692 | 17:36 |
| prometheanfire | docs state it went away in xena | 17:36 |
| JayF | https://github.com/openstack/ironic/blob/master/ironic/common/pxe_utils.py#L713 image properties being unset shouldn't be fatal | 17:38 |
| JayF | does that raise if no image_source? | 17:38 |
| prometheanfire | JayF: I'm setting kernel and ramdisk | 17:38 |
| TheJulia | https://github.com/openstack/ironic/blob/master/ironic/common/pxe_utils.py#L708-L712 | 17:39 |
| prometheanfire | is it possible to ramdisk boot a node with images stored in glance? | 17:39 |
| TheJulia | should be, I've never explicitly tried | 17:40 |
| * TheJulia lays down for a little bit | 17:41 | |
| prometheanfire | image_type seems to get set to partition in instance_info, which seems odd as deploy_interface is ramdisk | 17:41 |
| TheJulia | ugh, that is likely a bug inferring everything is just a partition image if a kernel/ramdisk is present | 17:41 |
| TheJulia | possibly due to naming as well | 17:42 |
| TheJulia | naming is hard, anyway, it shouldnt' be fatal to not have an image source | 17:42 |
| prometheanfire | trying to follow https://docs.openstack.org/ironic/latest/admin/ramdisk-boot.html | 17:42 |
| * JayF adds this to the list of troubleshooting he owes prometheanfire | 17:43 | |
| prometheanfire | lol, something to poke at | 17:43 |
| prometheanfire | I'll see if I can get a ramdisk boot to happen with glance, somehow | 17:44 |
| prometheanfire | https://paste.openstack.org/show/819356/ | 17:45 |
| JayF | prometheanfire: can you edit code directly? | 17:46 |
| JayF | I'm pretty sure if you just fixed the keyerror it'd work | 17:46 |
| prometheanfire | setting image source still has other errors it looks like, I'm guessing image_source is a dict | 17:46 |
| prometheanfire | ya | 17:46 |
| JayF | https://github.com/openstack/ironic/blob/master/ironic/common/pxe_utils.py#L691 change that to image_properties = None | 17:46 |
| JayF | and see if it works | 17:46 |
| JayF | I think that hard-requiring d_info to have an image_source may be the (only?) bug | 17:46 |
| JayF | it's certainly the first one lol | 17:46 |
| prometheanfire | no change, https://paste.openstack.org/show/819357 keep in mind the line numbers are for zed | 17:50 |
| JayF | ack; I'll have to take a bigger look later | 17:51 |
| prometheanfire | cool, thanks much | 17:51 |
| prometheanfire | JayF: 685 tries to access d_info['image_source'] as well | 17:55 |
| JayF | It'd be fun to see where/how it breaks if you fixed all the keyerrors | 18:00 |
| prometheanfire | setting that to None, causes ImageRefValidationFailed :D | 18:00 |
| prometheanfire | Scheme-less image href is not a UUID | 18:00 |
| prometheanfire | so maybe I'll look for a way to ramdisk boot via glance in the mean time | 18:00 |
| JayF | aight | 18:01 |
| ashinclouds[m] | I don’t remember what we do for tempest unfortunately | 18:01 |
| TheJulia | “/me fails at laying down and resting the brain for a few minutes | 18:02 |
| * JayF succeeded in attending two hours of TC PTG without falling asleep once lol | 18:02 | |
| TheJulia | Yay | 18:03 |
| JayF | video meetings of length are hard, even with periodic breaks | 18:03 |
| knikolla | just wait until the consecutive 4 hours on Thu-Fri :) | 18:22 |
| JayF | Ironic has I think 3/4 hour long sessions, we made time for breaks but it's still brutal | 18:23 |
| TheJulia | JayF: anything w/r/t oauth2? | 18:51 |
| JayF | TheJulia: I did not attend as the person replied on the mail list saying they were punting it to a time that was compatible | 18:56 |
| JayF | I think we can make 1500 UTC tomorrow work, actually | 18:57 |
| JayF | looking at the Tues schedule and the Weds APAC schdule -- I booked firmware upgrades in 2x places | 18:58 |
| TheJulia | Oh, okay | 18:58 |
| JayF | which gives us an extra 30 minutes on Tuesday | 18:58 |
| JayF | https://etherpad.opendev.org/p/ironic-bobcat-ptg sanity check before I reply to list | 18:58 |
| JayF | ? | 18:58 |
| * JayF would put the OAUTH 2.0 chat at 1500-1520, then a break, then move everything else +30min | 19:00 | |
| JayF | TheJulia: wdyt? | 19:00 |
| TheJulia | calendaring | 19:01 |
| TheJulia | that should work I think | 19:02 |
| TheJulia | JayF: added some comments to the oauth2 etherpad | 20:44 |
| JayF | ack | 20:46 |
| JayF | I have opinions along the lines of cheerleading "hooray this sounds awesome" but know very little about OAUTH2 and authentication in general | 20:47 |
| JayF | so happy to take a backseat in the discussion | 20:47 |
| JayF | (it's really nuts how little I know about OAUTH2 considering I used to work for Okta) | 20:47 |
| TheJulia | ack, the spec is very much in line with what is needed | 20:47 |
| prometheanfire | I don't see a way to ramdisk boot from glance | 20:47 |
| TheJulia | I have concern over how to get the the auth details into the client for the session | 20:48 |
| TheJulia | since an oauth2 provider can be a SSO portal | 20:48 |
| * TheJulia sees the wife is creating what looks like a hallway on a UNN Battleship in 3d on the other computer in the office | 20:48 | |
| JayF | The app I worked on at Okta did exactly that | 20:48 |
| JayF | you'd run a command to login (app auth login) | 20:48 |
| JayF | it'd open a browser on some platforms; on others it'd just print a URL | 20:49 |
| TheJulia | prometheanfire: well, that is a bug then :( | 20:49 |
| JayF | click the URL, copy+paste the result, press enter (or in supported platforms, just interact with the popped-up browser) | 20:49 |
| prometheanfire | oauth2 support will be nice | 20:49 |
| JayF | we'd have to probably have explicit support in a CLI client for it | 20:49 |
| TheJulia | I'm pretty sure I've seen a "launch browser window, login, and the token gets extracted back to the caller" | 20:50 |
| JayF | prometheanfire: if you're interested, we're talking about it in a cross project session tomorrow @ 1500 UTC in folsom | 20:50 |
| JayF | TheJulia: yep, I've done that multiple places :) | 20:50 |
| prometheanfire | probably too early for my blood (US/Central) | 20:50 |
| * TheJulia looks at her US Pacific timezone and thinks she will be well caffinated | 20:50 | |
| TheJulia | :) | 20:50 |
| TheJulia | ... as long as I make it to the supermarket after my doctor's appointment | 20:51 |
| JayF | prometheanfire: ...is 1500 UTC not 10am Central? | 20:51 |
| prometheanfire | hmm, actually not too bad, might make it | 20:51 |
| TheJulia | Hmm... the hallway could now be from the Anubis... | 20:51 |
| TheJulia | Anyway, happy to fix the bug prometheanfire (which might have worked, that is a tricky area of the code unfortunately) | 20:52 |
| TheJulia | Just might not be immediate | 20:53 |
| JayF | Yeah, and also he reported that it seems we broke cleaning on devices that held a software raid | 20:53 |
| JayF | I gotta dig into that to see if it's a regression, a misconfiguration, or "yes" | 20:53 |
| TheJulia | ... That I think is intentional | 20:53 |
| JayF | I am 99.9999% sure it had review feedback to be made the not-default | 20:54 |
| TheJulia | maybe, that was a while ago unfortunately | 20:54 |
| JayF | maybe I just made it optional? | 20:54 |
| JayF | yeah, it was | 20:54 |
| sean-k-mooney | JayF: are you still planning on working on the shard key enabling this cycle? | 21:00 |
| JayF | sean-k-mooney: I'd like for that work to proceed (in nova driver) with John Garbutt leading it. I'm working on the backend to make sure he has time to do so. | 21:00 |
| sean-k-mooney | ack if the code gets written we would be happy to review | 21:02 |
| sean-k-mooney | i just wanted to make sure that it was still planned to proceed | 21:02 |
| JayF | the hope is yes; I'll even work on it myself if I have to, but I don't think that'd be ideal :D | 21:03 |
| TheJulia | did the spec get approved on the nova side? | 21:06 |
| sean-k-mooney | it did last cycle | 21:06 |
| TheJulia | k | 21:06 |
| sean-k-mooney | it techniclaly need to be propsoed again but we have a fast reappal policy if its not changed | 21:06 |
| sean-k-mooney | other then the release names ectra | 21:06 |
| * prometheanfire tried to create an ironic bug but storyboard still hates me I think, here's the text I'd put in one https://paste.openstack.org/raw/bf1GtDV8GxUq9qdK59Ir/ | 21:07 | |
| sean-k-mooney | so i dont think that will be a blocker just paper work | 21:07 |
| prometheanfire | I tried setting the kernel and ramdisk to be glance image IDs and that failed as well (set image_source in case as well), should that be a separate bug? | 21:08 |
| sean-k-mooney | so its failng here https://github.com/openstack/ironic/blob/master/ironic/common/pxe_utils.py#L682-L689 | 21:10 |
| prometheanfire | ya, thereabouts | 21:10 |
| sean-k-mooney | https://github.com/openstack/ironic/commit/7b47e09a385d388854a3c81bc13c333b36c18a36 | 21:10 |
| sean-k-mooney | thats what last changed that | 21:11 |
| sean-k-mooney | but thats the extent of my git foo | 21:12 |
| prometheanfire | I saw that, maybe I should revert more fully to test | 21:12 |
| prometheanfire | and maybe glance will work again when setting kernel=glance_uuid and ramdisk=glance_uuid (not sure if that ever worked though, being honest) | 21:13 |
| sean-k-mooney | i think it did at least i only ever rememebr using glance uuid with ironic | 21:14 |
| prometheanfire | sean-k-mooney: to boot ramdisks nodes (meaning https://docs.openstack.org/ironic/zed/admin/ramdisk-boot.html )? | 21:15 |
| JayF | yeah I think we probably introduced a bug around that | 21:16 |
| JayF | when improving anaconda support | 21:16 |
| JayF | looking at the code, I think there's something there to fix | 21:17 |
| JayF | not just bad docs | 21:17 |
| sean-k-mooney | i have only ever really used ironic via nova or kolla-ansible/biforst so i dont really know how this works in detail | 21:17 |
| JayF | ramdisk deploy is one of our cooler features sean-k-mooney | 21:18 |
| JayF | basically instead of installing an OS, you just don't. and boot a ramdisk instead. | 21:18 |
| JayF | It should be a ton simpler, but we managed to break it anyway. Bugs are like that LOL | 21:18 |
| * prometheanfire wants to boot a harvester cluster, and one if their deploy methods is ramdisk, the other is iso... | 21:19 | |
| sean-k-mooney | ah ok so using http boot or simialr | 21:19 |
| prometheanfire | kinda, but not really, files still served over tftp | 21:20 |
| JayF | or not :) that's the magic of Ironic | 21:20 |
| JayF | prometheanfire: we *can* do that I believe | 21:20 |
| JayF | but you don't have to | 21:20 |
| sean-k-mooney | well i have pxebooted home servres form a ramdisk before i just assuemd thie is either using legacy pxe with tftp or redfhist httpboot | 21:21 |
| sean-k-mooney | depending on what your hardware suports and you ahve cofnigured | 21:21 |
| JayF | I think we might even support ramdisk deployments where the "ramdisk" is inserted as a virtual media device | 21:21 |
| sean-k-mooney | like the IPA ramdisk was always just booted over the netwrok so now your jsut booting something else right | 21:21 |
| JayF | pretty much-ish? I think there's some additional magic needed because of network switching but I'm not super familiar with the feature | 21:22 |
| prometheanfire | JayF: yep, I wanted to do that, but this server is finicky with ipxe | 21:22 |
| sean-k-mooney | my issue with thse features is the only servers i have that have bmcs at home wer made aroud 2011 | 21:22 |
| prometheanfire | so new? | 21:23 |
| sean-k-mooney | so bios only, with ssd coonected over sata 2 | 21:23 |
| JayF | did we deprecate legacy bios boot yet? I know it was a ptg topic at one point | 21:24 |
| prometheanfire | no, default changed to uefi | 21:24 |
| sean-k-mooney | still got 2 8 core cpus and 48GB of ram so fine dev but way to power ineffect at this point to keep running | 21:24 |
| JayF | Next time I build a desktop, I'm taking my current one (5950x 16c/32t + 64GB ram) and turning it into a 24/7 dev VM host | 21:25 |
| JayF | if I didn't have to reboot into windows to do my streams, or kill VMs to play a game, I'd probably be using it now | 21:25 |
| sean-k-mooney | why not stream from linux | 21:26 |
| prometheanfire | JayF: sean-k-mooney with revert still getting the same image_source keyerror | 21:26 |
| sean-k-mooney | also i can recommend steam decks they work pretty well | 21:26 |
| JayF | I've encountered bugs, multiple times, where OBS Studio audio meters will be bouncing around like audio is going thru, but nothing is going out the stream | 21:26 |
| JayF | even is audio in the recording, but not going out to the stream | 21:26 |
| JayF | and it's not every time, but it's frequently enough that when I gotta do streams as part of my job, I can't justify it just randomly not working time to time | 21:27 |
| JayF | sean-k-mooney: I own a steam deck and do 99.999% of my gaming in linux; literally am only rebooting at this point for streaming | 21:28 |
| * TheJulia whispers ‘instance_info/boot_iso’ to prometheanfire | 21:29 | |
| sean-k-mooney | prometheanfire: what about https://github.com/openstack/ironic/commit/4d653ac225a26dd83e81477f9d1152fe385c64aa#diff-04a54f43c1423729b0eab47a9f7ae102af6b1c68b3f897071362bf898fe33788 | 21:29 |
| prometheanfire | TheJulia: work with ipmi driver? | 21:29 |
| TheJulia | sean-k-mooney: my gut feeling is that is where I broke it | 21:30 |
| sean-k-mooney | im wondering if its related to " if not image_properties:" > " if not image_properties and not isap:" | 21:30 |
| JayF | yeah I think we broke it when we added isap | 21:30 |
| TheJulia | prometheanfire: yes, as long as the boot_interfacenis ipxe | 21:30 |
| JayF | ...which is the linked commit | 21:30 |
| TheJulia | And there are not other files on the disk | 21:30 |
| JayF | that was a scary one to review, I remember it still | 21:30 |
| prometheanfire | TheJulia: heh, I guess I'll test | 21:31 |
| TheJulia | prometheanfire: if everything is in the ramdisk on the iso, it should fire up. | 21:31 |
| prometheanfire | I was having problems with ipxe | 21:31 |
| sean-k-mooney | anywya im going to go eat and relax o/ | 21:31 |
| * TheJulia goes to meet new doctor | 21:32 | |
| prometheanfire | sean-k-mooney: yarp, I'll test reverting both patches | 21:32 |
| * prometheanfire is about to go pick up baby | 21:32 | |
| prometheanfire | I can confirm that with that commit reverted it's attempting to deploy | 21:50 |
| prometheanfire | now, have to run before it finishes, it's downloading the ramfs now (to cache) | 21:51 |
| TheJulia | JayF: deprecating legacybios was a question at one point, but we had some vendors say they will support it forever | 22:42 |
| TheJulia | Plus there are downsides with the other hardware platforms | 22:45 |
| JayF | makes sense | 23:00 |
| TheJulia | prometheanfire: ack ack, thanks for the data point | 23:36 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!