Architecture #9861
closed
Improve rudder→cfengine compliance by means of ordering for directive execution.
Description
This leads to unpredictable execution order of promises generated for each distinct technique. * And awful racing between range of hooks inside all directives that are based on the same technique.
- Just now I use dirty hack to implement order: clone "RudderTechnique"→"RudderTechnique_1", then sort directives content between regular technique and it's clone. Now the 2 directives can be linked into 2 alphabetically sorted rules.
- Why it's important? For example, first package installs the new repository, then the next 99 packages come from new repo. With no order, about all are erred at first pass.
- Another example is to change config-set for some service. Need restart on any change. But concurrent "restart" from relative hooks may lead to deadlock and zombies bearing!
What I propose? The cheap way is to introduce bundle tagging. E.g check_apt_package_installation divides in "check_apt_package_installation_tag1" "check_apt_package_installation_tag2" and so on.
This way needs minor changes: there can be used directive "Name" field in alpha-order for tagging, or reimplemented "Priority", or new field. Then rewrite .cf generator to loop through sorted tags, thus bundle for directive forks into N bundles ordered by tag. Profit.
Updated by Vincent MEMBRÉ almost 8 years ago
- Assignee set to Benoît PECCATTE
The problem is that we generate one file per directive/bundle.
We have an idea to fix this issue, instead of generating one file with all parameters per directive/bundle
usebundle => packageManagement # install package1, package2, package3 from three directives
, we will call call three bundles with parameters
usebundle => packageManagement('install', 'package1')
usebundle => packageManagement('install', 'package2')
usebundle => packageManagement('install', 'package3')
with ordering based on the names of the Rule/Directives
Would this fix you use case ?
(ps: good job on the workaround, that looks clever, sorry to be that complicated !!)
Updated by Dmitry Svyatogorov almost 8 years ago
Yes, it can help. But m.b. it will be better to implement ordering rule. E.g.:usebundle => packageManagement('install', 'package1')
usebundle => packageManagement('install', 'package2')
usebundle => packageManagement('install', 'package3')
- One directive → one bundle (group all inside directive together with the goal of enhance performance)
- Each directive produces it's own bundle in alpha-order, so the management trough web-ui becames plain enough!
Slightly more complex, but will lead to very useful improvement.
Updated by François ARMAND almost 8 years ago
The possibility to not merge directive together in our mid-term plans. It is much more complicated than it should be, especially because, as you saw, you need to be careful with global variables (classes, bundle names, etc) in technique. In all case, be assured that it is something important for us.
Updated by
Updated by Alexis Mousset 7 months ago
- Status changed from New to Rejected
- Regression set to No
Built-in techniques are more or less deprecated and the problem does not exist with new techniques, closing.