onchange variable #23

New Issue

ungleich-gitea · 2021-11-20T11:24:53Z

ungleich-gitea commented

2021-11-20 11:24:53 +00:00

let's imagine following:

__foo bar
onchange='__foo/bar' __baz

basically same as require='', but following type will be run only if dependency generated code.

@poljakowski can probably comment if this is even possible with current dependency resolver.

with this we also need non-idempotent __execute or __exec or whatever... which effectively adds --onchange to every type.

let's imagine following: ```bash __foo bar onchange='__foo/bar' __baz ``` basically same as `require=''`, but following type will be run only if dependency generated code. @poljakowski can probably comment if this is even possible with current dependency resolver. with this we also need non-idempotent `__execute` or `__exec` or whatever... which effectively adds `--onchange` to every type.

ungleich-gitea closed this issue

2021-11-20 11:24:53 +00:00

ungleich-gitea commented

2021-11-20 15:26:38 +00:00

I guess this is rejected so I am closing both, the issue and the MR.

ungleich-gitea commented

2021-11-20 15:26:40 +00:00

Just to make it clear, I have implemented it to see if it is even possible, and to see how and how easy/hard it can be done. And it is not about "executing a type", but about "processing a type" which includes all: explorers, manifest, gencode-*.

ungleich-gitea commented

2021-11-20 15:26:41 +00:00

Yet cdist just does not have any concept to do this. There is no such thing as executing a type. Using a type in a manifest creates an object in a database. If this leads to generation of some code is entirely up to the type itself. You also don't get this in a generic way by adding this onchange feature to cdist.

b-b-but @poljakowski just did that. what am I missing here? if type generates code, then there is a change, some actions. sorry, but I get this feeling that we are going in totally separate paths here and we are not talking about same thing.

and please stop, for moment, thinking that this is only good for restarting some service.

> Yet cdist just does not have any concept to do this. There is no such thing as `executing a type`. Using a type in a manifest creates an object in a database. If this leads to generation of some code is entirely up to the type itself. You also don't get this in a generic way by adding this onchange feature to cdist. b-b-but @poljakowski just did that. what am I missing here? if type generates code, then there is a change, some actions. sorry, but I get this feeling that we are going in totally separate paths here and we are not talking about same thing. and please stop, for moment, thinking that this is only good for restarting some service.

ungleich-gitea commented

2021-11-20 15:26:42 +00:00

With the above being said, and as all mentioned examples are related to restarting/reloading services on config changes: I do think cdist could use a proper __service type, because this is just something that everybody uses all the time.

IMHO the by far most common pattern in cdist (or any other config management system) is:

install packages
deploy/change config files
set service state to enabled/disabled started/stopped
reload/restart service if config changed

I wrote such a __service type long time ago. I'm sure some will not like it and will want to reinvent it. No problem.

What it does is:

handle the starting/stopping enabling/disabling and reloading/restarting of services on centos|ubuntu|debian|archlinux. It's easy to add other distros.
it is implemented in a way that allows other types to re-use the code to start/stop/enable/disable/reload a service from their gencode-remote scripts.

e.g.

[23:24:25] eos:type% cat ./__unbound/gencode-remote
#!/bin/sh -e
#
# 2014-2018 Steven Armstrong (steven-cdist at armstrong.cc)
#

if ! grep -q "^__file/etc/unbound" "$__messages_in"; then
   # nothing changed, nothing to do
   exit 0
fi

service_object="$__global/object/__service/unbound/$__cdist_object_marker"

if grep -q "^__file/etc/unbound/unbound.conf" "$__messages_in"; then
   printf '%s && %s || true\n' \
      "$(cat "$service_object/explorer/status-command")" \
      "$(cat "$service_object/explorer/restart-command")"
else
   printf '%s && %s || true\n' \
      "$(cat "$service_object/explorer/status-command")" \
      "$(cat "$service_object/explorer/reload-command")"
