Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting boot devices in virt.running and virt.defined states #57544

Closed
cbosdo opened this issue Jun 4, 2020 · 5 comments · Fixed by #57545
Closed

Allow setting boot devices in virt.running and virt.defined states #57544

cbosdo opened this issue Jun 4, 2020 · 5 comments · Fixed by #57545
Labels
Feature new functionality including changes to functionality and code refactors, etc.

Comments

@cbosdo
Copy link
Contributor

cbosdo commented Jun 4, 2020

Is your feature request related to a problem? Please describe.

virt.init() module has an undocumented boot_dev parameter for ages that allows setting the boot devices order for a VM. This parameter needs to be provided also in the virt.running and virt.defined states for users to be able to create VMs booting using PXE or using an attached CDROM.

@cbosdo cbosdo added the Feature new functionality including changes to functionality and code refactors, etc. label Jun 4, 2020
@dmurphy18 dmurphy18 added the info-needed waiting for more info label Jun 5, 2020
@dmurphy18 dmurphy18 added this to the Blocked milestone Jun 5, 2020
@dmurphy18 dmurphy18 self-assigned this Jun 5, 2020
@dmurphy18
Copy link
Contributor

@cbosdo Using undocumented feature and parameters, even if they have been around for ages, is not a good policy for system software. If can request the upstream maintainers for virt to document that boot_dev parameter, then SaltStack will consider the Feature Request.

Generally SaltStack only uses documented features, api's, parameters, etc.
If you want to discuss this further I shall hold this issue open over the weekend and intend closing on Monday if no further discussion

@cbosdo
Copy link
Contributor Author

cbosdo commented Jun 7, 2020

@dmurphy18 the point is that boot_dev parameter is a parameter of virt.init that was hidden in **kwargs for ages... and this issue is about making it documented. I can only agree with you that hiding parameters is not a good practice.

@dmurphy18 dmurphy18 removed their assignment Jun 8, 2020
@dmurphy18 dmurphy18 removed the info-needed waiting for more info label Jun 8, 2020
@dmurphy18 dmurphy18 removed this from the Blocked milestone Jun 8, 2020
@dmurphy18
Copy link
Contributor

@cbosdo Well arguing without you about boot_dev is pointless, went checking and it is already in the code for Sodium at least.

 683     context["graphics"] = graphics
 684 
 685     if "boot_dev" in kwargs:
 686         context["boot_dev"] = []
 687         for dev in kwargs["boot_dev"].split():
 688             context["boot_dev"].append(dev)
 689     else:
 690         context["boot_dev"] = ["hd"]
 691 
 692     context["boot"] = boot if boot else {}
 693 
 694     # if efi parameter is specified, prepare os_attrib
 695     efi_value = context["boot"].get("efi", None) if boot else None
 696     if efi_value is True:
 697         context["boot"]["os_attrib"] = "firmware='efi'"
"modules/virt.py" 6854 lines --10%--

Also check out 'def init()' in the same module

1655     :param boot_dev: String of space-separated devices to boot from (Default: ``'hd'``)

Going to close this feature request since the code already has it. If it is not working correctly, please open an issue describing the problem, and even better a PR with tests that fixes the issue.

@cbosdo
Copy link
Contributor Author

cbosdo commented Jun 8, 2020

@dmurphy18 The point of this issue was not that it wasn't in virt.init(), but that it was not exposed in the virt states using that function, namely virt.running and virt.defined.

And I also submitted a PR to implement it. See PR #57545

@dmurphy18
Copy link
Contributor

@cbosdo Sorry about that, initially took different meaning from your first sentence. Thanks for the PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature new functionality including changes to functionality and code refactors, etc.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants