| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-05 | |||
| 19:24:52 | sean-k-mooney | because you defien extra routs and the dns servers on the subnet | |
| 19:25:04 | sean-k-mooney | so i was expect the dhcp option ot also be on the subnet | |
| 19:25:23 | sean-k-mooney | JayF: so ya i dont see why you could not do pxe boot today | |
| 19:25:45 | sean-k-mooney | and it woudl be simple enough to add another port extention that nova could read to allow it to be used as the boot device | |
| 19:27:57 | sean-k-mooney | i should try doing this someday and write a doc... | |
| 19:29:08 | sean-k-mooney | JayF: there is even openstack client support for this | |
| 19:30:29 | JayF | yeah like, I don't want this feature personally | |
| 19:30:39 | JayF | but I figured ironic might be a model for doing it (or at least pointing in a direction) | |
| 19:30:53 | JayF | hint: this also could be used to enable UEFI HTTPBoot, which is superior to pxe in every way | |
| 19:31:15 | JayF | this being said: Ironic-Conductor spins up and manages the tftp server. There is no neutron answer to that aiui. | |
| 19:31:21 | sean-k-mooney | JayF: well since you say that if the ovmf file that wemu is using support that | |
| 19:31:28 | sean-k-mooney | then that woudl also already work today | |
| 19:32:14 | sean-k-mooney | enableing the boot memu allow you to use any of the facilites in teh uefi firmware provide by your host ovmf uefi image | |
| 19:33:01 | sean-k-mooney | is its really a question of does qemu/ovmf supprot http boot if so you could in thory use it | |
| 19:37:02 | JayF | I guess that's kinda true, it still comes over dhcp information | |
| 19:37:14 | JayF | so from a nova perspective, especially if you don't own the tftp/http/whatever server, it doesn't matter | |
| 19:37:15 | sean-k-mooney | yep i have it up locally | |
| 19:37:35 | sean-k-mooney | so my ovmf firmware supprot uefi and pxe boot | |
| 19:37:44 | sean-k-mooney | *http and pxe boot | |
| 19:38:22 | sean-k-mooney | i dont have dhcp confirued on my local libvirt to provide the dhcp options | |
| 19:38:32 | sean-k-mooney | but i dont see why you could not make this work today | |
| 19:39:06 | sean-k-mooney | it would be a lot cleaner however to have a neturon prot extion to just lable the port a boot souce | |
| 19:39:27 | sean-k-mooney | then we could add the libvirt xml to make it boot form that first and then fallback to the local disk | |
| 19:40:26 | sean-k-mooney | anywya i should finish for the day | |
| 19:40:49 | sean-k-mooney | JayF: before i go did ye get the auto lessee suff finished on the ironic side | |
| 19:41:07 | JayF | It's got one +2, waiting review, basically paused since we got CVE patches in the gate | |
| 19:41:13 | JayF | it'll be in this release, we don't FF like nova does :) | |
| 19:41:36 | sean-k-mooney | good to know and ya i saw the maile yesterday | |
| 19:41:40 | JayF | only piece missing that I promised, that frankly I forgot about until I looked at the BP yesterday is the migration script | |
| 19:42:06 | JayF | that'll be trivial to write and document :) | |
| 19:42:35 | JayF | although TBH I am extremely skeptical any operators will actually want to backfill lessee | |
| 19:49:46 | sean-k-mooney | ya it might be nice to put that in an ironic-manage command or similar | |
| 19:49:58 | sean-k-mooney | but it does not sound like its a blocker for the feature ot be used | |
| 19:50:15 | sean-k-mooney | jsut a nice to have for consitency | |
| 19:50:45 | sean-k-mooney | JayF: i assume an admin could just manually set the lessee on the ironic node if they wanted too | |
| 19:51:59 | JayF | We do not have an ironic-manage command, I was just going to add something to our tools/ directory | |
| 19:52:24 | JayF | basically just for each ironic node with non-null instance_uuid, check nova for instance owner, and set it on the node | |
| 19:52:44 | JayF | with probably an option for shard (so you can do N processes to parallelize) | |
| 19:53:06 | sean-k-mooney | JayF: oh really so you dont have an ironic-manage db_sync? | |
| 19:53:16 | sean-k-mooney | how do ye manage db upgrade in ironic? | |
| 19:53:19 | JayF | I thought it was ironic-dbsync? | |
| 19:53:20 | JayF | IMBW | |
| 19:53:58 | sean-k-mooney | yep https://opendev.org/openstack/ironic/src/branch/master/setup.cfg#L49 | |
| 19:54:23 | sean-k-mooney | ok i tought <project>-manage was the normal convention for that tool | |
| 19:54:34 | sean-k-mooney | but i ugess there is no really reason not to call it something else | |
| 19:54:56 | sean-k-mooney | ok actully stoping for today this time o/ | |
| 19:54:58 | JayF | yeah and TBH, with my operator hat on, I prefer tools like this not to require the whole app | |
| 19:55:19 | JayF | (pip install nova to get nova-manage just feels overkill, even if it's not, really) | |
| 19:55:53 | sean-k-mooney | well its internally using the same oslo version object and db fucntion ectra | |
| 19:56:06 | sean-k-mooney | but ya we normally intend it to be run form where the conductor is | |
| 19:56:17 | JayF | yeah, in this case though, I want to write a tool that's 100% API-shaped, no db magic needed | |
| 19:56:23 | sean-k-mooney | it can be run remotely but that not what we expect peopel to do | |
| 19:56:32 | JayF | I can tell you I've worked zero places that ran it, at upgrade time, from a nova-anything :) | |
| 19:56:34 | sean-k-mooney | right makes sense | |
| 19:57:15 | sean-k-mooney | well its normally ran form yoru openstack contoler nodes | |
| 19:57:44 | sean-k-mooney | in contaieriesed installer yousually the nova-conductor container just because it already had the correct configs | |
| 19:58:23 | sean-k-mooney | we have discussed having the conductore be able to just do it automatically in teh past when its starts | |
| 19:58:36 | sean-k-mooney | but that alway felt a little too much out fo scope | |
| 20:01:25 | JayF | yeah most places I worked did "N" version upgrades at once, so we'd just have someone spin up a dedicated machine that we'd upgrade through the intermediate versions to do all the migrations | |
| 20:01:52 | JayF | we went O->U at one place using that kinda model | |
| 23:08:58 | opendevreview | melanie witt proposed openstack/nova master: docs: Change note:: to warning:: for service user token https://review.opendev.org/c/openstack/nova/+/928308 | |
| #openstack-nova - 2024-09-06 | |||
| 00:27:02 | opendevreview | melanie witt proposed openstack/nova master: docs: Show the recommended way to PXE boot an instance https://review.opendev.org/c/openstack/nova/+/928309 | |
| 02:11:11 | opendevreview | sean mooney proposed openstack/nova master: [WIP] Add functional repoducer for ephemeral disks https://review.opendev.org/c/openstack/nova/+/928310 | |
| 08:10:56 | elodilles | melwitt: sean-k-mooney explained perfectly o:) thanks sean-k-mooney o/ | |
| 11:07:13 | opendevreview | Fabian Wiesel proposed openstack/nova master: Vmware: Remove uuid parameter from get_vmdk_info call https://review.opendev.org/c/openstack/nova/+/910627 | |
| 13:08:23 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928353 | |
| 13:08:25 | opendevreview | OpenStack Release Bot proposed openstack/os-vif stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928355 | |
| 13:08:27 | opendevreview | OpenStack Release Bot proposed openstack/os-vif master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928356 | |
| 13:08:31 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/osc-placement/+/928358 | |
| 13:08:33 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/osc-placement/+/928359 | |
| 13:08:34 | opendevreview | OpenStack Release Bot proposed openstack/osc-placement master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/osc-placement/+/928360 | |
| 13:08:42 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/python-novaclient/+/928363 | |
| 13:08:43 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/python-novaclient/+/928364 | |
| 13:08:44 | opendevreview | OpenStack Release Bot proposed openstack/python-novaclient master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/python-novaclient/+/928366 | |
| 13:38:45 | sean-k-mooney | dansmith: so i tought i had a fix for https://review.opendev.org/c/openstack/nova/+/928310/1/nova/tests/functional/regressions/test_bug_backing_file_partion_tables.py | |
| 13:39:05 | sean-k-mooney | and then whe i treid it i reasised that its more complex then i hoped | |
| 13:39:57 | sean-k-mooney | tl;dr is the mbr/gpt inspector is not only looking for a gpt partion table to exist its also looking for a os partion | |
| 13:40:22 | sean-k-mooney | for epmeral and swap disk that is not really a valid expecatoin | |
| 13:40:56 | sean-k-mooney | so just addign a gpt tabel and vfat partion is not enough to pass the safty check | |
| 13:42:17 | dansmith | It's not looking at the gpt part at all, | |
| 13:42:26 | dansmith | it's looking at the PMBR to make sure you have the right single entry | |
| 13:42:59 | sean-k-mooney | yes its looking at the mbr part | |
| 13:44:15 | dansmith | the mbr needs to have at least one partition that is not type EE, or a single type EE starting at the first sector | |
| 13:44:56 | sean-k-mooney | i likely can make that happen | |
| 13:45:18 | sean-k-mooney | but using our existign create partion tbale and create partion functions didnt seam to be enough | |
| 13:45:52 | dansmith | can you show me fdisk -l of what we create? | |
| 13:46:25 | sean-k-mooney | sure ill need to recreate the image but ill chuck taht in termbin in a sec | |
| 13:49:02 | sean-k-mooney | https://termbin.com/86m6 | |
| 13:49:29 | sean-k-mooney | i can get it to pass the first test_create_file but not test_cache_file | |
| 13:49:51 | opendevreview | Merged openstack/os-vif master: Update master for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928356 | |
| 13:50:11 | dansmith | okay that doesn't show the mbr part because it skips right over, but must have a real pmbr | |
| 13:50:28 | dansmith | can you grab just the first like 4k of that and post it for me somewhere? | |
| 13:50:36 | dansmith | (if it's easy) | |
| 13:51:38 | sean-k-mooney | sure i have this running in a debugger adn im stop right after we hcage created the image but before we call mkfs on it | |
| 13:51:54 | sean-k-mooney | im wonder fi that will alter the output but ill grab the first 4k first and then proceed | |
| 13:52:16 | dansmith | hmm, how is mkfs going to run on just the partition of a file? | |
| 13:52:27 | dansmith | ...without kpartx or something | |
| 13:52:52 | sean-k-mooney | im actully expecting it to recreate teh gpt and partion table | |
| 13:52:59 | dansmith | mkfs will definitely not do that | |
| 13:53:14 | sean-k-mooney | ok then we might need to actuly loop mount it | |