Bug #4227
closed
Override Parameter not saved in Host
Description
When you have a host and want to override a Class Parameter and submit it it's not saved.
If you edit this parameter, Submit it and go back to edit, the set parameter is gone and set back to the list of possible overrides.
Files
Updated by Dominic Cleal about 10 years ago
- translation missing: en.field_release deleted (
2) - Difficulty deleted (
easy)
Updated by Greg Sutcliffe about 10 years ago
- Status changed from New to Need more information
I can't replicate this - I can override default class parameters at the host level with no issues. Can you provide more information please? Are you using validators on the class parameter? Do you have any logs showing errors on save?
Updated by Yama Kasi about 10 years ago
I don't see errors on saving, a 302, but this should be OK.
My validators are emtpy and I have seen this same issue on 1.3.2 on the puppetclasses itself, this is fixed in 1.4. On 1.3.2 host overrides were working, but not anymore on 1.4.
So it seems that the issue has moved.
Updated by Yama Kasi about 10 years ago
I have found out that Global Paramaters (manually) created for a group are saved.
Updated by Yama Kasi about 10 years ago
I have checked the following:
It seems that override paramaters (from a group or not) are not inserted into the database following the PgSQL logs.
A global parameter is inserted or updated following the pgSQL logs.
Updated by Dominic Cleal about 10 years ago
Please provide debug logs when updating the host: http://projects.theforeman.org/projects/foreman/wiki/Troubleshooting#How-do-I-enable-debugging
Not setting the release - that's indicative of the version it's been fixed in.
Updated by Yama Kasi about 10 years ago
I have added a log when I submit a override, I know how to enable debugging ;)
Updated by Yama Kasi about 10 years ago
OK, I have checked everything double and am not able to see where this goes wrong.
It's a bug fore sure, we just need to debug out where and why it exists.
Updated by Yama Kasi about 10 years ago
- File Production_2.txt Production_2.txt added
Hereby a new log with full logging after my reinstall of the foreman package.
This log only contains a submit of override paramater that was already filled in on a host but not saved/set yet.
Updated by Yama Kasi about 10 years ago
Is here still more information needed ?
FM is useless here at the moment.
Updated by Dominic Cleal about 10 years ago
- Related to Bug #4234: Cannot edit host's puppet parameters added
Updated by Dominic Cleal about 10 years ago
- Status changed from Need more information to New
I suspect this might be #4234, since I see in the debug log:
\f1\b \cf3 LookupValue Exists (1.0ms)
\f0\b0 \cf0 SELECT 1 AS one FROM "lookup_values" WHERE ("lookup_values"."match" = 'fqdn=mysql-01' AND "lookup_values"."lookup_key_id" = 742) LIMIT 1\
\f1\b \cf3 LookupValue Load (0.8ms)
\f0\b0 \cf0 SELECT "lookup_values".* FROM "lookup_values" WHERE "lookup_values"."match" = 'fqdn=mysql-01.domain.local'\The lookup should always be for the FQDN, not the shortname.
It would only affect fully-managed hosts, due to a separate domain being set.
Updated by Yama Kasi about 10 years ago
That is very right Dominic, I have seen the same that fqdn's were not saved well and I wondered why.
When you clone a host now the fqdn is not taken over as before and the name of the host is empty. It might be a good idea to have this autofilled again.
I have just tested this with full fqdn and it's fixed.
Thanks a lot!!
Updated by Yama Kasi about 10 years ago
Some additional information:
When you set the fqdn on a host, that didn't save the puppet parameters, the paramater is saved but still available for override.
In this situation the fqdn in the "name field" is set back to the hostname only.
When you want to override an extra (add one) paramater and don't set the full fqdn in the name of the host again, the override parameter that already existed is "copied" with an empty scope and name an value of the existed one.
When you add an extra override paramater and also set the fdqn in the name, everything is saved fine.
Updated by Dominic Cleal about 10 years ago
- Status changed from New to Duplicate
Yama Kasi wrote:
That is very right Dominic, I have seen the same that fqdn's were not saved well and I wondered why.
When you clone a host now the fqdn is not taken over as before and the name of the host is empty. It might be a good idea to have this autofilled again.
That was a deliberate change in #3136 - the old hostname is shown in the title if you need it.
I have just tested this with full fqdn and it's fixed.
Okay, thanks. I'll mark this as a duplicate so we have just one ticket, and we'll continue fixing this in #4234.