ungleich-public/cdist
ungleich-public/cdist
7
4
Fork 10
Code Issues 59 Pull requests 15 Projects Releases Wiki Activity

Execute all global explorers only when needed #227

New issue
Closed
opened 2021-11-20 15:21:56 +00:00 by ungleich-gitea · 3 comments
ungleich-gitea commented 2021-11-20 15:21:56 +00:00
Owner
Copy link

Created by: dheule

My intention is to create a brunch of global explorer which are of use in some cases and makes cdist more userfriendly. But now, all global explorers are allways executed, even the return value of the explorers is never used.

I think a possible approach can be to replace the result files with pipes, and on first read of the pipe, the explorer is executed by the core, all following read calls from the pipe are answered from the core with the result of the first real execute of the explorer.

So cdist can have an unlimited number of global explorers and only used explorers
are executed on the target host, all other explorers laying around are simply ignored.

Also a possible approach would be to create a new explorer type (dynamic explorers) which are sitting in a different directory to (for example dynexploer) and only this ones are executed with the conditional approach explained above. So the overhead to create pipes and monitor it is only in place on explorers which are not interesting for everyone ...

*Created by: dheule* My intention is to create a brunch of global explorer which are of use in some cases and makes cdist more userfriendly. But now, all global explorers are allways executed, even the return value of the explorers is never used. I think a possible approach can be to replace the result files with pipes, and on first read of the pipe, the explorer is executed by the core, all following read calls from the pipe are answered from the core with the result of the first real execute of the explorer. So cdist can have an unlimited number of global explorers and only used explorers are executed on the target host, all other explorers laying around are simply ignored. Also a possible approach would be to create a new explorer type (dynamic explorers) which are sitting in a different directory to (for example dynexploer) and only this ones are executed with the conditional approach explained above. So the overhead to create pipes and monitor it is only in place on explorers which are not interesting for everyone ...
ungleich-gitea commented 2021-11-20 15:48:54 +00:00
Author
Owner
Copy link

Created by: telmich

Hey Daniel,

