FAQ
So my digging through documentation and source code along with various
attempts hasn't resulted in success, so I'm going to ask here and hope that
someone might know how to do what I'm looking for... :)

I have an application that's using the Salt API to call a custom module on
a minion(s), and currently have code something like the following:

     opts = salt.config.minion_config('/etc/salt.tds/minion') # Custom config
     caller = salt.client.Caller(mopts=opts)
     result = caller.function('publish.full_data', host, cmd, args)

The 'cmd' is an 'install' method in the custom module which is actually
doing some checking and installing (upgrading or downgrading) a given
package. 'args' contains the application name and version (or sometimes
just 'restart' to restart the app - that part actually seems to work okay).

The issue I'm running into is that the actual installation process takes up
to 30 seconds to run, and 'publish.full_data' defaults to a 5 second timeout,
so my result is always an empty dictionary even if the install is successful
because the function() method exits well before the module on the minion
has time to respond. I tried passing a timeout as well, but unfortunately
after digging through the salt.minion.load_args_and_kwargs() method I
found that the 'keywords' value for publish.full_data in 'argspec' is... None.
So I can't actually fix the timeout.

So this leads me to the question: is there another, asynchronous way I can
try to accomplish this? Initially I considered salt.runner.RunnerClient but
then realized that it only can be used on the Salt master, and the appli-
cation using the Salt API exists on a set of client machines (the custom
minion configuration is to allow non-root users to call _only_ the custom
module), so that's out, and I'm not really seeing anything else... help? :)

Thanks in advance.

p.s. In case it matters, using Salt 2014.7.1 both on masters, minions and
     clients.

--
Ken Lareau

