Let salt-call instruct the minion to do the work #2375

Closed
madduck opened this Issue Oct 28, 2012 · 11 comments

Comments

Projects
None yet
3 participants
@madduck
Contributor

madduck commented Oct 28, 2012

salt-call can be used to obtain policy and run commands once in pull,
one-off fashion, whereas the salt-minion persists in the background and
reacts to published commands.

Both can coexist and since they reuse the same Python code and talk to the
same master, there is no danger of duplication, redundancy or getting out of
sync.

However, while the minion logs what it does to /var/log, salt-call does
not.

This made me think that it would be good to have a salt-call mode that
instructed the local minion to do the work, rather than to do the work itself,
e.g.

salt-call --minion state.highstate

run on myhost.example.org would have the same effect as a call

salt myhost.example.org state.highstate

run on the master: the salt-minion process would wake up and ensure that the
highstate is applied.

@thatch45

This comment has been minimized.

Show comment
Hide comment
@thatch45

thatch45 Oct 29, 2012

Member

I think that the salt-call command not logging at all to a file should be considered an issue. As for having it communicate to the running minion, I don't think this is the right move, because when the salt-minion runs it executes the call itself in a separate process anyway.

Member

thatch45 commented Oct 29, 2012

I think that the salt-call command not logging at all to a file should be considered an issue. As for having it communicate to the running minion, I don't think this is the right move, because when the salt-minion runs it executes the call itself in a separate process anyway.

@madduck

This comment has been minimized.

Show comment
Hide comment
@madduck

madduck Oct 29, 2012

Contributor

also sprach Thomas S Hatch notifications@github.com [2012.10.29.0439 +0100]:

I think that the salt-call command not logging at all to a file
should be considered an issue. As for having it communicate to the
running minion, I don't think this is the right move, because when
the salt-minion runs it executes the call itself in a separate
process anyway.

There are other reasons. For instance, I don't think two highstate
runs should happen at the same time, but that can only be ensured if
it all converges in one place.

To the local admin, it doesn't really matter what the site policy is
regarding how salt runs… salt-call, remote execution, it's all the
same. Hence it should all be logged in the same place.

And I am sure there are other reasons. Don't get me wrong, I like
the ability to use salt-call to directly execute, I am just missing
a salt-poke method to poke the minion to do the work instead.

Contributor

madduck commented Oct 29, 2012

also sprach Thomas S Hatch notifications@github.com [2012.10.29.0439 +0100]:

I think that the salt-call command not logging at all to a file
should be considered an issue. As for having it communicate to the
running minion, I don't think this is the right move, because when
the salt-minion runs it executes the call itself in a separate
process anyway.

There are other reasons. For instance, I don't think two highstate
runs should happen at the same time, but that can only be ensured if
it all converges in one place.

To the local admin, it doesn't really matter what the site policy is
regarding how salt runs… salt-call, remote execution, it's all the
same. Hence it should all be logged in the same place.

And I am sure there are other reasons. Don't get me wrong, I like
the ability to use salt-call to directly execute, I am just missing
a salt-poke method to poke the minion to do the work instead.

@thatch45

This comment has been minimized.

Show comment
Hide comment
@thatch45

thatch45 Oct 29, 2012

Member

Sounds good, my big concern is the logging issue and I will update salt-call to log and chew on the other possibility.

Member

thatch45 commented Oct 29, 2012

Sounds good, my big concern is the logging issue and I will update salt-call to log and chew on the other possibility.

@madduck

This comment has been minimized.

Show comment
Hide comment
@madduck

madduck Oct 30, 2012

Contributor

Here is another reason why salt-call should be thought of as an
interface to the local salt-minion, if possible:

# salt-call --log-level=info --no-color state.highstate
[INFO    ] Loaded configuration file: /etc/salt/minion
                                                ^^^^^^ ;)
Contributor

madduck commented Oct 30, 2012

Here is another reason why salt-call should be thought of as an
interface to the local salt-minion, if possible:

# salt-call --log-level=info --no-color state.highstate
[INFO    ] Loaded configuration file: /etc/salt/minion
                                                ^^^^^^ ;)
@thatch45

This comment has been minimized.

Show comment
Hide comment
@thatch45

thatch45 Oct 30, 2012

Member

I fail to see why salt-call using the minion config is a justification here, is there some mystic rule I am unaware of?

Member

thatch45 commented Oct 30, 2012

