Forum: CFEngine Help Subject: Re: 3.1.4 => 3.3.4: has something changed regarding classes in bundles? Author: davidlee Link to topic: https://cfengine.com/forum/read.php?3,26274,26292#msg-26292
Thanks, Diego. It's re-assuring to know that my analysis seems correct. Having said that, while my suggestion is an improvement, it is still not an ideal bugfix. There is a fundamental design weakness right at the heart of this, which my fix helps but does not fully cure. We're merely adding a bandage; we're not curing the underlying ailment. Internally, "set_variable_values", as it currently exists, needs a control mechanism within any given invocation to decide whether to insert a line or to "field_edit" an existing line. This mechanism needs to be local, not global, in scope, so as to be re-useable. It needs to be guaranteed unique per call. But the existing chosen mechanism uses something which is global, not local, in scope. It lurks from call to call, potentially failing subsequent calls, unless that thing of global scope can be guaranteed unique per call. If a globally scoped implementation is chosen, then his uniqueness requirement must never be violated throughout global scope. As it was, the "$(key)_in_file" was OK for a single call, but could fail when called on different files with the same key. The revised version "$(key)_in_$(file)" allows multiple calls for the same key on different files; it adds file-based uniqueness. But this weakness still lurks. Now imagine a single "INI" file containing multiple sections, with each section containing similar keys to other sections. The first call will be OK. But subsequent calls to the same file for a different section but with the same key will still be prone to error, because both $(key) and $(file) are now the same; that is, the uniqueness requirement is again violated, this time across sections. So we would need something like "($key)_at_$(location)_in_$(file)". I think you'll agree that this attempt at fudging global uniqueness is getting messy, and may still be prone to yet other non-uniqueness circumstances. The only clean solution is to use something of truly local, not global, scope. But is there such a thing available to us? At bug 679 we've been discussing an alternative for "set_variable_values". A library component needs both robustness and good generality. This alternative, by using "replace_patterns" rather than "field_edits", seems (I believe) to use a mechanism of the required truly local scope. It also has better generalisation, including letting the separator be an argument, and letting the "value" (of the key/value data) itself contain the separator. You might want to take a look. Thanks again, Diego, for following this issue. _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
