On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard cbouchar@redhat.com wrote:

Hi Ruby:

I couldn't use your whole changeset since it introduced a different issue. With your patch, I was seeing the following error and it never reached the code creating squashfs.img as a directory. So I removed the patch and only applied the pxe_util.py changes in cache_ramdisk_kernel() and I've made further progress.

*| last_error | Failed to prepare to deploy: Cannot validate driver deploy. Some parameters were missing in node's instance_info. Missing are: ['root_gb'] |*

Is this root_gb a new requirement? More background: At the moment, I don't have baremetal devices and I'm starting my work by using VMs bifrost created for me. Also I'm using the xena branch of bifrost/ironic.

Carol

root_gb is old. I suspect bifrost doesn't use/need that information. If all the info you have for using the anaconda deploy interface is in the OS image or via configs, you'll be ok. Although when that patch merges, it'll break your use case if the VM-ironic-node doesn't have instance_info['root_gb'] specified. That code is getting triggered via:

PXEAnacondaDeploy.prepare(): node.instance_info = deploy_utils.build_instance_info_for_deploy( task). which causes this code to be invoked [1]

To get around it, you could set the ironic node's instance_info to have 'root_gb' = <some value>. Eg: "openstack baremetal node set <node> --instance-info root_gb=10"

It seems to me that we might want to modify the code to handle this (any takers?)

--ruby

[1]: https://opendev.org/openstack/ironic/src/commit/a4a89d6b20a03e692e0550e3a34a...

On Mon, Feb 7, 2022 at 11:56 AM Ruby Loo opensrloo@gmail.com wrote:

...

Hi Carol,

Thanks for reporting this! It is a bug :-( The fix is in https://review.opendev.org/c/openstack/ironic/+/827924.

--ruby

On Fri, Feb 4, 2022 at 11:44 AM Carol Bouchard cbouchar@redhat.com wrote:

...

Ironic folks:

I'm trying to spawn a RHEL7 image using a kickstart file and having issues with stage2 file. First I used bifrost to initially setup a couple of VMs. (There is no openstack/glance). I'm now using one of those VMs to boot up with RHEL7. I changed the VM config with the following:

*| deploy_interface | anaconda*

• | instance_info | {'kernel': 'http://myip:8080/RHEL7/vmlinuz

http://myip:8080/RHEL7/vmlinuz', 'ramdisk': 'http://myip:8080/RHEL7/initrd.img http://myip:8080/RHEL7/initrd.img', 'image_source': 'http://myip:8080/RHEL7/initrd.img http://myip:8080/RHEL7/initrd.img', 'stage2': 'http://myip:8080/RHEL7/squashfs.img http://myip:8080/RHEL7/squashfs.img', 'ks_cfg': 'http://myip:8080/RHEL7/ks.cfg.template http://myip:8080/RHEL7/ks.cfg.template', 'ks_template': 'http://myip:8080/RHEL7/ks.cfg.template http://myip:8080/RHEL7/ks.cfg.template'}*

ironic.conf changes I made are as follows:

*enabled_deploy_interfaces = direct,ramdisk,anaconda*

*[anaconda]default_ks_template = file:///etc/ironic/ks.cfg.template*

The error I'm getting is as follows: *$ baremetal node show testvm1 --field last_error*

*| last_error | Deploy step deploy.deploy failed with IsADirectoryError: [Errno 21] Is a directory: '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'.* Tail end of traceback is as follows:

• ironic-conductor[]: ERROR ironic.conductor.utils File

"/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/common/pxe_utils.py", line 1245, in cache_ramdisk_kernel ironic-conductor[]: ERROR ironic.conductor.utils deploy_utils.fetch_images(ctx, TFTPImageCache(), list(t_pxe_info.values()), ironic-conductor[]: ERROR ironic.conductor.utils File "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/deploy_utils.py", line 240, in fetch_images ironic-conductor[]: ERROR ironic.conductor.utils cache.fetch_image(href, path, ctx=ctx, force_raw=force_raw) ironic-conductor[]: ERROR ironic.conductor.utils File "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py", line 120, in fetch_image ironic-conductor[]: ERROR ironic.conductor.utils dest_up_to_date = _delete_dest_path_if_stale(master_path, ironic-conductor[]: ERROR ironic.conductor.utils File "/opt/stack/bifrost/lib64/python3.9/site-packages/ironic/drivers/modules/image_cache.py", line 460, in _delete_dest_path_if_stale ironic-conductor[]: ERROR ironic.conductor.utils os.unlink(dest_path) ironic-conductor[]: ERROR ironic.conductor.utils IsADirectoryError: [Errno 21] Is a directory: '/httpboot/4e41df61-84b1-5856-bfb6-6b5f2cd3dd11/LiveOS/squashfs.img'*

Please advise.

Carol

On Mon, Feb 7, 2022 at 3:30 PM Julia Kreger juliaashleykreger@gmail.com wrote:

On Mon, Feb 7, 2022 at 12:21 PM Ruby Loo opensrloo@gmail.com wrote:

...

On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard cbouchar@redhat.com

wrote:

...

...

[trim]

...

...

Is this root_gb a new requirement? More background: At the moment, I

don't have baremetal devices and I'm starting my work by

...

...

using VMs bifrost created for me. Also I'm using the xena branch of

bifrost/ironic.

...

...

Carol

root_gb is old. I suspect bifrost doesn't use/need that information. If

all the info you have for using the anaconda deploy interface is in the OS image or via configs, you'll be ok. Although when that patch merges, it'll break your use case if the VM-ironic-node doesn't have instance_info['root_gb'] specified. That code is getting triggered via:

...

PXEAnacondaDeploy.prepare(): node.instance_info =

deploy_utils.build_instance_info_for_deploy(

...

            task).

which causes this code to be invoked [1]

To get around it, you could set the ironic node's instance_info to have

'root_gb' = <some value>. Eg: "openstack baremetal node set <node> --instance-info root_gb=10"

Yeah, we really need to nuke the requirement, but I could see it still being needed if someone tries to perform a partition image deployment. That being said, I don't think we should be requiring it on the anaconda deployment interface.

Bifrost largely was designed around just deploying whole disk images, which is why it is not present on the node.

<snip>

Ok, I updated the PR [1] to skip the root_gb check. The updated PR won't automatically backport nicely (because of a recent change to master) but it isn't too difficult to manually fix. Hopefully there won't be other issues ;)

[1] https://review.opendev.org/c/openstack/ironic/+/827924/3