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

[Issue 71] Adds convert_to_template option to proxmox builders #72

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

LethalServant
Copy link

@LethalServant LethalServant commented Mar 7, 2022

Adds convert_to_template bool option to proxmox-iso and proxmox-clone builders configuration.
This gives the user more control over the machine image, whether it stays a VM or is converted to a VM Template.
The convert_to_template option is optional, and the default value is false, resulting in the VM not being converted to a template.
In practice the option is only need if the user wants the machine image to become a VM Template.

Tests:
Given working proxmox-iso and proxmox-clone packer file configurations, the following values were changed and run for each builder:

convert_to_template      = true  // result: vm is a template
convert_to_template      = false // result: vm is not a template 
remove convert_to_template option, testing default value // result: vm is not a template

Closes #71

@LethalServant LethalServant requested a review from a team as a code owner March 7, 2022 01:37
@hashicorp-cla
Copy link

hashicorp-cla commented Mar 7, 2022

CLA assistant check
All committers have signed the CLA.

@LethalServant LethalServant changed the title Issue 71 [Issue 71] Adds convert_to_template bool option Mar 7, 2022
@LethalServant LethalServant changed the title [Issue 71] Adds convert_to_template bool option [Issue 71] Adds convert_to_template option Mar 7, 2022
@LethalServant LethalServant changed the title [Issue 71] Adds convert_to_template option [Issue 71] Adds convert_to_template option to proxmox builders Mar 7, 2022
@carlpett
Copy link
Contributor

carlpett commented Apr 7, 2022

Hi @LethalServant,
So this would change the default behaviour of the builder quite a bit, is there a compelling reason for this?

@sylviamoss
Copy link
Contributor

@LethalServant do you have any update on @carlpett's question?

@adrian-hoasted
Copy link

It should keep the default behaviour of converting into a template.
and if the option is set, it should change the default behaviour to leave the VM.

ie.
The convert_to_template option is optional, and the default value is TRUE, resulting in the VM being converted to a template. If the value is set to FALSE, no template is created. This would prevent a breaking change.

Copy link
Contributor

@sylviamoss sylviamoss left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see this is indeed changing the default behavior and I figure that's not your intention as you mentioned in our previous comment.

@@ -64,6 +64,7 @@ type Config struct {

TemplateName string `mapstructure:"template_name"`
TemplateDescription string `mapstructure:"template_description"`
ConvertToTemplate bool `mapstructure:"convert_to_template"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default of this configuration will always be false which will indeed change the default behavior of the builder. Also, in the prepare method you're explicitly setting it to false as default.

If the intention is to not change the default behavior, the default should be true. In this case, you can:

  • Use Trilian, a custom type available in the SDK for this type of configuration
  • Rename it to skip_convert_to_template that will skip converting to template when set to true. The default will be automatically false.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sylviamoss Thanks for the feedback, this should be resolved now.

coreSteps = append(coreSteps, &stepStopVM{})

if b.config.ConvertToTemplate {
coreSteps = append(coreSteps, &stepConvertToTemplate{})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like better when we pass the configuration to the step and within the step is determined if it should be skipped or not based on the configuration. It makes it easier to log "Skipping ..." and keeps this step slice clean.

@zakx
Copy link

zakx commented Sep 27, 2022

It's been two months, any update on this? Would love to have this functionality.

@nywilken
Copy link
Contributor

nywilken commented Nov 1, 2022

It's been two months, any update on this? Would love to have this functionality.

Hi @LethalServant thanks for working to push this forward. We haven't had a chance to review this since you last updated. But I'm adding it to our planning board so we can give it some cycles next week. Quickly looking at the approach I don't know if skip_convert_to_template is the best way to avoid changing the default behavior.

I will be releasing a new version of the plugin today v1.1.0 to address #119. After that change we can work to get this change in. Thanks again for pushing this change forward and for sticking with us.

@nywilken nywilken added the version/bump minor A PR that changes behavior or contains breaking changes template configuration options. label Nov 1, 2022
@nywilken nywilken requested review from sylviamoss and removed request for sylviamoss November 1, 2022 16:29
Copy link
Contributor

@lbajolet-hashicorp lbajolet-hashicorp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @LethalServant,

First off, apologies for letting this PR open without activity for so long, let's get the ball rolling on this one and get this feature in!

I left a couple of comments on your code, I think the Trilean is not necessary in the current state as you inverted the condition, if it can safely default to false, we can keep it as a bool, which simplifies the interactions with it later on.

Also the code is out of sync since it was untouched for a while, so you will unfortunately need to rebase on top of the current main if we want to merge this later.

Please let me know if you're interested in continuing this work, and if you need help also feel free to reach out, I'll surely be able to help.

Thanks!

TemplateDescription string `mapstructure:"template_description"`
TemplateName string `mapstructure:"template_name"`
TemplateDescription string `mapstructure:"template_description"`
SkipConvertToTemplate config.Trilean `mapstructure:"skip_convert_to_template"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there a reason why this is a Trilean? If the intent is that this is false by default, bool would work this way, and this would simplify using the option

ui.Error(err.Error())
return multistep.ActionHalt
}
if !c.SkipConvertToTemplate.True() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be inverted here since this is the last step here

