Project

General

Profile

Actions

Support #18047

open

Wrong template type resolved on first host creation

Added by Damien Churchill almost 8 years ago. Updated over 6 years ago.

Status:
New
Priority:
Normal
Assignee:
Category:
Web Interface
Target version:
-
Triaged:
Fixed in Releases:
Found in Releases:

Description

I've been experiencing this issue for some releases now, regretfully I don't recall exactly which release it first started occurring in, and I'm unsure whether it is misconfiguration on my behalf or a bug.

When I'm creating a new host using the OpenStack provider, with everything correctly configured on each tab. If I hit the resolve button on the operating system page, I receive the message:

Sorry but no templates were configured.

Then, on the first submit to create the host will fail with:

Unable to save
No finish templates were found for this host, make sure you define at least one in your FreeBSD-11.0 11.0 settings

On the Operating System tab once the page is loaded, I can now click the "Resolve" button next to Provisioning templates and it will correctly detect the user_data template I have configured for FreeBSD.

I may be way off with this assumption, but it seems like on the initial create, it looks for the wrong type of template (finish), but something gets updated against the hosts configuration which ensures on the next create it will look for the correct type of template (user_data). Another point of note is that if I clone an existing host, this will succeed first time and be able to resolve the user_data template.

I have 2 OpenStack compute resources, and this occurs for both of them. It happens on all the operating systems I use, which all use user_data templates for provisioning.


Files

Screenshot from 2018-06-06 13-47-34.png View Screenshot from 2018-06-06 13-47-34.png 166 KB HTML, disabled attribute present Damien Churchill, 06/06/2018 12:50 PM
Screenshot from 2018-06-06 13-48-00.png View Screenshot from 2018-06-06 13-48-00.png 80.3 KB Clicking resolve template, finish template selected, POST won't have included image id Damien Churchill, 06/06/2018 12:50 PM
Screenshot from 2018-06-06 13-48-22.png View Screenshot from 2018-06-06 13-48-22.png 134 KB HTML, disabled attribute removed Damien Churchill, 06/06/2018 12:50 PM
Screenshot from 2018-06-06 13-51-31.png View Screenshot from 2018-06-06 13-51-31.png 319 KB Form-data sent to the server, missing host[compute_attributes][image_ref] Damien Churchill, 06/06/2018 12:57 PM
Screenshot from 2018-06-06 13-51-49.png View Screenshot from 2018-06-06 13-51-49.png 329 KB Form-data sent to the server, contains host[compute_attributes][image_ref] Damien Churchill, 06/06/2018 12:57 PM
Screenshot from 2018-06-06 13-48-38.png View Screenshot from 2018-06-06 13-48-38.png 86.3 KB Clicking resolve template, user-data template selected, POST included image id Damien Churchill, 06/06/2018 12:59 PM
foreman-logs.txt.gz foreman-logs.txt.gz 7.94 KB Damien Churchill, 06/14/2018 11:26 AM
Actions #1

Updated by Damien Churchill over 6 years ago

  • Category changed from Templates to Web Interface

After spending a bit of time digging into this further I think I've pinned this to a UI bug. When going through VM creation and selecting the operating system, the image select field gets populated with the correct value, however both the <input> and <select> end up having the disabled attribute added so the value is never sent by the browser.

Opening the browser development tools and removing the disabled attribute from both of these gives the expected behaviour, the image is found upon first submit.

Actions #2

Updated by Lukas Zapletal over 6 years ago

Hello, your VM "Image" in Foreman inventory specifies flag called "user-data". If it's checked, user-data template is used. If it's unchecked, finish template is used. Can you check if this is the behavior? That's by design. It is indeed confusing, we might put some explanation somewhere.

Updated by Damien Churchill over 6 years ago

They all have user-data enabled, that's certainly not (at least directly) the problem.

As I'm going through creating a virtual machine now I've created some screenshots to hopefully clarify what I mean. I changed nothing other than removing the disabled attribute from the <select> in between.

Hope this helps.

Actions #4

Updated by Damien Churchill over 6 years ago

  • File deleted (Screenshot from 2018-06-06 13-51-31.png)
Actions #6

Updated by boaz shust over 6 years ago

  • Assignee set to b sh
Actions #7

Updated by boaz shust over 6 years ago

Damien Churchill can you also add Rails logs during the time of that problem.
This information can help me a lot to reproduce the problem (as I don't have OpenStack available at the momemnt).

Thanks.

Actions #8

Updated by Damien Churchill over 6 years ago

Just created a new VM, and attached the logs for each request mentioning the new VMs name. Let me know if you need more logs.

Actions

Also available in: Atom PDF