Bug #9784

Autoprovisioning via hostgroup does not populate all parameters via WebUI or API

Added by Mattias Giese over 2 years ago. Updated 11 months ago.

Status:Closed
Priority:Urgent
Assigned To:Lukas Zapletal
Category:Discovery plugin
Target version:Plugin 6.0
Difficulty: Pull request:https://github.com/theforeman/foreman_discovery/pull/277
Bugzilla link:1319283
Story points-
Velocity based estimate-

Description

Happening on Foreman 1.8-RC1 and Discovery plugin 3.0.0

How to reproduce:

1) Select a discovered host for Provisioning
2) In the Provisioning UI, select a host group
3) parameters like Puppet CA/Puppetmaster are not populated


Related issues

Related to Foreman - Bug #9591: Override puppet configuration on host level does not work... Closed 03/01/2015
Related to Foreman - Bug #6369: Unable to create host without Puppet master when specifie... Closed 06/25/2014
Related to Katello - Bug #16063: Autoprovisioning fails with Katello plugin installed Closed 08/11/2016
Duplicated by Discovery - Bug #14187: Host Group parameters are not being inherited by newly ad... Duplicate 03/14/2016
Duplicated by Discovery - Bug #14733: Puppet master and Puppet CA info in not added after host ... Duplicate 04/20/2016

Associated revisions

Revision 8e3bc400
Added by Lukas Zapletal over 1 year ago

Fixes #9784 - autoprovisioning populates from hostgroup

History

#1 Updated by Lukas Zapletal over 2 years ago

Hello,

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

#2 Updated by Lukas Zapletal over 2 years ago

  • Target version set to Plugin 3.0.0

#3 Updated by Lukas Zapletal over 2 years ago

  • Status changed from New to Need more information
  • Target version deleted (Plugin 3.0.0)

#4 Updated by Mattias Giese over 2 years ago

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.

#5 Updated by Dominic Cleal over 2 years ago

  • Status changed from Need more information to New

#6 Updated by larry campbell over 2 years ago

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

#7 Updated by larry campbell over 2 years ago

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)

#8 Updated by Simon Wydooghe over 2 years ago

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.

#9 Updated by Simon Wydooghe over 2 years ago

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.

#10 Updated by Ohad Levy over 2 years ago

  • Assigned To set to Alon Goldboim

#11 Updated by Lukas Zapletal over 2 years ago

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

#12 Updated by Lukas Zapletal over 2 years ago

Ok it was caused by this patch #6369

#13 Updated by Lukas Zapletal over 2 years ago

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

#14 Updated by Lukas Zapletal over 2 years ago

  • Related to Bug #9591: Override puppet configuration on host level does not work if specified on host group added

#15 Updated by Lukas Zapletal over 2 years ago

  • Related to Bug #6369: Unable to create host without Puppet master when specified on host group added

#16 Updated by Lukas Zapletal over 2 years ago

  • Status changed from New to Assigned
  • Assigned To changed from Alon Goldboim to Lukas Zapletal
  • Priority changed from High to Normal

#17 Updated by Dominic Cleal about 2 years ago

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.

#18 Updated by Tom Verdaat about 2 years ago

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!

#19 Updated by Lukas Zapletal about 2 years ago

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

#20 Updated by Tom Verdaat almost 2 years ago

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!

#21 Updated by Mike Fröhner almost 2 years ago

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!

#22 Updated by Simon Wydooghe over 1 year ago

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.

#23 Updated by Lukas Zapletal over 1 year ago

  • Priority changed from Normal to Urgent
  • Target version set to Plugin 6.0

Ok raising priority.

#24 Updated by Dominic Cleal over 1 year ago

  • Duplicated by Bug #14187: Host Group parameters are not being inherited by newly added hosts added

#25 Updated by Lukas Zapletal over 1 year ago

  • Bugzilla link set to 1319283

Affected is BOTH provisioning and auto-provisioning.

#26 Updated by The Foreman Bot over 1 year ago

  • Status changed from Assigned to Ready For Testing
  • Pull request https://github.com/theforeman/foreman_discovery/pull/262 added

#27 Updated by The Foreman Bot over 1 year ago

  • Pull request https://github.com/theforeman/foreman/pull/3354 added

#28 Updated by Dominic Cleal over 1 year ago

  • Duplicated by Bug #14733: Puppet master and Puppet CA info in not added after host was discovered via PXE added

#29 Updated by Lukas Zapletal over 1 year ago

  • Status changed from Ready For Testing to Closed
  • Pull request deleted (https://github.com/theforeman/foreman/pull/3354, https://github.com/theforeman/foreman_discovery/pull/262)

Issue #4426 fixed this properly.

#30 Updated by Lukas Zapletal over 1 year ago

#31 Updated by Lukas Zapletal over 1 year ago

  • Subject changed from Selecting a hostgroup does not populate all parameters to Autoprovisioning via hostgroup does not populate all parameters
  • Status changed from Closed to New

So the patch #4426 fixed only UI provisioning, not auto-provisioning. Keeping this ticket opened, will create new patch that handles this correctly.

#32 Updated by The Foreman Bot over 1 year ago

  • Status changed from New to Ready For Testing
  • Pull request https://github.com/theforeman/foreman_discovery/pull/277 added

#33 Updated by Anonymous over 1 year ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100

#34 Updated by Lukas Zapletal about 1 year ago

  • Related to Bug #16063: Autoprovisioning fails with Katello plugin installed added

#35 Updated by Lukas Zapletal about 1 year ago

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

#36 Updated by Simon Wydooghe about 1 year ago

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

#37 Updated by Adam Lewis about 1 year ago

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!

#38 Updated by Lukas Zapletal about 1 year ago

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).

#39 Updated by Lukas Zapletal 11 months ago

  • Subject changed from Autoprovisioning via hostgroup does not populate all parameters to Autoprovisioning via hostgroup does not populate all parameters via WebUI or API

Just for the record, this also does not work via API as was reported today on the list.

Also available in: Atom PDF