[ironic]Anaconda deploy interface config

Ruby Loo opensrloo at gmail.com
Tue Feb 8 18:05:30 UTC 2022


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

> On Mon, Feb 7, 2022 at 12:21 PM Ruby Loo <opensrloo at gmail.com> wrote:
> >
> >
> >
> > On Mon, Feb 7, 2022 at 2:20 PM Carol Bouchard <cbouchar at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20220208/3821480e/attachment.htm>


More information about the openstack-discuss mailing list