ncm-metaconfig: cleanup component templates #621
Conversation
| prefix '/software/components/${project.artifactId}'; | ||
|
|
||
| #'version' = '${project.version}'; | ||
| #'package' = 'NCM::Component'; |
There was a problem hiding this comment.
I was going to comment that the version attribute had been dropped which might prevent the component being run after a new version was installed. However now I remember that following a schema change to /software/packages, all components were dispatched, so does ncm-ncd already include functionality to register the /software/packages/ncm-$component/ subtree for changes? In which case the version attribute should be deprecated and removed from other PRs such as #601 ?
There was a problem hiding this comment.
i would like to start using the version again for quattor/ncm-ncd#41, but this PR just cleans up teh config-*.pan.
i'm no sure i understand what you mean with functionality to register the /software/packages/ncm-$component/ subtree. i thought that was the default for each component? but i could be wrong....
There was a problem hiding this comment.
Just trying to understand if we should be putting this field in during clean up or taking it out. :-) Can we have a definitive statement please?
Sorry for the confusing statement: it must be ncm-cdispd which triggers a dispatch of a component if /software/packages/ncm-$component/ changes.
There was a problem hiding this comment.
cleanup should not change current behaviour imho. i removed it here because it was commented out.
at some point i would like it as part of quattor/ncm-ncd#41, but now i wouldn't know which "version" to use (project.version, no-snapshot-version,...).
i looked at the ncm-cdispd code, each component is subscribed to its prefix, and if the CCM checksum of the path changes, the component runs. since version is under the prefix, a change in version will provide a different checksum of the prefix, and thus will trigger the component to run.
i always tought that there was a mechanism somewhere that also triggered the component if the component package was updated, but i wouldn't know how that worked, so thinking about it, that probably doesn't happen 😄 (well, maybe 😕 ) i opened quattor/ncm-cdispd#24 to not forget to investigate this
There was a problem hiding this comment.
i always tought that there was a mechanism somewhere that also triggered the component if the > component package was updated, but i wouldn't know how that worked, so thinking about it, that > probably doesn't happen 😄 (well, maybe 😕 )
It definitely does on the version we are using because I managed to trigger a run of all dispatched components across our plant when I changed the schema of ncm-spma a year or so back. One of machines was misconfigured and so when chkconfig ran it disabled a service which had startstop=true and I had to explain to people why the schema change to /software/packages had shutdown their (unregistered) database service.
OTOH I don't know which version of ncm-cdispd that was so perhaps a subsequent refactor removed that?
|
Are we merging 15.12 stuff yet? |
|
i guess we are awaiting final 15.8.0. we are now running 29 PRs on top of 15.8.0-rc3, merging would help 😄 |
ncm-metaconfig: cleanup component templates
No description provided.