Bug #15548
closedCant resolve templates - Sorry but no templates were configured
Description
A fresh install with Foreman 12.1 + Discovery Plugin.
When trying to provision a discovered host, I get 'Sorry but no templates were configured' when clicking the resolve button for provisioning templates.
The production log shows the following:
2016-06-30 10:48:27 [app] [I] Started POST "/hosts/template_used?id=1&provisioning=build" for 10.30.0.1 at 2016-06-30 10:48:27 +0100
2016-06-30 10:48:27 [app] [I] Processing by HostsController#template_used as */*
2016-06-30 10:48:27 [app] [I] Parameters: {"utf8"=>"✓", "authenticity_token"=>"ADk2D+bNMA4UjYDKPvshtUTCrUsfnOxcBFoxB6w6qZrX0a57CUAWEh/fxoB5EbDtuZgWsC4mn9+63BOKKQXrdg==", "host"=>{"name"=>"mac080027139497", "hostgroup_id"=>"1", "environment_id"=>"1", "puppetclass_ids"=>[""], "managed"=>"true", "progress_report_id"=>"[FILTERED]", "type"=>"Host::Managed", "interfaces_attributes"=>{"0"=>{"_destroy"=>"0", "mac"=>"08:00:27:13:94:97", "identifier"=>"enp0s3", "name"=>"mac080027139497", "domain_id"=>"1", "subnet_id"=>"1", "ip"=>"10.30.0.102", "managed"=>"1", "primary"=>"1", "provision"=>"1", "tag"=>"", "attached_to"=>"", "id"=>"1"}, "1"=>{"_destroy"=>"0", "mac"=>"08:00:27:5d:9e:3c", "identifier"=>"enp0s8", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"0", "primary"=>"0", "provision"=>"0", "tag"=>"", "attached_to"=>"", "id"=>"2"}, "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"=>"1", "operatingsystem_id"=>"2", "build"=>"1", "medium_id"=>"9", "ptable_id"=>"69", "disk"=>"", "root_pass"=>"[FILTERED]", "is_owned_by"=>"3-Users", "enabled"=>"1", "model_id"=>"1", "comment"=>"", "overwrite"=>"false"}, "fakepassword"=>"[FILTERED]", "bare_metal_capabilities"=>"build", "id"=>"1", "provisioning"=>"build"}
2016-06-30 10:48:27 [app] [I] Rendered common/404.html.erb within layouts/application (4.0ms)
2016-06-30 10:48:27 [app] [I] Rendered layouts/_application_content.html.erb (0.2ms)
2016-06-30 10:48:27 [app] [I] Rendered layouts/base.html.erb (0.6ms)
2016-06-30 10:48:27 [app] [I] Completed 404 Not Found in 12ms (Views: 5.9ms | ActiveRecord: 0.7ms)
A installation media was created for RedHat 6.8
A OS was created for RedHat 6.8. The following associations were made:
Partition table: kickstart default
Installation Media: RedHat Mirror
Templates:
Provisioning Templates: Kickstart RHEL default
PXELinux Template: Kickstart default PXELinux
It looks related to http://projects.theforeman.org/issues/15223 for 1.11.3 which has been closed.
Updated by Dave Johnston over 8 years ago
- Related to Bug #15223: Resolving templates to provision a discovered host fails added
Updated by Dominic Cleal over 8 years ago
- Translation missing: en.field_release deleted (
161)
1) Does this work correctly for a regular host?
2) Is this on the the discovery plugin pages, or when editing the host after it has been converted?
3) Do templates show under the Templates tab of the host? (Not while editing.)
Updated by Lukas Zapletal about 8 years ago
- Project changed from Foreman to Discovery
- Category changed from Host creation to Discovery plugin
I can confirm the behavior, that's bug in Discovery.
Updated by Jeff Sparrow about 8 years ago
Adding to this, mostly to get updates sent back to me. Same issue on 1.11.4
2016-09-27 09:15:35 [app] [I] Started POST "/hosts/template_used?id=1980&provisioning=build" for 172.31.100.214 at 2016-09-27 09:15:35 -0500
2016-09-27 09:15:35 [app] [I] Processing by HostsController#template_used as */*
2016-09-27 09:15:35 [app] [I] Parameters: {"utf8"=>"✓", "authenticity_token"=>"UO7/lLpDXp0JpHkUrHvBUKi3hIrdWHufKluUGPSQ1/8=", "host"=>{"name"=>"currahee", "hostgroup_id"=>"16", "environment_id"=>"1", "puppet_ca_proxy_id"=>"1", "puppet_proxy_id"=>"1", "config_group_ids"=>[""], "puppetclass_ids"=>[""], "managed"=>"true", "progress_report_id"=>"[FILTERED]", "type"=>"Host::Managed", "interfaces_attributes"=>{"0"=>{"_destroy"=>"0", "mac"=>"b8:ca:3a:6e:8a:50", "identifier"=>"eno1", "name"=>"currahee", "domain_id"=>"22", "subnet_id"=>"4", "ip"=>"172.23.41.99", "managed"=>"1", "primary"=>"1", "provision"=>"1", "execution"=>"1", "tag"=>"", "attached_to"=>"", "id"=>"2376"}, "1"=>{"_destroy"=>"0", "mac"=>"b8:ca:3a:6e:8a:52", "identifier"=>"eno2", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"0", "primary"=>"0", "provision"=>"0", "execution"=>"0", "tag"=>"", "attached_to"=>"", "id"=>"2377"}, "2"=>{"_destroy"=>"0", "mac"=>"b8:ca:3a:6e:8a:54", "identifier"=>"eno3", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"0", "primary"=>"0", "provision"=>"0", "execution"=>"0", "tag"=>"", "attached_to"=>"", "id"=>"2378"}, "3"=>{"_destroy"=>"0", "mac"=>"b8:ca:3a:6e:8a:55", "identifier"=>"eno4", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"0", "primary"=>"0", "provision"=>"0", "execution"=>"0", "tag"=>"", "attached_to"=>"", "id"=>"2379"}, "4"=>{"_destroy"=>"0", "mac"=>"00:c0:dd:25:c0:48", "identifier"=>"enp5s1f0", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"0", "primary"=>"0", "provision"=>"0", "execution"=>"0", "tag"=>"", "attached_to"=>"", "id"=>"2380"}, "5"=>{"_destroy"=>"0", "mac"=>"00:c0:dd:25:c0:4a", "identifier"=>"enp5s1f2", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"0", "primary"=>"0", "provision"=>"0", "execution"=>"0", "tag"=>"", "attached_to"=>"", "id"=>"2381"}, "6"=>{"_destroy"=>"0", "mac"=>"f8:bc:12:36:98:b8", "identifier"=>"ipmi", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"172.23.41.100", "managed"=>"0", "primary"=>"0", "provision"=>"0", "execution"=>"0", "username"=>"root", "password"=>"[FILTERED]", "provider"=>"IPMI", "id"=>"2382"}, "new_interfaces"=>{"_destroy"=>"1", "type"=>"Nic::Managed", "mac"=>"", "identifier"=>"", "name"=>"", "domain_id"=>"", "subnet_id"=>"", "ip"=>"", "managed"=>"1", "primary"=>"0", "provision"=>"0", "execution"=>"0", "virtual"=>"0", "tag"=>"", "attached_to"=>""}}, "architecture_id"=>"1", "operatingsystem_id"=>"21", "build"=>"1", "medium_id"=>"10", "ptable_id"=>"179", "disk"=>"", "root_pass"=>"[FILTERED]", "is_owned_by"=>"50-Users", "enabled"=>"1", "model_id"=>"12", "comment"=>"", "overwrite"=>"false"}, "fakepassword"=>"[FILTERED]", "bare_metal_capabilities"=>"build", "id"=>"1980", "provisioning"=>"build"}
2016-09-27 09:15:35 [app] [D] Setting current user thread-local variable to jsparrow
2016-09-27 09:15:35 [app] [D] not found: Couldn't find Host::Managed with 'id'=1980 [WHERE `hosts`.`type` IN ('Host::Managed')]
2016-09-27 09:15:35 [app] [I] Rendered common/404.html.erb within layouts/application (1.2ms)
2016-09-27 09:15:35 [app] [I] Rendered layouts/_application_content.html.erb (0.3ms)
2016-09-27 09:15:35 [app] [I] Rendered layouts/base.html.erb (1.0ms)
2016-09-27 09:15:35 [app] [I] Completed 404 Not Found in 11ms (Views: 3.9ms | ActiveRecord: 0.6ms)
and verified id exists in the table:
select * from `hosts` where `id` like "%1980%" limit 0,25
1980 cmlb8ca3a6e8a50 2016-09-27 14:03:26 2016-09-27 14:03:26 2016-09-27 14:02:53
Updated by Jeff Sparrow about 8 years ago
Update. Looks like this issue is related to the table 'hosts'. Within that table the field of 'type' shows as Host::Discovered. But the templates are looking for Host::Managed. If I manually edit the 'type' field on the host with the same ID, then the resolve works and the host is able to find its templates.
Updated by Daniel Lobato Garcia about 8 years ago
I'm seeing this issue when selecting the architecture even, it's quite a blocker IMO as one cannot provision any discovered host unless a hostgroup with the OS and templates is chosen.
Updated by Jeff Sparrow about 8 years ago
update: I have confirmed the only issue is rendering templates. The hosts will still continue to provision. So no totally a blocker on my end.
Updated by The Foreman Bot about 8 years ago
- Status changed from New to Ready For Testing
- Assignee set to Daniel Lobato Garcia
- Pull request https://github.com/theforeman/foreman_discovery/pull/305 added
Updated by Daniel Lobato Garcia about 8 years ago
Actually #16750 was the problem I had in my last comment. This is fixed by https://github.com/theforeman/foreman_discovery/pull/305 and https://github.com/theforeman/foreman/pull/3905
Updated by Anonymous over 7 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset foreman_discovery|0e1bdd346054f4c096cdcdf9b4e760f7fb3df896.