Suggested change
if !c.SkipConvertToTemplate.True() {
if c.SkipConvertToTemplate {
ui.Say("Skipping VM template conversion")
return multistep.ActionContinue
}

The rest of the code can be left unchanged if we do it this way

@@ -109,6 +110,9 @@ func TestBasicExampleFromDocsIsValid(t *testing.T) {
if b.config.CloudInit != false {
t.Errorf("Expected CloudInit to be false, got %t", b.config.CloudInit)
}
if b.config.SkipConvertToTemplate.False() {
t.Errorf("Expected ConvertToTemplate to be true, got %t", b.config.SkipConvertToTemplate.True())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be rephrased, also I suspect the error was introduced in the first draft, so the value does not match what the condition highlights.

}
"template_description": "Fedora 29-1.2, generated on {{ isotime \"2006-01-02T15:04:05Z\" }}",
"skip_convert_to_template": true
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The indentation is not consistent with the rest of the template here, the verbatim template being only indented with spaces.


var _ templateConverter = &proxmox.Client{}

func (s *stepStopVM) Run(ctx context.Context, state multistep.StateBag) multistep.StepAction {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why this becomes a step on its own here, it seems that the step_convert_to_template does this already, why not move the check after the VM is shutdown so we don't have to introduce another step?
For the record, I don't hate this change by itself, it's just that this brings more changes to this PR which makes the diff larger and harder to understand.

// the VM has been converted into a template, such as updating name and description, or
// unmounting the installation ISO.
type stepFinalizeTemplateConfig struct{}
type stepFinalizeVMConfig struct{}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we can either produce a template or a VM, might I suggest renaming this step as stepFinalize instead? Just to avoid confusion

@@ -11,7 +11,8 @@ import (

type Artifact struct {
builderID string
templateID int
vmID int
isTemplate bool
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I don't think there's other possible types than VM and template, I would maybe suggest changing this to a string, and have an enumeration to the side.

Something like

type ArtifactType string

const (
	TemplateArtifact ArtifactType = "Template"
	VMArtifact       ArtifactType = "VM"
)
[...]
type Artifact struct {
	builderID string
	artifactID int
	artifactType ArtifactType
[...]
}

Doing it this way also makes it possible to inject this in the String() and Destroy() methods without needing conditionals.

coreSteps = append(coreSteps, &stepConvertToTemplate{})

coreSteps = append(coreSteps, &stepFinalizeVMConfig{})
coreSteps = append(coreSteps, &stepSuccess{})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason for this change? This might be me only but I don't find this more readable than the original way of defining the steps, and it complexifies the diff so I would consider leaving this change out of the current patchset.

}

artifact := &Artifact{
builderID: b.id,
templateID: tplID,
vmID: vmRef.VmId(),
isTemplate: !b.config.SkipConvertToTemplate.True(),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we decide to keep it as a Trilean, this could be changed to

Suggested change
isTemplate: !b.config.SkipConvertToTemplate.True(),
isTemplate: b.config.SkipConvertToTemplate.False(),

// Verify that the template_id was set properly, otherwise we didn't progress through the last step
tplID, ok := state.Get("template_id").(int)
// Get vmRef for vmid in artifact storage
vmRef, ok := state.Get("vmRef").(*proxmox.VmRef)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be sure, if the artifact is a template, do we still get the appropriate ID from the vmRef in state?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: yes we do, the current way this is implemented is by writing vmRef.VmId() to the state as template_id, which is not necessary since the vmRef is already part of the state.

@lbajolet-hashicorp lbajolet-hashicorp removed the version/bump minor A PR that changes behavior or contains breaking changes template configuration options. label Oct 24, 2023
@lbajolet-hashicorp
Copy link
Contributor

Note: removed the bump minor label since in the current state, this does not change how the plugin works, so this can be a patch release.

@mfisher87
Copy link

The author of this PR hasn't had any GitHub activity in a year or two. Is there a path forward to merge this?

@AnthonyTippy
Copy link

checking in on this. Is it possible to merge in this feature? As I understand the current builder methods (ISO, and Clone) only allow you to create templates instead of going straight to a running VM?

Im looking to have packer build out a functional VM from ISO instead of a template. Is this possible in the proxmox environment? Currently we have a functional process using Vsphere but I am currently exploring proxmox as an alternative.

@tacoman
Copy link

tacoman commented Mar 27, 2024

Would love to see this merged in for our current workflow.

@lbajolet-hashicorp
Copy link
Contributor

Hi @AnthonyTippy @tacoman @mfisher87,

This looks pretty stale still, haven't heard of feedback from @LethalServant yet (to be fair to them, we waited a really long time for reviewing the code so there's definitely a lot of blame on us).

If someone wants to pickup that PR and add contributions on top to address the comments (that will likely need to be in a separate PR to supersede this one) I posted in my review, that would be very appreciated for sure, please let us know and we'll make sure to review the changes with minimal delay this time around.

@LethalServant
Copy link
Author

Hey @lbajolet-hashicorp

I started working on this feature back around v1.0.4 so I think the code base has changed a lot and it would take some effort to get this back in mergeable state. Not sure when I'll be able to get to this, if someone else is in a better position to add this feature either by picking this up or starting from scratch, go for it. Cheers!

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

Successfully merging this pull request may close these issues.

Add "convert_to_template" option to iso and clone builders