Plugins » Discovery

Hello,

can you verify those two fields are set in your hostgroup?

Yep, i have tried several combinations, both groups that are nested and groups that are not nested. I set the two fields in both of them.

I can confirm this issue exists in our setup:

"When I attempt to provision a "discovered" host using the discovery 3.0 plugin and the 2.1 discovery image, and I select the host group, the "Puppet CA" and "Puppet Master" fields do not auto-populate. the Environment field however does auto-populate, so I'm not convinced its a javascript or browser issue. I have double-checked my 'host groups' config and can confirm that these two fields are pre-filled."

from: https://groups.google.com/forum/?fromgroups#!topic/foreman-users/lBpqcdUnhqg

I do not yet have a non-production site setup and am unable to produce logs at this time

OK here's a sanitized portion of the production.log where I click on the desired hostgroup.

Started POST "/hosts/process_hostgroup" for 10.x.x.x at 2015-04-29 15:19:43 -0500
2015-04-29 15:19:43 [I] Processing by HostsController#process_hostgroup as */*
2015-04-29 15:19:43 [I]   Parameters: {"utf8"=>"✓", "authenticity_token"=>"u1MHGhz1oD433DP4vvVqj2htXdbYg8MMku8cuLVnmeE=", "host"=>{"name"=>"host005056ae4717", "hostgroup_id"=>"26", "environment_id"=>"", "puppet_ca_proxy_id"=>"", "puppet_proxy_id"=>"", "managed"=>"true", "progress_report_id"=>"[FILTERED]", "type"=>"Host::Managed", "interfaces_attributes"=>{"0"=>{"_destroy"=>"0", "mac"=>"00:50:56:ae:47:17", "name"=>"host005056ae4717", "domain_id"=>"", "subnet_id"=>"1", "ip"=>"10.x.x.x", "managed"=>"1", "primary"=>"1", "provision"=>"1", "tag"=>"", "attached_to"=>"", "id"=>"366"}, "1"=>{"_destroy"=>"0", "mac"=>"00:50:56:ae:7b:2f", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"0", "primary"=>"0", "provision"=>"0", "tag"=>"", "attached_to"=>"", "id"=>"367"}, "new_interfaces"=>{"_destroy"=>"1", "type"=>"Nic::Managed", "mac"=>"", "identifier"=>"", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"1", "primary"=>"0", "provision"=>"0", "virtual"=>"0", "tag"=>"", "attached_to"=>""}}, "architecture_id"=>"", "build"=>"1", "disk"=>"", "root_pass"=>"[FILTERED]", "is_owned_by"=>"3-Users", "enabled"=>"1", "model_id"=>"1", "comment"=>"", "overwrite"=>"false", "id"=>"117"}, "fakepassword"=>"[FILTERED]"}
2015-04-29 15:19:44 [I]   Rendered hosts/_progress.html.erb (0.3ms)
2015-04-29 15:19:44 [I]   Rendered puppetclasses/_selectedClasses.html.erb (0.0ms)
2015-04-29 15:19:44 [I]   Rendered puppetclasses/_classes_in_groups.html.erb (0.0ms)
2015-04-29 15:19:44 [I]   Rendered puppetclasses/_classes.html.erb (69.1ms)
2015-04-29 15:19:44 [I]   Rendered puppetclasses/_class_selection.html.erb (158.4ms)
2015-04-29 15:19:44 [I]   Rendered nic/_base_form.html.erb (220.8ms)
2015-04-29 15:19:44 [I]   Rendered nic/_virtual_form.html.erb (1.9ms)
2015-04-29 15:19:44 [I]   Rendered nic/_provider_specific_form.html.erb (0.2ms)
2015-04-29 15:19:44 [I]   Rendered nic/manageds/_managed.html.erb (226.4ms)
2015-04-29 15:19:44 [I]   Rendered nic/_base_form.html.erb (20.6ms)
2015-04-29 15:19:44 [I]   Rendered nic/_virtual_form.html.erb (1.9ms)
2015-04-29 15:19:44 [I]   Rendered nic/_provider_specific_form.html.erb (0.1ms)
2015-04-29 15:19:44 [I]   Rendered nic/manageds/_managed.html.erb (25.3ms)
2015-04-29 15:19:44 [I]   Rendered nic/_base_form.html.erb (18.6ms)
2015-04-29 15:19:44 [I]   Rendered nic/_virtual_form.html.erb (1.8ms)
2015-04-29 15:19:44 [I]   Rendered nic/_provider_specific_form.html.erb (0.1ms)
2015-04-29 15:19:44 [I]   Rendered nic/manageds/_managed.html.erb (23.2ms)
2015-04-29 15:19:44 [I]   Rendered hosts/_interfaces.html.erb (279.9ms)
2015-04-29 15:19:44 [I]   Rendered common/os_selection/_architecture.html.erb (6.4ms)
2015-04-29 15:19:44 [I]   Rendered common/os_selection/_operatingsystem.html.erb (14.2ms)
2015-04-29 15:19:44 [I]   Rendered hosts/_operating_system.html.erb (30.5ms)
2015-04-29 15:19:44 [I]   Rendered hosts/_unattended.html.erb (311.1ms)
2015-04-29 15:19:44 [I]   Rendered puppetclasses/_class_parameters.html.erb (40.4ms)
2015-04-29 15:19:44 [I]   Rendered puppetclasses/_classes_parameters.html.erb (54.3ms)
2015-04-29 15:19:44 [I]   Rendered common_parameters/_inherited_parameters.html.erb (7.0ms)
2015-04-29 15:19:44 [I]   Rendered common_parameters/_puppetclass_parameter.html.erb (5.0ms)
2015-04-29 15:19:44 [I]   Rendered common_parameters/_puppetclasses_parameters.html.erb (8.3ms)
2015-04-29 15:19:44 [I]   Rendered common_parameters/_parameter.html.erb (2.8ms)
2015-04-29 15:19:44 [I]   Rendered common_parameters/_parameters.html.erb (5.8ms)
2015-04-29 15:19:44 [I]   Rendered hosts/_form.html.erb (617.2ms)
2015-04-29 15:19:44 [I] Completed 200 OK in 694ms (Views: 587.7ms | ActiveRecord: 43.1ms)

