"messaging" in cdist: What should be messaged? #137

Closed
opened 2021-11-20 13:24:33 +00:00 by ungleich-gitea · 3 comments

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.

*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`.
ungleich-gitea added the
Stale
label 2021-11-20 13:24:33 +00:00
Author
Owner

closed

closed
Author
Owner

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 allow

  • monitoring 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 the messages-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: 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 allow - monitoring 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 the `messages`-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.
Author
Owner

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).

*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).
Sign in to join this conversation.
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: ungleich-public/cdist#137
No description provided.