| Summary: | [RFE] configd producing fully annotated inorder of application config files. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Timothy St. Clair <tstclair> |
| Component: | condor-wallaby-client | Assignee: | grid-maint-list <grid-maint-list> |
| Status: | CLOSED WONTFIX | QA Contact: | MRG Quality Engineering <mrgqe-bugs> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | Development | CC: | matt, tstclair, willb |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-06-10 16:49:54 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Timothy St. Clair
2011-06-09 21:20:50 UTC
I'm not sure I understand this request, but if I do, "wallaby explain" does what you're asking for. If not, let me know and reopen. Execute nodes will not have access to that tool. I also assert annotations are desired in the end user config files. e.g. ######################################## # Here is your layered cake config ordering # default # Group Bleh # .local ######################################## # Group Bleh # Feature X - Does such and Such XFEATURE_CONFIG=ABC RANDOM_BIT=123 ######################################## # Group Bleh # Feature Y - Does XyZ YFEATURE_CONFIG=DEF ######################################## # .local # Overrides RANDOM_BIT RANDOM_BIT=XYZ (In reply to comment #2) > Execute nodes will not have access to that tool. Not so and not important So Wallaby doesn't actually generate config files; it sends out maps corresponding to the final config. Since these are maps, they don't have values for parameters that are overridden in higher-priority features or groups; the information that comment #3 asks for never exists in current wallaby-configd interactions. Personally, I believe that the configuration file with multiply-defined values is *more* confusing than the one that just has the values that won out. But if something like comment #3 is what you want for every deployed configuration file, then this should really be a bug filed against the configd. This would either require that the configd become more complex (using the explain API method, which is a lot slower than getConfig, or replicating "wallaby explain" functionality, which is slower still) or that wallaby stored cached explanations. (From experience, I can say that the latter would be pretty inefficient in space and time.) If we're just talking about debugging in special cases, though, I think "wallaby explain" or a similar tool built on top of the API (if the "explain" output is somehow unsuitable) is more than adequate. Unless I'm missing something, I believe this bug, as reported, should be closed. I don't believe this is a special case scenario. There have been several instances of trying to debug configs and deciphering the file which has been dropped can be rather difficult. Much like your previous comment, I agree that it would be ideal if one could view only the config that won out. At present, in default config scenarios there are SEC configs which produce output like the FOLLOWING: condor_config_val -dump | grep SEC SEC_DEFAULT_AUTHENTICATION_METHODS = , FS, NTLM, CLAIMTOBE, CLAIMTOBE, FS, NTLM, CLAIMTOBE When traversing the file which is dropped, you will see it written multiple times w/o explanation of the logic as to why. Reassigning to configd for eval. |