point taken - we can laeve this open for some time as an idea (usually
we have put them into docs/dev/logs/* but the issue tracker is probably
not bad at all to expose ideas to other people).

Regarding the global explores/sap tuning: this is ia great use case!

If you ever submit your global explorers for inclusion, I suggest to
take care they run on every system (maybe not return something if they
don't know how), because they are always run (at the moment ;-)

Cheers,

Nico

dheule [Thu, Feb 06, 2014 at 11:08:45AM -0800]:

Now we have no problem at all,,, i have only write down a idea which are on
my mind ...

But if we extend the count of global explorers (some we already have
developed),
i expect a longer runtime of the explorers, this idea is against long run
times.
--> If you don't expect runtime issues with explorers in next time, feel
free to
close this issue ...

Some explorers which we have and are interesting for everyone are for
example:

  • machine_type --> is the system bare-metal or xen or vmware ?
  • cpu_cores --> how much cores have the cpu
  • cpu_sockets --> how much sockets have the system
  • memory --> how much memory a system have ...

This values are of interest for different tuning tasks of different
applications like sap or oracle etc ...

2014-02-06 17:01 GMT+01:00 Nico Schottelius notifications@github.com:

Interesting approach, but I am wondering which problem you are solving
with this approach? Why can't all global explorers be executed always?

Btw, we have some thoughts about extending cdist to support switches,
storage systems, etc. => there may come something up that creates
"environments" which a dedicated set of explorers / remote_copy and
remote_exec settings in the future.

—
Reply to this email directly or view it on GitHubhttps://github.com/telmich/cdist/issues/286#issuecomment-34337586
.

Reply to this email directly or view it on GitHub:
https://github.com/telmich/cdist/issues/286#issuecomment-34358461

PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0

*Created by: telmich* Hey Daniel, point taken - we can laeve this open for some time as an idea (usually we have put them into docs/dev/logs/\* but the issue tracker is probably not bad at all to expose ideas to other people). Regarding the global explores/sap tuning: this is ia great use case! If you ever submit your global explorers for inclusion, I suggest to take care they run on every system (maybe not return something if they don't know how), because they are always run (at the moment ;-) Cheers, Nico dheule [Thu, Feb 06, 2014 at 11:08:45AM -0800]: > Now we have no problem at all,,, i have only write down a idea which are on > my mind ... > > But if we extend the count of global explorers (some we already have > developed), > i expect a longer runtime of the explorers, this idea is against long run > times. > --> If you don't expect runtime issues with explorers in next time, feel > free to > close this issue ... > > Some explorers which we have and are interesting for everyone are for > example: > - machine_type --> is the system bare-metal or xen or vmware ? > - cpu_cores --> how much cores have the cpu > - cpu_sockets --> how much sockets have the system > - memory --> how much memory a system have ... > > This values are of interest for different tuning tasks of different > applications like sap or oracle etc ... > > 2014-02-06 17:01 GMT+01:00 Nico Schottelius notifications@github.com: > > > Interesting approach, but I am wondering which problem you are solving > > with this approach? Why can't all global explorers be executed always? > > > > Btw, we have some thoughts about extending cdist to support switches, > > storage systems, etc. => there may come something up that creates > > "environments" which a dedicated set of explorers / remote_copy and > > remote_exec settings in the future. > > > > — > > Reply to this email directly or view it on GitHubhttps://github.com/telmich/cdist/issues/286#issuecomment-34337586 > > . > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/telmich/cdist/issues/286#issuecomment-34358461 ## PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0
ungleich-gitea commented 2021-11-20 15:48:56 +00:00
Author
Owner
Copy link

Created by: dheule

Now we have no problem at all,,, i have only write down a idea which are on
my mind ...

But if we extend the count of global explorers (some we already have
developed),
i expect a longer runtime of the explorers, this idea is against long run
times.
--> If you don't expect runtime issues with explorers in next time, feel
free to
close this issue ...

Some explorers which we have and are interesting for everyone are for
example:

  • machine_type --> is the system bare-metal or xen or vmware ?
  • cpu_cores --> how much cores have the cpu
  • cpu_sockets --> how much sockets have the system
  • memory --> how much memory a system have ...

This values are of interest for different tuning tasks of different
applications like sap or oracle etc ...

2014-02-06 17:01 GMT+01:00 Nico Schottelius notifications@github.com:

Interesting approach, but I am wondering which problem you are solving
with this approach? Why can't all global explorers be executed always?

Btw, we have some thoughts about extending cdist to support switches,
storage systems, etc. => there may come something up that creates
"environments" which a dedicated set of explorers / remote_copy and
remote_exec settings in the future.

—
Reply to this email directly or view it on GitHubhttps://github.com/telmich/cdist/issues/286#issuecomment-34337586
.

*Created by: dheule* Now we have no problem at all,,, i have only write down a idea which are on my mind ... But if we extend the count of global explorers (some we already have developed), i expect a longer runtime of the explorers, this idea is against long run times. --> If you don't expect runtime issues with explorers in next time, feel free to close this issue ... Some explorers which we have and are interesting for everyone are for example: - machine_type --> is the system bare-metal or xen or vmware ? - cpu_cores --> how much cores have the cpu - cpu_sockets --> how much sockets have the system - memory --> how much memory a system have ... This values are of interest for different tuning tasks of different applications like sap or oracle etc ... 2014-02-06 17:01 GMT+01:00 Nico Schottelius notifications@github.com: > Interesting approach, but I am wondering which problem you are solving > with this approach? Why can't all global explorers be executed always? > > Btw, we have some thoughts about extending cdist to support switches, > storage systems, etc. => there may come something up that creates > "environments" which a dedicated set of explorers / remote_copy and > remote_exec settings in the future. > > — > Reply to this email directly or view it on GitHubhttps://github.com/telmich/cdist/issues/286#issuecomment-34337586 > .
ungleich-gitea commented 2021-11-20 15:48:57 +00:00
Author
Owner
Copy link

Created by: telmich

Interesting approach, but I am wondering which problem you are solving with this approach? Why can't all global explorers be executed always?

Btw, we have some thoughts about extending cdist to support switches, storage systems, etc. => there may come something up that creates "environments" which a dedicated set of explorers / remote_copy and remote_exec settings in the future.

*Created by: telmich* Interesting approach, but I am wondering which problem you are solving with this approach? Why can't all global explorers be executed always? Btw, we have some thoughts about extending cdist to support switches, storage systems, etc. => there may come something up that creates "environments" which a dedicated set of explorers / remote_copy and remote_exec settings in the future.
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
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#227
No description provided.