fi
[23:24:26] eos:type%

I once had ideas to grow this into a formal API for types to interact.
Here are some related notes from a different life.

[23:17:06] eos:~% cat ~/log/2016-01-25.cdist-event-emit-schedule
Introduce type 'actions' or 'intents' (as in Android) or $better_name.

The idea would be that a cdist type has an api to allow other types to
use/share functionality.

For example a __service type could expose the following actions that it implements and uses internally to other types:

disable: disable a service
stop: stop a service
start: start a service
restart: restart a service
reload: reload a service


This could then be used by other types like this:

# in manifest
cdist schedule __service/ssh enable
schedule:
   schedule the execution of the required code in the gencode of the object in
   who's manifest 'schedule' is called
parameters:
   --before
      run the scheduled code before the generated code of this object
   --after
      run the scheduled code after the generated code of this object


# in gencode
cdist emit __service/ssh enable
emit:
   generate the required code to perform the desired action and write it to stdout.
   it will be run together with the rest of the generated code.

cdist emit __service/ssh disable
cdist emit __service/ssh stop
cdist emit __service/ssh start
cdist emit __service/ssh restart
cdist emit __service/ssh reload


Maybe 'emit' should be called 'include' instead as that would more explicitly
describe what is actually happening. Then again, using it as 'cdist include'
could be confusing or misleading.


--------------------------------------------------------------------------------

Other possibilities to use this:

# subcommand that generates and executes the required code on the given targets
cdist call __service/ssh enable $target_host

[23:17:10] eos:~%

Some other, somewhat related concept we had talked about in the past is what puppet calls run stages.

Not sure any of this is relevant for any of you. Just dumping it here for reference.