I fail to see why salt-call using the minion config is a justification here, is there some mystic rule I am unaware of?

@madduck

This comment has been minimized.

Show comment
Hide comment
@madduck

madduck Oct 30, 2012

Contributor

also sprach Thomas S Hatch notifications@github.com [2012.10.30.1633 +0100]:

I fail to see why salt-call using the minion config is
a justification here, is there some mystic rule I am unaware of?

No, there is not. It's just that I am scrambling for arguments to
convince you and if two tools use the same configuration file, it's
normal to assume that they work together.

Contributor

madduck commented Oct 30, 2012

also sprach Thomas S Hatch notifications@github.com [2012.10.30.1633 +0100]:

I fail to see why salt-call using the minion config is
a justification here, is there some mystic rule I am unaware of?

No, there is not. It's just that I am scrambling for arguments to
convince you and if two tools use the same configuration file, it's
normal to assume that they work together.

@thatch45

This comment has been minimized.

Show comment
Hide comment
@thatch45

thatch45 Oct 30, 2012

Member

I am just having a hard time understanding why this matters at all, also the fact that salt-call is made to be executed even if the minion is not running so that you don't need to be running a minion to use things like states.

Member

thatch45 commented Oct 30, 2012

I am just having a hard time understanding why this matters at all, also the fact that salt-call is made to be executed even if the minion is not running so that you don't need to be running a minion to use things like states.

@madduck

This comment has been minimized.

Show comment
Hide comment
@madduck

madduck Oct 30, 2012

Contributor

also sprach Thomas S Hatch notifications@github.com [2012.10.30.1723 +0100]:

I am just having a hard time understanding why this matters at
all, also the fact that salt-call is made to be executed even if
the minion is not running so that you don't need to be running
a minion to use things like states.

I am not advocating that this be changed. I just would like to
/also/ have the ability to poke the minion locally.

The sender e-mail address used (github.com@pobox.madduck.net)
is valid and specific to our correspondence. It should not indicate any
affiliation with your organisation.

Die verwendete E-mail-Adressse (github.com@pobox.madduck.net)
ist gültig und spezifisch für unsere Korrespondenz. Sie soll in keiner Weise
auf eine Verbindung mit Ihrer Organisation hindeuten.

Spamtrap: github.com.bogus@pobox.madduck.net

Contributor

madduck commented Oct 30, 2012

also sprach Thomas S Hatch notifications@github.com [2012.10.30.1723 +0100]:

I am just having a hard time understanding why this matters at
all, also the fact that salt-call is made to be executed even if
the minion is not running so that you don't need to be running
a minion to use things like states.

I am not advocating that this be changed. I just would like to
/also/ have the ability to poke the minion locally.

The sender e-mail address used (github.com@pobox.madduck.net)
is valid and specific to our correspondence. It should not indicate any
affiliation with your organisation.

Die verwendete E-mail-Adressse (github.com@pobox.madduck.net)
ist gültig und spezifisch für unsere Korrespondenz. Sie soll in keiner Weise
auf eine Verbindung mit Ihrer Organisation hindeuten.

Spamtrap: github.com.bogus@pobox.madduck.net

@thatch45

This comment has been minimized.

Show comment
Hide comment
@thatch45

thatch45 Oct 30, 2012

Member

ok, that makes more sense, and should be doable. The minion basically does 2 things in the server loop, listen for calls from the master, and check for jobs in the push queue to publish. So we might be able to cleanly add this

Member

thatch45 commented Oct 30, 2012

ok, that makes more sense, and should be doable. The minion basically does 2 things in the server loop, listen for calls from the master, and check for jobs in the push queue to publish. So we might be able to cleanly add this

@madduck

This comment has been minimized.

Show comment
Hide comment
@madduck

madduck Jan 30, 2013

Contributor

Here is one big benefit of salt-call able to work independently of the minion (i.e. what is currently the case): pdb debugging… this would be much more painful with different processes.

Contributor

madduck commented Jan 30, 2013

Here is one big benefit of salt-call able to work independently of the minion (i.e. what is currently the case): pdb debugging… this would be much more painful with different processes.

@rallytime rallytime added the Feature label Sep 30, 2014

@stale stale bot added the stale label Sep 5, 2017

@stale

This comment has been minimized.

Show comment
Hide comment
@stale

stale bot Sep 5, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

stale bot commented Sep 5, 2017

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot closed this Sep 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment