Bug #23863
closed
Provisioning starts even with errors in provisioning templates
Description
As reported here: https://community.theforeman.org/t/discovery-provisioning-starts-even-with-errors-in-provisioning-templates/8961
I’m running into in issue with foreman discovery and the first time provisioning of a discovered host, in case there is a problem with the provisioning templates.
Normally when an already known host is (re)build (using the “Build” button in the foreman webinterface) and there is an error while generating the provisioning templates, foreman prevents that provisioning starts and shows the nature of the error to the user. (in my case an exception was raised from the ruby code)
However, when starting with a freshly discovered host and triggering “Provision” for the first time, provisioning starts anyway, even though the generation of the provisioning templates is failing. This result in a host that is unable to be provisioned properly. You only notice that something is wrong when the node stays unreachable after a certain period of time and you to physically look at the console to see that it didn’t even start to provision.
I would expect that the same error would be shown in both cases.
Is that known or expected behavior? Or is that a bug?
Is there a work around to have a quicker reply or indication that there is something wrong with the provisioning templates?
Version:
foreman: 1.14.3
discovery: 8.0.1
Also tested with:
foreman: 1.16.0
discovery: 10.0.0
I'm willing to help and look into it, but do need some pointers what to look for.
Updated by Lukas Zapletal over 6 years ago
Hello Danny, this is a bug, yes.
Are you using quick provision, custom provision (Edit Host form) or auto-provisioning workflow? Every one of the three uses slightly different codepath. The check implemented in Foreman Core is probably hooked into New Host - Submit path while discovery uses slightly modified Edit Host form (or no form at all for the other two).
I suggest you to start with editing an existing host in Core - does not show any error? If not, that's a missing feature in Core and we need this to be implemented. If it does work correctly, then make sure that discovery triggers the check. I roughly looked in the codebase but could not find it where do we check the templates.
Updated by Danny S over 6 years ago
Hi Lukas, thanks for your reply.
I first noticed the issue with the 'custom provisioning' scenario, which uses the edit host form. I can't test auto-provision that easily at this point, but it seems that quick-provision has the same issue.
Some other findings that may be interesting:- I can edit an existing host and submit: it does not report the error in the provisioning templates.
- I can edit an existing host, press the "Resolve" provisioning templates button: it also does not report the error.
- I can preview the provisioning template using the edit template form: it does report the error in the template.
- I can press the "Build" button for an existing host: it does report the error in the template.
I'm not sure if it is to be expected that the scenarios of bullet 1 and 2 are not showing the error. I can imagine that it is less relevant in those cases.
Without knowing the details, it seems to me that provisioning a discovered host exists of two steps (when comparing to the Foreman Core):- First edit the host (if applicable)
- Immediately/automatically followed by the "Build" path of the host
Please correct me if I'm wrong, but this leads me to believe that the checks to triggers are probably part of the "Build" path instead of "Edit host" path in Foreman Core.
Does that make sense?
Updated by Lukas Zapletal over 6 years ago
- Status changed from New to Closed
Absolutely, good analysis. We only appear to added rendering check when user clicks Build button. Not a good user experience.
There is one technical limitation tho, when creating new host, the database records does not yet exist, therefore templates cannot be rendered (thus verified for errors). So scratch new host form, that wont work.
However, on Edit Host form the Resolve button currently only creates links to previews. It could actually perform renderer test and show the same dialog or perhaps report errors somewhere else. This would be super useful.
Provisioning of discovered hosts uses Edit Host form as well, so the Resolve button could be used the same way.
If this is not enough for you, another way of implementing this is possible - extracting the renderer preview code into reusable code and creating an orchestration step that triggers after host is saved in the database. Of orchestration step fails, this can be logged and host creation/edit can be rolled back with some message. This is more challenging path.
Ideally we should implement both. None of these belong into discovery project tho, this is core. I am going to close this ticket here, feel free to reopen Feature issues in core for that. If you want to give this a try, I will happily review your patch and help to push this forward.
Updated by Danny S over 6 years ago
Thanks for your reply.
I noticed that the "Build" button for an existing host triggers a call to the URL path: "/hosts/<name>/review_before_build", which seems to be checking if the provisioning templates can be rendered (and probably triggers other checks as well). Shouldn't discovery also trigger the same check? As there could be more verification steps that are now skipped by discovery.
Again, feel free to correct me if I'm wrong, but this makes me believe that the 'reusable code' needed for this already exists in core. Wouldn't it be possible to include that check in discovery as well?
Because of this, I'm not really sure if it will be that useful to write an issue in core at this point.
Updated by Lukas Zapletal over 6 years ago
Yes, discovery should reuse this for auto and quick provisioning.
For "Customize host" option Discovery actually renders Edit Host form from core. I know this is confusing.
Depending on which workflow you want the check to be present, that should go there. We can rule out auto provisioning because that's non interactive. So quick provision ("Provision" button) or "Customize host" button.