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

New issue

Closed

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

ungleich-gitea commented 2021-11-20 13:24:33 +00:00

Owner

Copy link

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 2021-11-20 13:24:33 +00:00

• closed this issue
• added the
  Stale
  label

ungleich-gitea commented 2021-11-20 15:42:30 +00:00

Author

Owner

Copy link

closed

closed

ungleich-gitea commented 2021-11-20 15:42:31 +00:00

Author

Owner

Copy link

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.

ungleich-gitea commented 2021-11-20 15:42:33 +00:00

Author

Owner

Copy link

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 Branch/Tag specified

Branches Tags

master

7.0

6.9

py3.10

ander/__package_apt_update_index

haproxy-dualstack

ander/__sed

beta

ander/os_version_debian_sid

evilham-compatibility-fixes

ander/__rsync

__snakeoil_cert

ander/update_readme

__download_improvements

feature/onchange

cleanup/string-formatting

feature/type-relationship-graph

cleanup/ssh-auth-keys-types

__letsencrypt_cert-fix-hooks

bugfix/preos-debug

bugfix/in-script-import

6.8

bugfix/sphinx-docs-build

6.7

cherry-pick-2f433a14

bugfix/make-code-consistent

6.6

regain-py3.2-support

6.5

bugfix/multiple-log-lines

matterbridge

coturn

alpinefix

matrix

new-type/network-interface

feature/process

6.4

feature/info-command

feature/libexec

6.3

preos-plugins-dir-opt

gitlab-ci

6.2

order-dep-fix

6.1

6.0

build/support-pip-from-git

feature/shell-lib

5.1

feature/support-type-deprecation

5.0

feature/python-types

4.11

4.10

shellcheck

4.9

4.8

freebsd-improvements

new-prometheus

key_value-onchange

feature/output_streams

AnotherKamila-patch-1

__letsencrypt_cert-fixes

letsencrypt-cron-fix

4.7

newtype-__letsencrypt_cert

os_explorer_devuan_fix

prometheus-exporter-fixes

daemontools-for-fbsd

type-prometheus-exporter-from-master

prometheus-more-fixes

4.6

4.5

fix-j

steven-backport

4.4

prometheus-fixes

grafana_dashboard

prometheus

daemontools

consul_improvements

feature/trigger

4.3

4.0-pre-not-stable

4.2

4.1

4.0

feature_install_and_preos

3.1

no-dot-cdist

random_dot_cdist

feature_yum_url

feature_files_export

3.0

2.3

2.2

2.1

ssh_callback

2.0

archive_shell_function_approach

1.7

1.6

1.5

1.4

1.3

1.2

1.1

1.0

7.0.0

6.9.8

6.9.7

6.9.6

6.9.5

6.9.4

6.9.3

6.9.2

6.9.1

6.9.0

6.8.0

6.7.0

6.6.0

6.5.6

6.5.5

6.5.4

6.5.3

6.5.2

6.5.1

6.5.0

6.4.0

6.3.0

6.2.0

6.1.1

6.1.0

6.0.4

6.0.3

6.0.2

6.0.1

6.0.0

5.1.3

5.1.2

5.1.1

5.1.0

5.0.2

5.0.1

5.0.0

4.11.1

4.11.0

4.10.11

4.10.10

4.10.9

4.10.8

4.10.7

4.10.6

4.10.5

4.10.4

4.10.3

4.10.2

4.10.1

4.10.0

4.9.1

4.9.0

4.8.4

4.8.3

4.8.2

4.8.1

4.8.0

4.7.3

4.7.2

4.7.1

4.7.0

4.6.1

4.6.0

4.5.0

4.4.4

4.4.3

4.4.2

4.4.1

4.4.0

4.3.2

4.3.1

4.3.0

4.2.2

4.2.1

4.2.0

4.1.0

4.0.0

3.1.13

tn1

3.1.12

3.1.11

3.1.10

3.1.9

3.1.8

3.1.7

3.1.6

4.0.0pre3

3.1.5

3.1.4

3.1.3

3.1.2

3.1.1

3.1.0

4.0.0pre2

3.0.9

3.0.8

3.0.7

3.0.6

3.0.5

3.0.4

3.0.3

4.0.0pre1

3.0.2

3.0.1

3.0.0

2.3.7

2.3.6

2.3.5

2.3.4

2.3.3

2.3.2

2.3.1

2.3.0

2.2.0

2.1.2

2.1.1

2.1.0

2.1.0pre8

2.1.0pre7

2.1.0pre6

2.0.15

2.1.0pre5

2.1.0pre4

2.1.0pre3

2.1.0pre2

2.1.0pre1

2.0.14

2.0.13

2.0.12

2.0.11

2.0.10

2.0.9

2.0.8

2.0.7

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

1.7.1

1.7.0

1.6.2

1.6.1

1.6.0

1.5.0

1.4.1

1.4.0

1.3.2

1.3.1

1.3.0

1.2.0

1.1.0

1.0.4

1.0.3

1.0.2

1.0.1

1.0.0

0.9.9

0.9.8

0.9.7

0.9.6

0.9.5

0.9.4

0.9.3

0.9.2

0.9.1

0.9

0.8

0.7

0.6

0.5

0.4

0.3

0.2

0.1

Labels

Clear labels   

bugfix

  

cleanup

  

discussion

  

documentation

  

doing

  

done

  

feature

  

improvement

  

packaging

  

Stale

  

testing

  

TODO

No labels

bugfix

cleanup

discussion

documentation

doing

done

feature

improvement

packaging

Stale

testing

TODO

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

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.