I can confirm this bug. My base hostgroup has a default setting of Puppet CA and Puppet Master, but these settings do not get transferred to a new autoprovisioned host.

I don't mean to be pushy, but if anyone knows a temporary workaround for this problem, it would be greatly appreciated. I just noticed that the lack of a Puppet CA being set is preventing the foreman-proxy autosign feature. This is preventing puppet to run at the end of provisioning. I need to roll out 500 new physical machines soon, unknown to foreman and I would prefer not to have to add them all manually just to set the puppetmaster and puppetca variables.

Another option would be to enable naive autosigning on the puppetmaster, but of course, this is not really top-notch security.

Thanks for any input.

Reproduced, will make my best to push this into 3.0.1.

Ok it was caused by this patch #6369

Ok it looks like this patch should fix it, I need to test it once rebased: https://github.com/theforeman/foreman/pull/2230

Due to bigger impact we will unlikely fix this for 1.8/1.9, workaround is to revert #6369

Lukas Zapletal wrote:

Ok it looks like this patch should fix it, I need to test it once rebased: https://github.com/theforeman/foreman/pull/2230

It will help, and Discovery will need to make a code update to call the new helper for 1.10.

Due to bigger impact we will unlikely fix this for 1.8/1.9, workaround is to revert #6339

That's overkill, it could be fixed by checking new_record? || type_changed? to catch the transition between STI types for Discovery.

Confirmed on Foreman 1.9.1 with the latest discovery plugin and image (automatically added by foreman-installer)

I have a fully configured hostgroup. When I:
- manually create a new host, the puppetca/master fields get populated as soon as I select the hostgroup.
- manually provision a discovered host, the puppetca/hosts fields remain empty.
- let Foreman autoprovision discovered hosts, the puppetca/hosts fields remain empty.

Please note that with provisioning all other fields are inherited from the hostgroup correctly except for the puppetca/hosts fields. Given that the issue manifests both with manual and auto provisioning I do not believe this is a browser/javascript related bug.

Please fix because this renders discovery autoprovisioning broken on all new Foreman deployments!

Hmm develop still does not work, in the meantime revert this patch to workaround the issue: https://github.com/theforeman/foreman/pull/2068/files

Confirmed on Foreman 1.10.0 RC2 with the latest discovery plugin (4.1) and image (3.0.2), both automatically added by foreman-installer.

In this version not only does it not set the puppetca and puppetmaster fields, it also doesn't set the environment field!

Tom Verdaat wrote:

Confirmed on Foreman 1.9.1 with the latest discovery plugin and image (automatically added by foreman-installer)

I have a fully configured hostgroup. When I:
- manually create a new host, the puppetca/master fields get populated as soon as I select the hostgroup.
- manually provision a discovered host, the puppetca/hosts fields remain empty.
- let Foreman autoprovision discovered hosts, the puppetca/hosts fields remain empty.

Please note that with provisioning all other fields are inherited from the hostgroup correctly except for the puppetca/hosts fields. Given that the issue manifests both with manual and auto provisioning I do not believe this is a browser/javascript related bug.

I can confirm same behavior on foreman 1.9.3 with plugin 4.0.0

Please fix because this renders discovery autoprovisioning broken on all new Foreman deployments!

Tom Verdaat wrote:

Confirmed on Foreman 1.10.0 RC2 with the latest discovery plugin (4.1) and image (3.0.2), both automatically added by foreman-installer.

In this version not only does it not set the puppetca and puppetmaster fields, it also doesn't set the environment field!

I can confirm this worsened behaviour. Environment is not being set.

For the record, the associated patch is:

https://github.com/theforeman/foreman_discovery/pull/273/files

For the record, if you have Katello plugin installed, this patch is not enough and there must be one another applied: #16063

Thanks very much for having fixed this in Discovery 6.0, it saves us a lot of time having autoprovisioning up and running!

I've installed the updated version from the repo for RHEL7 (tfm-rubygem-foreman_discovery.noarch v6.0.0-1.fm1_12.el7) but I'm still having an issue.
I click Provision, get the "Select initial host properties" box and select my host group, then click "Create Host" and get forwarded to the Edit page. The Environment, Puppet CA, Puppet Master, and Realm fields are all filled in correctly based on the Host Group selection. However when I click Submit to build the new host that information doesn't get transferred to the new host.
If I edit the host after clicking the Submit button Those same 4 boxes are empty. I've tried clicking the "Inherit" button on each one to unlock the selections but still make sure they are correct, but this leads to the same behavior. Let me know what information I can provide to help track down this issue.

Thanks!

Adam Lewis wrote:

I click Provision, get the "Select initial host properties" box and select my host group, then click "Create Host" and get forwarded to the Edit page. The Environment, Puppet CA, Puppet Master, and Realm fields are all filled in correctly based on the Host Group selection. However when I click Submit to build the new host that information doesn't get transferred to the new host.

Adam, this ticket tracks auto-provisioning similar bug, your case is different. Unfortunately, this is not yet fixed for the Edit Host form, we are tracking this as a design issue #14035. In the meantime, you can use the new Quick form that let's you select org/loc and hostgroup (implemented as part of #4426).