"messaging" in cdist: What should be messaged? #137
Labels
No Label
bugfix
cleanup
discussion
documentation
doing
done
feature
improvement
packaging
Stale
testing
TODO
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: ungleich-public/cdist#137
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Created by: tom-ee
This is a general question regarding messaging:
What is messaged/written to
$__messages_out
?Currently messages seem to be issued in an ad-hoc style: If the implementation of a type requires messaging, e.g. to act on some change in
gencode-remote
, messages are added.Also there might be some historical/technical dept as the messaging concept was added with/around v3.0.0 of cdist and existing types were not adjusted.
Would a styleguide like: "Every change to the target system results in a message" be a good idea?
This would allow us to decide from the cached
messages
-file if (and what) changes happened on the target.In PR #623 the updating of the package index would be messaged in
gencode-remote
.closed
Created by: tom-ee
The rephrased version combined with a recommendation against implemention it if it's not used is the current state.
For debugging inspecting
code-*
is the best way for sure. My intention for the proposal was targeted at the "day-to-day"-use, e.g. to allowmonitoring the
messages
-file and feed that into a monitoring system. If cdist is running on a fixed interval we can detect flapping configuration, get "poor mans deployment lines"(tm), ...after a dry-run (
cdist config -n <host>
) we can inspect themessages
-file to get an idea what would be changed. Currently we only get messages for a subset of changes that would be carried out on the target -- which degrades the dry-run to kind-of a syntax-check.Both could qualify as "somebody" is using it.
Created by: telmich
I agree rephrasing it to "Every change to the target system SHOULD result in a message". Even though consistency is a nice thing, I would not recommend to implement it, when nobody is using it.
Tracing if there is any change could/should be done by inspecting code-* ---> if there is code, there is a change (I know this is not always trivial, but would be the cleanest solution).