-
Notifications
You must be signed in to change notification settings - Fork 32
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
Remove build flag and re-introduce provision method attribute #122
Remove build flag and re-introduce provision method attribute #122
Conversation
The build flag was introduced as the replacement for the "method" attribute. Earlier, the method could be set to "build" or "image", which is then used by Foreman. The initial creation of a host also needed the build flag to be set in the API request to signal Foreman that it should create the machine. This lead to the problem that Terraform configs containing "build = true" would reset the build flag in Foreman even for existing, already built machines, resetting them at the next boot. This is dangerous and should be avoided. The commit removes the build flag completely from Terraform and uses the "provision_method" attribute from the Foreman API (again). We will have to find an additional attribute to support the use case of "enforced rebuild" that originally lead to the switch. The "managed" flag is not changed. Refs terraform-coop#40 Refs terraform-coop#68 Refs terraform-coop#106
…ning See examples/host/vmware_imagebased_host.tf for a VMware-backed image VM Refs terraform-coop#103 Refs terraform-coop#102 Refs terraform-coop#105
My tests with self-compiled binary were successful either with network-based or image-based provisioning method (running against foreman v3.6.1) My test code (image-based provisioning example with vSphere provider)
|
@@ -953,6 +946,10 @@ func setResourceDataFromForemanHost(d *schema.ResourceData, fh *api.ForemanHost) | |||
log.Printf("[WARN] error setting compute attributes: %s", err) | |||
} | |||
|
|||
// See issue #115 for "Build" attribute | |||
d.Set("managed", fh.Managed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This fixes #124
foreman/resource_foreman_host.go
Outdated
// log.Debugf("computeResource: [%+v]", computeResource) | ||
|
||
var diags diag.Diagnostics | ||
if h.ProvisionMethod == "image" { // && strings.ToLower(computeResource.Provider) == "vmware" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might differ in other providers, so a hard fail when image_id
is not given might introduce problems for other users. See #125 (reply in thread)
Removes an experimental check of the compute_attributes when using "image"-based host creation. The backend providers need different values. VMware for example needs the image_id as UUID, see the example file in examples/host/vmware_imagebased_host.tf Refs terraform-coop#125
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a quick test and seems ok
foreman/resource_foreman_host.go
Outdated
diags = append(diags, diag) | ||
return diags | ||
|
||
} else if _, ok := h.ComputeAttributes["image_id"]; !ok { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
image_id
might be required for vmware but I don't believe it is for other plugins. It can also be implicitly provided through a compute_profile. As in this example. Every virtualisation plugin is different, I think trying to validate the content of compute_attributes
is going to be impossible. Every PR risks breaking existing behaviour as no one can test all possible plugins.
PR terraform-coop#122 removed the "build" argument, removing the possibility to enforce setting the Foreman-internal build flag to "true". This commit re-introduces this ability, but with a more explicit argument name: "set_build_flag". And it defaults to "false", so that not specifying it does not toggle the flag to "true" on accident. Resolves terraform-coop#130 See terraform-coop#125
PR #122 removed the "build" argument, removing the possibility to enforce setting the Foreman-internal build flag to "true". This commit re-introduces this ability, but with a more explicit argument name: "set_build_flag". And it defaults to "false", so that not specifying it does not toggle the flag to "true" on accident. Resolves #130 See #125
The build flag was introduced as the replacement for the "method" attribute. Earlier, the method could be set to "build" or "image", which is then used by Foreman. The initial creation of a host also needed the build flag to be set in the API request to signal Foreman that it should create the machine.
This lead to the problem that Terraform configs containing "build = true" would reset the build flag in Foreman even for existing, already built machines, resetting them at the next boot. This is dangerous and should be avoided.
The commit removes the build flag completely from Terraform and uses the "provision_method" attribute from the Foreman API (again).
We will have to find an additional attribute to support the use case of "enforced rebuild" that originally lead to the switch.
The "managed" flag is not changed.
Refs #40
Refs #68
Refs #106