Hide Forgot
Description: When debugging config issues it can sometimes take a fairly long time deciphering the wallaby_node.config file which was dropped. e.g. - Many times you will see a variable multiple times in the same file and it is can be difficult to debug when the file is long. Then the only source of logic becomes condor_config_val. + There are configs which don't really make a lot of sense when without some context. It would be highly beneficial if there annotations + a description of why it exists in the file at that location. e.g. - override b/c of .local group Version-Release number of selected component (if applicable): wallaby-0.10.5-5
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.