--
You received this message because you are subscribed to the Google Groups "Salt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Seth House at Apr 3, 2015 at 10:45 pm
    Hi, Ken. The timeout behavior seems to be working at the CLI but I can
    reproduce what you're seeing with the Python API. I _think_ the
    `function` method is eating the timeout kwarg instead of passing it
    through like it should. Try this instead:

    result = caller.sminion.functions['publish.full_data'](host, cmd,
    args, timeout=15)

    That's working in my local tests. If that works for you as well will
    you please file an issue so we can dive into the missing timeout
    kwarg?
    On Fri, Apr 3, 2015 at 2:32 PM, Ken Lareau wrote:
    So my digging through documentation and source code along with various
    attempts hasn't resulted in success, so I'm going to ask here and hope that
    someone might know how to do what I'm looking for... :)

    I have an application that's using the Salt API to call a custom module on
    a minion(s), and currently have code something like the following:

    opts = salt.config.minion_config('/etc/salt.tds/minion') # Custom config
    caller = salt.client.Caller(mopts=opts)
    result = caller.function('publish.full_data', host, cmd, args)

    The 'cmd' is an 'install' method in the custom module which is actually
    doing some checking and installing (upgrading or downgrading) a given
    package. 'args' contains the application name and version (or sometimes
    just 'restart' to restart the app - that part actually seems to work okay).

    The issue I'm running into is that the actual installation process takes up
    to 30 seconds to run, and 'publish.full_data' defaults to a 5 second timeout,
    so my result is always an empty dictionary even if the install is successful
    because the function() method exits well before the module on the minion
    has time to respond. I tried passing a timeout as well, but unfortunately
    after digging through the salt.minion.load_args_and_kwargs() method I
    found that the 'keywords' value for publish.full_data in 'argspec' is... None.
    So I can't actually fix the timeout.

    So this leads me to the question: is there another, asynchronous way I can
    try to accomplish this? Initially I considered salt.runner.RunnerClient but
    then realized that it only can be used on the Salt master, and the appli-
    cation using the Salt API exists on a set of client machines (the custom
    minion configuration is to allow non-root users to call _only_ the custom
    module), so that's out, and I'm not really seeing anything else... help? :)

    Thanks in advance.

    p.s. In case it matters, using Salt 2014.7.1 both on masters, minions and
    clients.

    --
    Ken Lareau

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ken Lareau at Apr 3, 2015 at 11:05 pm
    Well I'll be a monkey's uncle... that worked beautifully, Seth!
    result = caller.sminion.functions['publish.full_data']('dtdstestone01.*', 'tds.install', ['tdstest', 36], timeout=60)
    result
    {'dtdstestone01.XXXX.com': {'ret': 'Install of app "tdstest", version
    "36" successful'}}

    (I have to set the timeout ridiculously high due to yum sometimes
    taking forever to run 'makecache' and install the package, but it
    will always return when it's done, so most of the time it should
    only take 15-20 seconds, thankfully.)

    That answer was almost painfully obvious when I saw it that
    I'm a bit embarrassed I didn't figure it out sooner! Thank you
    very much, Seth.

    - Ken

    On Fri, Apr 3, 2015 at 3:45 PM, Seth House wrote:
    Hi, Ken. The timeout behavior seems to be working at the CLI but I can
    reproduce what you're seeing with the Python API. I _think_ the
    `function` method is eating the timeout kwarg instead of passing it
    through like it should. Try this instead:

    result = caller.sminion.functions['publish.full_data'](host, cmd,
    args, timeout=15)

    That's working in my local tests. If that works for you as well will
    you please file an issue so we can dive into the missing timeout
    kwarg?
    On Fri, Apr 3, 2015 at 2:32 PM, Ken Lareau wrote:
    So my digging through documentation and source code along with various
    attempts hasn't resulted in success, so I'm going to ask here and hope that
    someone might know how to do what I'm looking for... :)

    I have an application that's using the Salt API to call a custom module on
    a minion(s), and currently have code something like the following:

    opts = salt.config.minion_config('/etc/salt.tds/minion') # Custom config
    caller = salt.client.Caller(mopts=opts)
    result = caller.function('publish.full_data', host, cmd, args)

    The 'cmd' is an 'install' method in the custom module which is actually
    doing some checking and installing (upgrading or downgrading) a given
    package. 'args' contains the application name and version (or sometimes
    just 'restart' to restart the app - that part actually seems to work okay).

    The issue I'm running into is that the actual installation process takes up
    to 30 seconds to run, and 'publish.full_data' defaults to a 5 second timeout,
    so my result is always an empty dictionary even if the install is successful
    because the function() method exits well before the module on the minion
    has time to respond. I tried passing a timeout as well, but unfortunately
    after digging through the salt.minion.load_args_and_kwargs() method I
    found that the 'keywords' value for publish.full_data in 'argspec' is... None.
    So I can't actually fix the timeout.

    So this leads me to the question: is there another, asynchronous way I can
    try to accomplish this? Initially I considered salt.runner.RunnerClient but
    then realized that it only can be used on the Salt master, and the appli-
    cation using the Salt API exists on a set of client machines (the custom
    minion configuration is to allow non-root users to call _only_ the custom
    module), so that's out, and I'm not really seeing anything else... help? :)

    Thanks in advance.

    p.s. In case it matters, using Salt 2014.7.1 both on masters, minions and
    clients.

    --
    Ken Lareau

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Ken Lareau

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Seth House at Apr 4, 2015 at 2:32 am

    On Fri, Apr 3, 2015 at 5:05 PM, Ken Lareau wrote:
    That answer was almost painfully obvious when I saw it that
    I'm a bit embarrassed I didn't figure it out sooner!
    I wouldn't put this one on you at all. That interface is a bit
    inconsistent and a bit outdated. I just submitted this pull req to get
    it cleaned up and consistent with the other Salt interfaces.

    https://github.com/saltstack/salt/pull/22355

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ken Lareau at Apr 6, 2015 at 3:01 am

    On Fri, Apr 3, 2015 at 7:32 PM, Seth House wrote:
    On Fri, Apr 3, 2015 at 5:05 PM, Ken Lareau wrote:
    That answer was almost painfully obvious when I saw it that
    I'm a bit embarrassed I didn't figure it out sooner!
    I wouldn't put this one on you at all. That interface is a bit
    inconsistent and a bit outdated. I just submitted this pull req to get
    it cleaned up and consistent with the other Salt interfaces.

    https://github.com/saltstack/salt/pull/22355
    Cool, that would definitely be a nice addition!


    --
    Ken Lareau

    --
    You received this message because you are subscribed to the Google Groups "Salt-users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsalt-users @
postedApr 3, '15 at 8:32p
activeApr 6, '15 at 3:01a
posts5
users2

2 users in discussion

Ken Lareau: 3 posts Seth House: 2 posts

People

Translate

site design / logo © 2021 Grokbase