Proposal to add build flexibility on resource node build #281
robbellphd
started this conversation in
Show and tell
Replies: 2 comments
-
Rob added this support in PR #282 and it's awesome. Thanks, Rob! |
Beta Was this translation helpful? Give feedback.
0 replies
-
Thanks, Knute! Enjoyed it immensely! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I am starting this discussion to be get input on the style of tree build that I am used to working with, and to get any comments on a proposed extension to the current ResourceTreeNode to accommodate it.
The Sparta tree build and configure process looks like this:
Typically you would instantiate your root node factory with whatever topology you define, then in build tree, the first ResourceTreeNode() instance is constructed on the tree root, and the calling structure unrolls from there:
There don’t appear to be hooks in the ResourceTreeNode() hierarchy above to reconfigure the node prior to yaml parameter application. You can reconfigure of course in the createSubtree() method, but, looking at the flow above, it occurs after the node’s yaml parameters have already been applied in addChild(). Reconfiguring then implies identifying what, if anything, was done to the tree in prior addChild() parameter application, and either accept what was done or modify/overwrite it.
The proposal is that a hook, referred to here as an “onBuilding()” call in initConfigurables_() before addChild(), would allow early parameter application, such as parameter overrides from topology walking, prior to application of the yaml parameters. This would be more natural for some building styles, if you want command line or file based yaml parameters to override any coded topology parameter values. With that capability, this style of building would then flow like this:
Notice configureTree() is now isolated from the initial build, although further modification in configureTree() is possible. Note that for this to work, we also need to convert the static createSubtree() call in onConfiguring to a virtual onConfiguring() function, and call createSubtree() from onBuilding() instead of onConfiguring() in the resource factories as needed.
In summary, we could enable this style of build by adding the onBuilding() and onConfiguring() virtual function hooks in the ResourceTreeNode definition, retaining the flexibility for either style of tree build.
Thanks in advance for any insight or comments!
Rob
Beta Was this translation helpful? Give feedback.
All reactions