With the above being said, and as all mentioned examples are related to restarting/reloading services on config changes: I do think cdist could use a proper __service type, because this is just something that everybody uses all the time. IMHO the by far most common pattern in cdist (or any other config management system) is: - install packages - deploy/change config files - set service state to enabled/disabled started/stopped - reload/restart service if config changed I wrote such a [__service](https://github.com/asteven/cdist-types/tree/master/__service) type long time ago. I'm sure some will not like it and will want to reinvent it. No problem. What it does is: - handle the starting/stopping enabling/disabling and reloading/restarting of services on centos|ubuntu|debian|archlinux. It's easy to add other distros. - it is implemented in a way that allows other types to re-use the code to start/stop/enable/disable/reload a service from their gencode-remote scripts. e.g. ``` [23:24:25] eos:type% cat ./__unbound/gencode-remote #!/bin/sh -e # # 2014-2018 Steven Armstrong (steven-cdist at armstrong.cc) # if ! grep -q "^__file/etc/unbound" "$__messages_in"; then # nothing changed, nothing to do exit 0 fi service_object="$__global/object/__service/unbound/$__cdist_object_marker" if grep -q "^__file/etc/unbound/unbound.conf" "$__messages_in"; then printf '%s && %s || true\n' \ "$(cat "$service_object/explorer/status-command")" \ "$(cat "$service_object/explorer/restart-command")" else printf '%s && %s || true\n' \ "$(cat "$service_object/explorer/status-command")" \ "$(cat "$service_object/explorer/reload-command")" fi [23:24:26] eos:type% ``` I once had ideas to grow this into a formal API for types to interact. Here are some related notes from a different life. ``` [23:17:06] eos:~% cat ~/log/2016-01-25.cdist-event-emit-schedule Introduce type 'actions' or 'intents' (as in Android) or $better_name. The idea would be that a cdist type has an api to allow other types to use/share functionality. For example a __service type could expose the following actions that it implements and uses internally to other types: disable: disable a service stop: stop a service start: start a service restart: restart a service reload: reload a service This could then be used by other types like this: # in manifest cdist schedule __service/ssh enable schedule: schedule the execution of the required code in the gencode of the object in who's manifest 'schedule' is called parameters: --before run the scheduled code before the generated code of this object --after run the scheduled code after the generated code of this object # in gencode cdist emit __service/ssh enable emit: generate the required code to perform the desired action and write it to stdout. it will be run together with the rest of the generated code. cdist emit __service/ssh disable cdist emit __service/ssh stop cdist emit __service/ssh start cdist emit __service/ssh restart cdist emit __service/ssh reload Maybe 'emit' should be called 'include' instead as that would more explicitly describe what is actually happening. Then again, using it as 'cdist include' could be confusing or misleading. -------------------------------------------------------------------------------- Other possibilities to use this: # subcommand that generates and executes the required code on the given targets cdist call __service/ssh enable $target_host [23:17:10] eos:~% ``` Some other, somewhat related concept we had talked about in the past is what puppet calls [run stages](https://puppet.com/docs/puppet/7.5/lang_run_stages.html). Not sure any of this is relevant for any of you. Just dumping it here for reference.

ungleich-gitea commented

2021-11-20 15:26:44 +00:00

I guess my problem with this is that you are basically all saying that you want to execute a type if something changed.

Yet cdist just does not have any concept to do this. There is no such thing as executing a type. Using a type in a manifest creates an object in a database. If this leads to generation of some code is entirely up to the type itself. You also don't get this in a generic way by adding this onchange feature to cdist.

The following means nothing:

onchange="__file/path/to/something/foobar/likes" \
   __service/foobar

If the foobar service is already in it's desired state, the __service type will just do nothing, because it is not aware that the onchange'ed __file has anything to do with it. And cdist core can not do anything about it.

So you can only use this onchange feature with types that unconditionally generate code. The only type that I can imagine to be useful in this context is an __exec type. Or some other purpose built custom type.

Then there's the ad-hoc / non-reusable nature of it.
e.g. consider the given examples:

require=${vhost_objects-} \
__check_messages apache2_reload \
  --pattern '^__(file/etc/apache2/sites-available/|link/etc/apache2/sites-enabled)' \
  --execute '/etc/init.d/apache2 reload'

onchange=${vhost_objects-} \
__exec apache2_reload --run '/etc/init.d/apache2 reload'

I use Ubuntu. Any types using the above constructs will not work for me.
Should such types be part of cdist?

If the above problem is solved using a custom type, it can be done in a way (or changed over time) to also work on e.g. Ubuntu.

If you really absolutely want such a 'onchange' feature for some ad-hoc solution, which I'm sure there are valid reasons for, you could just solve it with a custom type like the following.

__conditional_exec reload_apache \
   --message '^__(file|link|line)/etc/apache/sites-available' \
   --message '^__(file|link|line)/etc/apache/sites-enabled' \
   --changed '__key_value/etc/default/apache:some-key' \
   --changed '__some_other_type_that_may_have_generated_code' \
   --exec 'service apache reload'

Or not?

I guess my problem with this is that you are basically all saying that you want to `execute a type if something changed`. Yet cdist just does not have any concept to do this. There is no such thing as `executing a type`. Using a type in a manifest creates an object in a database. If this leads to generation of some code is entirely up to the type itself. You also don't get this in a generic way by adding this onchange feature to cdist. The following means nothing: ``` onchange="__file/path/to/something/foobar/likes" \ __service/foobar ``` If the foobar service is already in it's desired state, the __service type will just do nothing, because it is not aware that the onchange'ed __file has anything to do with it. And cdist core can not do anything about it. So you can only use this onchange feature with types that unconditionally generate code. The only type that I can imagine to be useful in this context is an __exec type. Or some other purpose built custom type. Then there's the ad-hoc / non-reusable nature of it. e.g. consider the given examples: ``` require=${vhost_objects-} \ __check_messages apache2_reload \ --pattern '^__(file/etc/apache2/sites-available/|link/etc/apache2/sites-enabled)' \ --execute '/etc/init.d/apache2 reload' ``` ``` onchange=${vhost_objects-} \ __exec apache2_reload --run '/etc/init.d/apache2 reload' ``` I use Ubuntu. Any types using the above constructs will not work for me. Should such types be part of cdist? If the above problem is solved using a custom type, it can be done in a way (or changed over time) to also work on e.g. Ubuntu. If you really absolutely want such a 'onchange' feature for some ad-hoc solution, which I'm sure there are valid reasons for, you could just solve it with a custom type like the following. ``` __conditional_exec reload_apache \ --message '^__(file|link|line)/etc/apache/sites-available' \ --message '^__(file|link|line)/etc/apache/sites-enabled' \ --changed '__key_value/etc/default/apache:some-key' \ --changed '__some_other_type_that_may_have_generated_code' \ --exec 'service apache reload' ``` Or not?

ungleich-gitea commented

2021-11-20 15:26:45 +00:00

Yes, I know how messaging works and I have read the manual multiple times and this doesn't change anything for me. If I could get 1 € every time I have to create new type just to get some single use specific situation resolved, I wouldn't propose onchange="".

Yes, I know how messaging works and I have read the manual multiple times and this doesn't change anything for me. If I could get 1 € every time I have to create new type just to get some single use specific situation resolved, I wouldn't propose `onchange=""`.

ungleich-gitea commented

2021-11-20 15:26:46 +00:00

@nico Well, my point is not, that there is another set of problems, that this would solve. I just wanted to highlight, that this would be an easier, OOTB interface to the messaging system: any type could be messaging-aware without the said type actually reading messages.

Hence it would make the usage and writing of types easier with more concise manifests.

@nico Well, my point is not, that there is another set of problems, that this would solve. I just wanted to highlight, that this would be an easier, OOTB interface to the messaging system: any type could be *messaging-aware* without the said type actually reading messages. Hence it would make the usage and writing of types easier with more concise manifests.

ungleich-gitea commented

2021-11-20 15:26:48 +00:00

@fancsali Can you specify a problem that onchange would solve that messaging doesn't solve at the moment?

@fancsali Can you specify a problem that **onchange** would solve that messaging doesn't solve at the moment?

ungleich-gitea commented

2021-11-20 15:26:49 +00:00

Thanks for the example, @ander. How this would typically be solved

__download xyz
require="__download/xyz" __unpack xyz

From the internals:

I'd expect __unpack to have some kind of notion to find out whether it did already it's job. Maybe by checking for a specific file existence. It's important to remember that __unpack itself should be idempotent.
In this example you don't even need the messaging system
It would however be very typical of __download to emit a message, when it actually downloaded something. This is good behaviour and allows loose coupling.
Then you could have __unpack_downloaded that only unpacks, if __download emitted a message

So for nothing of above is onchange required and given the current examples I'd say that it is even confusing to support or implement it, because we do have a straight forward, easy to use solution builtin.

I strongly recommend to read https://www.cdi.st/manual/latest/cdist-messaging.html, which also references exactly the case @matze was talking about.

Thanks for the example, @ander. How this would typically be solved ``` __download xyz require="__download/xyz" __unpack xyz ``` From the internals: * I'd expect `__unpack` to have some kind of notion to find out whether it did already it's job. Maybe by checking for a specific file existence. It's important to remember that `__unpack` itself should be idempotent. * In this example you don't even **need** the messaging system * It *would* however be very typical of `__download` to emit a message, when it actually downloaded something. This is good behaviour and allows loose coupling. * Then you *could* have `__unpack_downloaded` that only unpacks, if `__download` emitted a message So for nothing of above is onchange required and given the current examples I'd say that it is even confusing to support or implement it, because we do have a straight forward, easy to use solution builtin. I strongly recommend to read https://www.cdi.st/manual/latest/cdist-messaging.html, which also references exactly the case @matze was talking about.

ungleich-gitea commented

2021-11-20 15:26:50 +00:00

@nico Noting that most of them just send messages that the messaging system can be supported, there are 7 types searching through the messaging system (grep -ri ".*grep.*\$__messages" . should display them).

I rather think the general cdist user isn't really aware about he can use the messaging system. He don't know about that it's capable or usable of doing so. Also, it can only be used in type manifests where the type that emits messages must be in the dependency, while the onchange= can be used in initial manifests, too. Also, did I mentioned recursion?

@nico Noting that most of them just send messages that the messaging system can be supported, there are 7 types searching through the messaging system (`grep -ri ".*grep.*\$__messages" .` should display them). I rather think the general cdist user isn't really aware about he can use the messaging system. He don't know about that it's capable or usable of doing so. Also, it can only be used in type manifests where the type that emits messages must be in the dependency, while the `onchange=` can be used in initial manifests, too. Also, did I mentioned recursion?

ungleich-gitea commented

2021-11-20 15:26:52 +00:00

@matze I am not sure where the impression comes from that the messaging system is not used. It is an integral part of cdist and "just not knowing about it" and trying to re-implement an existing feature does not sound very promising to me.

I count 150 occurrences with a simple check only in the upstream repo:

[17:45] nb3:cdist% grep __messages -r cdist/conf/type/ | wc  -l
150

So it's not that nobody is using it, it's more the opposite.

@matze I am not sure where the impression comes from that the messaging system is not used. It is an integral part of cdist and "just not knowing about it" and trying to re-implement an existing feature does not sound very promising to me. I count 150 occurrences with a simple check only in the upstream repo: ``` [17:45] nb3:cdist% grep __messages -r cdist/conf/type/ | wc -l 150 ``` So it's not that nobody is using it, it's more the opposite.

ungleich-gitea commented

2021-11-20 15:26:53 +00:00

I promised not to add anything, but...

What is the problem to solve: reloading services on demand. What is the solution: the messaging system already solves this problem

imho, messaging system is unintuitive and feels like a hack. messaging support hasn't been a requirment to get type into core, but idempotency is required and that's something we always can rely on in very simple way, just like require=''.

having conditional execution for type is not only good for "just restarting something", but for whatever actions one must do, like I mentioned in older comment. I have to run many types in order, but some types are only relevant when something else before them actually does something. with that we can also win in execution time.

idea for onchange='' came to me when I started to write __download and __unpack.

something I wrote yesterday:

__download /var/www/vault.tar.gz \
    --url https://github.com/dani-garcia/bw_web_builds/releases/download/v2.19.0/bw_web_v2.19.0.tar.gz \
    --sum md5:c219a5bed2104c75c05d3834812572a6

__unpack /var/www/vault.tar.gz \
    --destination /var/www/vault \
    --tar-strip 1 \
    --preserve-archive \
    --backup-destination

these two types can be chained together, because __unpack makes sense only when __download happens. I'm pretty sure that once we open this door for onchange="" we can have many such examples.

so, instead of writing gencode script or coming up clever ways using messaging or writing some state information to target host, I can write (type or init) manifest, use battle-tested existing types, chain them together and have much more readable and maintainable manifest versus many times longer gencode. also don't have to reinvent the wheel all the time.

and yes, restarting some service after series of actions, is main use, because instead of having --onchange for every type, we have that in core, out of the box.

I promised not to add anything, but... > What is the problem to solve: reloading services on demand. What is the solution: the messaging system already solves this problem imho, messaging system is unintuitive and feels like a hack. messaging support hasn't been a requirment to get type into core, but idempotency is required and that's something we always can rely on in very simple way, just like `require=''`. having conditional execution for type is not only good for "just restarting something", but for whatever actions one must do, like I mentioned in older comment. I have to run many types in order, but some types are only relevant when something else before them actually does something. with that we can also win in execution time. idea for `onchange=''` came to me when I started to write `__download` and `__unpack`. something I wrote yesterday: ``` __download /var/www/vault.tar.gz \ --url https://github.com/dani-garcia/bw_web_builds/releases/download/v2.19.0/bw_web_v2.19.0.tar.gz \ --sum md5:c219a5bed2104c75c05d3834812572a6 __unpack /var/www/vault.tar.gz \ --destination /var/www/vault \ --tar-strip 1 \ --preserve-archive \ --backup-destination ``` these two types can be chained together, because `__unpack` makes sense only when `__download` happens. I'm pretty sure that once we open this door for `onchange=""` we can have many such examples. so, instead of writing gencode script or coming up clever ways using messaging or writing some state information to target host, I can write (type or init) manifest, use battle-tested existing types, chain them together and have much more readable and maintainable manifest versus many times longer gencode. also don't have to reinvent the wheel all the time. and yes, restarting some service after series of actions, is main use, because instead of having `--onchange` for every type, we have that in core, out of the box.

ungleich-gitea commented

2021-11-20 15:26:55 +00:00

So if "messaging solve that problem", why many struggle with it? Why there are not really a type out there utilizing the messaging system? If the messaging system would solve it, why it isn't solved in upstream types? The most common used solution are --onchange and executing the __service type all times (at least this is my impression). Why there are no types that reloading services on demand upstream?

I don't think we're bored and think how we can annoy you with pointless cdist proposals. It's rather a try to solve our problems. By now, we commonly have many types that are required by the service-reload type. As there isn't just one init-system, each type must develop it's own code to recursively check for messages. Also, service reloading might not the only usecase for messages. This means there will be many code out there doing the same. If you don't want copy'n'paste disasters, we need a library or an option to call a cdist-helper for it inside the scripts.

The feature we propose is to provide a cdist-native generic way of doing so. Reasons why this should be better are in other posts of this issue - I don't want to repeat me again. If you wanna refuse this feature for cdist, there should be clarification and documentation/education about how to do such things properly (as nobody except Steven came to this idea). Also, cdist should provide such types to do so.

So if "messaging solve that problem", why many struggle with it? Why there are not really a type out there utilizing the messaging system? If the messaging system would solve it, why it isn't solved in upstream types? The most common used solution are `--onchange` and executing the `__service` type all times (at least this is my impression). Why there are no types that reloading services on demand upstream? I don't think we're bored and think how we can annoy you with pointless cdist proposals. It's rather a try to solve our problems. By now, we commonly have many types that are required by the service-reload type. As there isn't just one init-system, each type must develop it's own code to recursively check for messages. Also, service reloading might not the only usecase for messages. This means there will be many code out there doing the same. If you don't want copy'n'paste disasters, we need a library or an option to call a cdist-helper for it inside the scripts. The feature we propose is to provide a cdist-native generic way of doing so. Reasons why this should be better are in other posts of this issue - I don't want to repeat me again. If you wanna refuse this feature for cdist, there should be clarification and documentation/education about how to do such things properly (as nobody except Steven came to this idea). Also, cdist should provide such types to do so.

ungleich-gitea commented

2021-11-20 15:26:56 +00:00

@matze Now we are talking.

What is the problem to solve: reloading services on demand.
What is the solution: the messaging system already solves this problem

So if that's the main problem we want to solve, then we don't need onchange. If there is a different problem we want to solve, let's discuss that.

@matze Now we are talking. What is the problem to solve: reloading services on demand. What is the solution: the messaging system already solves this problem So if that's the main problem we want to solve, then we don't need onchange. If there is a different problem we want to solve, let's discuss that.

ungleich-gitea commented

2021-11-20 15:26:57 +00:00

What is tired to solve? To provide a generic way of only executing a type if something changed based on current run information. Common example: service reloading on demand.

ungleich-gitea commented

2021-11-20 15:26:59 +00:00

Again, to share some POV from someone, who's mainly a user...

Having systemctl ... --if-required and/or __check_messages seems to me to be a bit off from the more declarative cdist way of doing things. It's a bit like scripting in an imperative manner, within the manifest, while those should really go into the output of the gencode-* scripts.

Also, that would mean, potentially all the types I might need to apply or not apply depending on the outcome of other things need to be amended to be --if-required-aware. Or, I have bit of a boilerplate with __check_messages.

So, having a onchange= variable similar to the require= would be moving that logic one level higher, and allowing the users to have simpler, and yet smarter types. In other words, in my view the potential in that is that it comes out of the box...

It might not make sense, but that's how I see it... ;)

Again, to share some POV from someone, who's mainly a user... Having `systemctl ... --if-required` and/or `__check_messages` seems to me to be a bit off from the more declarative `cdist` way of doing things. It's a bit like scripting in an imperative manner, within the manifest, while those should really go into the output of the `gencode-*` scripts. Also, that would mean, potentially all the types I might need to apply or not apply depending on the outcome of other things need to be amended to be `--if-required`-aware. Or, I have bit of a boilerplate with `__check_messages`. So, having a `onchange=` variable similar to the `require=` would be moving that logic one level higher, and allowing the users to have simpler, and yet smarter types. In other words, in my view the potential in that is that it comes out of the box... It might not make sense, but that's how I see it... ;)

ungleich-gitea commented

2021-11-20 15:27:00 +00:00

I'm still standing on my original question of the problem that is tried to be solved. If we are not solving a problem, we should not add code.

ungleich-gitea commented

2021-11-20 15:27:01 +00:00

I agree, we should not prolong this.

@nico @steven what is your final decision?

I agree, we should not prolong this. @nico @steven what is your final decision?

ungleich-gitea commented

2021-11-20 15:27:03 +00:00

Something we haven't talked about is idempotency. As onchange= and other methods based on the messaging system only use runtime information. Given that, they "fail" to refresh the service if changes are done outside the current cdist run. That may be an abort in a cdist run or a manual change. But it doesn't did it's job in reloading the service.

To be sure, the service has to be reloaded every run, or everything is checked which could be changed since the last reload. I think for most people, it's ok if the accuracy isn't 100% or if it's just based on the current run, but since types should check the current state and change it to the should-state - which is to update the service that it runs with the freshest configuration - it's something if there should come types dedicated to reload services if required.

Something we haven't talked about is idempotency. As `onchange=` and other methods based on the messaging system only use runtime information. Given that, they "fail" to refresh the service if changes are done outside the current cdist run. That may be an abort in a cdist run or a manual change. But it doesn't did it's job in reloading the service. To be sure, the service has to be reloaded every run, or everything is checked which could be changed since the last reload. I think for most people, it's ok if the accuracy isn't 100% or if it's just based on the current run, but since types should check the current state and change it to the should-state - which is to update the service that it runs with the freshest configuration - it's something if there should come types dedicated to reload services if required.

ungleich-gitea commented

2021-11-20 15:27:06 +00:00

@poljakowski thanks for your hard work for implementing and additionally explaining this feature.

I think Ander's primary focus are init manifests.

yes, init and type manifests.

it's totally okay and there's no hard feelings if @nico and @steven decide not to have this feature in cdist, because I can maintain my own patches for cdist just fine. my only ask is not to delay with final decision, so I can go on with my stuff and stop waiting.

other than that, I have nothing else to add to this conversation.

@poljakowski thanks for your hard work for implementing and additionally explaining this feature. > I think Ander's primary focus are init manifests. yes, init and type manifests. it's totally okay and there's no hard feelings if @nico and @steven decide not to have this feature in cdist, because I can maintain my own patches for cdist just fine. my only ask is not to delay with final decision, so I can go on with my stuff and stop waiting. other than that, I have nothing else to add to this conversation.

Sign in to join this conversation.