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

enhance(pxe): Add Network PXE boot option, doc, and examples #492

Merged
merged 3 commits into from
Feb 4, 2022

Conversation

sygibson
Copy link
Contributor

@sygibson sygibson commented Feb 2, 2022

Adds support to the Terraform Provider Proxmox capabilities for PXE booted VMs. Addresses the following reported issues:

The following changes have been made:

  • support for the upstream proxmox-api-go PXE feature added at commit 20220113001728-0c6f43a60b62
  • allows use of pxe = true in Terraform resource definition, which is exclussive of Clone and ISO modes
  • validates the boot options to ensure a Network boot order is set first
  • skips the forced ISO evaluation code, when PXE mode is set
  • adds a minimal test case
  • adds note to "Known Limitations" in main README.md
  • adds appropriate documentation for the vm_qemu.md
  • updates go.mod and go.sum appropriately
  • adds a pxe_example.tf sample

If this PR is accepted, I would ask that a new Release (presumably v2.9.5) be cut, so the requires statements will pull in the right version with the PXE support.

@sygibson
Copy link
Contributor Author

sygibson commented Feb 2, 2022

@mleone87 - thank you for your help with merging the upstream options in to Telemate/proxmox-api-go which I submitted.

Hoping that you can help move this through, tag, and release (presumably v2.9.5) this enhancement.

Much appreciated!

My apologies about the go.mod and go.sum conflicts - I'm not sure what I'm supposed to do with those to prevent the conflicts. I bumped the go.mod to include the upstream commit require:

  • github.com/Telmate/proxmox-api-go v0.0.0-20220113001728-0c6f43a60b62

Then did go mod tidy which modified go.sum.

@sygibson
Copy link
Contributor Author

sygibson commented Feb 2, 2022

Ok - corrected the conflicts ... I failed to re-sync my Fork prior to generating the go.mod and go.sum changes. I thought I was working off of the freshest set of changes.

@sygibson
Copy link
Contributor Author

sygibson commented Feb 3, 2022

@mleone87 - I might have fixed the test failures. I am not able to replicate running the tests in my environment, so I'm not certain on that.

@mleone87
Copy link
Collaborator

mleone87 commented Feb 4, 2022

great work!

@mleone87 mleone87 merged commit b2d39bb into Telmate:master Feb 4, 2022
@sygibson
Copy link
Contributor Author

sygibson commented Feb 4, 2022

@mleone87 - what is the process to have the 2.9.5 release provider made available in the Terraform registry ? Is there something else I need to do to make that happen ? Or am I just being too impatient waiting for it to be pushed up ?

Thank you for your help in ushering this through and being patient with me.

@mleone87
Copy link
Collaborator

mleone87 commented Feb 4, 2022

@mleone87 - what is the process to have the 2.9.5 release provider made available in the Terraform registry ? Is there something else I need to do to make that happen ? Or am I just being too impatient waiting for it to be pushed up ?

Thank you for your help in ushering this through and being patient with me.

Nothing, the release process already creates the assets and terraform already pulls them

@jValdron
Copy link

This is problematic for setting up a VM from PXE:

validates the boot options to ensure a Network boot order is set first

We shouldn't need to have network boot as the first option. Having boot to disk, then PXE, makes sense when you need to do an initial install of a VM through PXE, but want boot directly from disk afterwards.

@sygibson
Copy link
Contributor Author

@jValdron - a commit has already been made to adjust the validation to check that "network" exists "somewhere" in the boot order, but is no longer required as the first option.

In our use cases, Network is always first, and out infrastructure automation always controls what the Node or Machine should boot to on next boot. This allows the automation to boot systems, and take back control for things like BIOS updates, Firmware updates, decommissioning, recommissioning, audit compliance checks, maintenance break/fix reasons, etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants