FAQ
Hi,

I'd like to write a SLS for following situation.I want to call 'svn info'
for creating the default subversion configuration in user land. When 'svn
info' runs outside a subversion project, it will return error code 1. This
error code should be ignored. I found the execution module cmd.retcode that
can ignore return codes. So my code snippet for the SLS looks like the
following one

svn_config:
   module.run:
     - name: cmd.retcode
     - cmd: 'svn info'
     - ignore_retcode: True

Unfortunately, calling this state failed with the error message

                 ID: svn_config
        Function: module.run
            Name: cmd.retcode
           Result: False
      Comment: An exception occurred in this state: Traceback (most recent
call last):
                 File "/usr/lib/python2.7/dist-packages/salt/state.py", line
1382, in call
                   **cdata['kwargs'])
                 File
"/usr/lib/python2.7/dist-packages/salt/states/module.py", line 203, in run
                   if ret['changes'].get('ret', {}).get('retcode', 0) != 0:
               AttributeError: 'int' object has no attribute 'get'
      Changes:

When I call cmd.retcode directly (salt-call cmd.retcode 'svn info'
ignore_retcode=True), everything is alright. Do I use module.run wrong?

BTW I use Salt version 2014.1.13 on an Ubuntu 14.04 via Vagrant (version
1.6.3)

Best regards,

Sandra

--
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

  • Warren Turkal at Nov 3, 2014 at 4:52 pm
    I really don't completely understand your use case, so I hope my
    suggestions are helpful.

    Rather than the module.run state, try cmd.run state. Module.run is tricky
    because it it a raw wrapper around execution modules. Typically, a state
    module wraps one or more execution module functions and has additional
    logic on top of that.

    Also, what directory are you running the command in? The cmd.run state
    function takes a cwd parameter to specify the working directory. If you
    have multiple directories that you need to run the command in, you can have
    multiple states in your sls file.

    wt

    On Monday, November 3, 2014 6:41:15 AM UTC-8, sandra....@googlemail.com
    wrote:
    Hi,

    I'd like to write a SLS for following situation.I want to call 'svn info'
    for creating the default subversion configuration in user land. When 'svn
    info' runs outside a subversion project, it will return error code 1. This
    error code should be ignored. I found the execution module cmd.retcode that
    can ignore return codes. So my code snippet for the SLS looks like the
    following one

    svn_config:
    module.run:
    - name: cmd.retcode
    - cmd: 'svn info'
    - ignore_retcode: True

    Unfortunately, calling this state failed with the error message

    ID: svn_config
    Function: module.run
    Name: cmd.retcode
    Result: False
    Comment: An exception occurred in this state: Traceback (most recent
    call last):
    File "/usr/lib/python2.7/dist-packages/salt/state.py",
    line 1382, in call
    **cdata['kwargs'])
    File
    "/usr/lib/python2.7/dist-packages/salt/states/module.py", line 203, in run
    if ret['changes'].get('ret', {}).get('retcode', 0) != 0:
    AttributeError: 'int' object has no attribute 'get'
    Changes:

    When I call cmd.retcode directly (salt-call cmd.retcode 'svn info'
    ignore_retcode=True), everything is alright. Do I use module.run wrong?

    BTW I use Salt version 2014.1.13 on an Ubuntu 14.04 via Vagrant (version
    1.6.3)

    Best regards,

    Sandra
    --
    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.
  • Sandra Kosmalla at Nov 3, 2014 at 7:15 pm
    Thank you for your answer.

    Cmd.run state can't match my use case, because cmd.run accepts only return
    code 0 by the command. In my use case I want run 'svn info' for setting up
    the subversion client configuration with the default values, but the return
    code of it is 1. So I search for a salt equivalent to the following puppet
    snippet

       exec { 'svn info':
         user => 'vagrant',
         path => '/usr/bin',
         returns => 1,
       }

    Am Montag, 3. November 2014 17:52:08 UTC+1 schrieb Warren Turkal:
    I really don't completely understand your use case, so I hope my
    suggestions are helpful.

    Rather than the module.run state, try cmd.run state. Module.run is tricky
    because it it a raw wrapper around execution modules. Typically, a state
    module wraps one or more execution module functions and has additional
    logic on top of that.

    Also, what directory are you running the command in? The cmd.run state
    function takes a cwd parameter to specify the working directory. If you
    have multiple directories that you need to run the command in, you can have
    multiple states in your sls file.

    wt

    On Monday, November 3, 2014 6:41:15 AM UTC-8, sandra....@googlemail.com
    wrote:
    Hi,

    I'd like to write a SLS for following situation.I want to call 'svn info'
    for creating the default subversion configuration in user land. When 'svn
    info' runs outside a subversion project, it will return error code 1. This
    error code should be ignored. I found the execution module cmd.retcode that
    can ignore return codes. So my code snippet for the SLS looks like the
    following one

    svn_config:
    module.run:
    - name: cmd.retcode
    - cmd: 'svn info'
    - ignore_retcode: True

    Unfortunately, calling this state failed with the error message

    ID: svn_config
    Function: module.run
    Name: cmd.retcode
    Result: False
    Comment: An exception occurred in this state: Traceback (most recent
    call last):
    File "/usr/lib/python2.7/dist-packages/salt/state.py",
    line 1382, in call
    **cdata['kwargs'])
    File
    "/usr/lib/python2.7/dist-packages/salt/states/module.py", line 203, in run
    if ret['changes'].get('ret', {}).get('retcode', 0) != 0:
    AttributeError: 'int' object has no attribute 'get'
    Changes:

    When I call cmd.retcode directly (salt-call cmd.retcode 'svn info'
    ignore_retcode=True), everything is alright. Do I use module.run wrong?

    BTW I use Salt version 2014.1.13 on an Ubuntu 14.04 via Vagrant (version
    1.6.3)

    Best regards,

    Sandra
    --
    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.
  • Warren Turkal at Nov 3, 2014 at 10:30 pm
    Cmd.run can run any shell command. For example, you could do:

    blah_cmd:
       cmd.run:
         - name: "svn info || true"

    That would make sure that there is always a 0 return code. Also, if you're
    doing something more complex, cmd.script may be even more apropos.

    wt
    On Mon, Nov 3, 2014 at 11:15 AM, wrote:


    Thank you for your answer.

    Cmd.run state can't match my use case, because cmd.run accepts only return
    code 0 by the command. In my use case I want run 'svn info' for setting up
    the subversion client configuration with the default values, but the return
    code of it is 1. So I search for a salt equivalent to the following puppet
    snippet

    exec { 'svn info':
    user => 'vagrant',
    path => '/usr/bin',
    returns => 1,
    }

    Am Montag, 3. November 2014 17:52:08 UTC+1 schrieb Warren Turkal:
    I really don't completely understand your use case, so I hope my
    suggestions are helpful.

    Rather than the module.run state, try cmd.run state. Module.run is tricky
    because it it a raw wrapper around execution modules. Typically, a state
    module wraps one or more execution module functions and has additional
    logic on top of that.

    Also, what directory are you running the command in? The cmd.run state
    function takes a cwd parameter to specify the working directory. If you
    have multiple directories that you need to run the command in, you can have
    multiple states in your sls file.

    wt

    On Monday, November 3, 2014 6:41:15 AM UTC-8, sandra....@googlemail.com
    wrote:
    Hi,

    I'd like to write a SLS for following situation.I want to call 'svn
    info' for creating the default subversion configuration in user land. When
    'svn info' runs outside a subversion project, it will return error code 1.
    This error code should be ignored. I found the execution module cmd.retcode
    that can ignore return codes. So my code snippet for the SLS looks like the
    following one

    svn_config:
    module.run:
    - name: cmd.retcode
    - cmd: 'svn info'
    - ignore_retcode: True

    Unfortunately, calling this state failed with the error message

    ID: svn_config
    Function: module.run
    Name: cmd.retcode
    Result: False
    Comment: An exception occurred in this state: Traceback (most
    recent call last):
    File "/usr/lib/python2.7/dist-packages/salt/state.py",
    line 1382, in call
    **cdata['kwargs'])
    File "/usr/lib/python2.7/dist-
    packages/salt/states/module.py", line 203, in run
    if ret['changes'].get('ret', {}).get('retcode', 0) !=
    0:
    AttributeError: 'int' object has no attribute 'get'
    Changes:

    When I call cmd.retcode directly (salt-call cmd.retcode 'svn info'
    ignore_retcode=True), everything is alright. Do I use module.run wrong?

    BTW I use Salt version 2014.1.13 on an Ubuntu 14.04 via Vagrant (version
    1.6.3)

    Best regards,

    Sandra

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/jsx9XT7D78w/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.


    --
    Warren Turkal

    --
    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.
  • Sandra Kosmalla at Nov 4, 2014 at 9:40 am
    Thanks Warren. Yes, it would be run wirth cmd.run, but it looks like a
    workaround for me. But I will have a deeper look on cmd.scripts.

    I find out that my snippet runs with Salt in version 2014.1.11 like
    expected, but in version 2014.1.13 (current version) the script produces
    the above error message. Is it possible that it is a bug?

    A common question about module.run. Is it the only way to use execution
    modules in a SLS file?

    Am Montag, 3. November 2014 23:30:46 UTC+1 schrieb Warren Turkal:
    Cmd.run can run any shell command. For example, you could do:

    blah_cmd:
    cmd.run:
    - name: "svn info || true"

    That would make sure that there is always a 0 return code. Also, if you're
    doing something more complex, cmd.script may be even more apropos.

    wt

    On Mon, Nov 3, 2014 at 11:15 AM, <sandra....@googlemail.com <javascript:>>
    wrote:
    Thank you for your answer.

    Cmd.run state can't match my use case, because cmd.run accepts only
    return code 0 by the command. In my use case I want run 'svn info' for
    setting up the subversion client configuration with the default values, but
    the return code of it is 1. So I search for a salt equivalent to the
    following puppet snippet

    exec { 'svn info':
    user => 'vagrant',
    path => '/usr/bin',
    returns => 1,
    }

    Am Montag, 3. November 2014 17:52:08 UTC+1 schrieb Warren Turkal:
    I really don't completely understand your use case, so I hope my
    suggestions are helpful.

    Rather than the module.run state, try cmd.run state. Module.run is
    tricky because it it a raw wrapper around execution modules. Typically, a
    state module wraps one or more execution module functions and has
    additional logic on top of that.

    Also, what directory are you running the command in? The cmd.run state
    function takes a cwd parameter to specify the working directory. If you
    have multiple directories that you need to run the command in, you can have
    multiple states in your sls file.

    wt

    On Monday, November 3, 2014 6:41:15 AM UTC-8, sandra....@googlemail.com
    wrote:
    Hi,

    I'd like to write a SLS for following situation.I want to call 'svn
    info' for creating the default subversion configuration in user land. When
    'svn info' runs outside a subversion project, it will return error code 1.
    This error code should be ignored. I found the execution module cmd.retcode
    that can ignore return codes. So my code snippet for the SLS looks like the
    following one

    svn_config:
    module.run:
    - name: cmd.retcode
    - cmd: 'svn info'
    - ignore_retcode: True

    Unfortunately, calling this state failed with the error message

    ID: svn_config
    Function: module.run
    Name: cmd.retcode
    Result: False
    Comment: An exception occurred in this state: Traceback (most
    recent call last):
    File "/usr/lib/python2.7/dist-packages/salt/state.py",
    line 1382, in call
    **cdata['kwargs'])
    File "/usr/lib/python2.7/dist-
    packages/salt/states/module.py", line 203, in run
    if ret['changes'].get('ret', {}).get('retcode', 0) !=
    0:
    AttributeError: 'int' object has no attribute 'get'
    Changes:

    When I call cmd.retcode directly (salt-call cmd.retcode 'svn info'
    ignore_retcode=True), everything is alright. Do I use module.run wrong?

    BTW I use Salt version 2014.1.13 on an Ubuntu 14.04 via Vagrant
    (version 1.6.3)

    Best regards,

    Sandra

    --
    You received this message because you are subscribed to a topic in the
    Google Groups "Salt-users" group.
    To unsubscribe from this topic, visit
    https://groups.google.com/d/topic/salt-users/jsx9XT7D78w/unsubscribe.
    To unsubscribe from this group and all its topics, send an email to
    salt-users+...@googlegroups.com <javascript:>.
    For more options, visit https://groups.google.com/d/optout.


    --
    Warren Turkal
    --
    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.
  • Warren Turkal at Nov 4, 2014 at 11:15 pm

    On Tue, Nov 4, 2014 at 1:40 AM, wrote:

    Thanks Warren. Yes, it would be run wirth cmd.run, but it looks like a
    workaround for me.
    If you really don't care about the return code, it seems fine.

    FWIW, you might be able to avoid forking for /bin/true by doing the
    following (untested): "svn info && exit 0".

    But I will have a deeper look on cmd.scripts.
    >

    Cmd.script will download a file from some source and run it as a script.

    I find out that my snippet runs with Salt in version 2014.1.11 like
    expected, but in version 2014.1.13 (current version) the script produces
    the above error message. Is it possible that it is a bug?
    The change in behavior may be a bug.

    A common question about module.run. Is it the only way to use execution
    modules in a SLS file?
    Module.run is the way to run execution module functions from a state.
    However, states require specific information to be returned so that they
    can report things like changes (for requisites). Execution modules, in most
    cases, are not meant to be stateful, and one should be very careful when
    using them as such. The cmd.run may be a thin enough wrapper that it
    doesn't matter, but in that case I would still prefer to use the state
    module over module.run on the exec module.

    wt

    --
    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.
  • Sandra Kosmalla at Nov 5, 2014 at 9:57 am

    Thanks Warren. Yes, it would be run wirth cmd.run, but it looks like a
    workaround for me.
    If you really don't care about the return code, it seems fine.
    Yes, in this case, you are absolutely right. I was persistent, because I
    had some use cases in my head in which the return code could be important.

    I find out that my snippet runs with Salt in version 2014.1.11 like
    expected, but in version 2014.1.13 (current version) the script produces
    the above error message. Is it possible that it is a bug?
    The change in behavior may be a bug.
    I opened an issue about this change in behaviour
    (https://github.com/saltstack/salt/issues/17182).

    A common question about module.run. Is it the only way to use execution
    modules in a SLS file?
    Module.run is the way to run execution module functions from a state.
    However, states require specific information to be returned so that they
    can report things like changes (for requisites). Execution modules, in most
    cases, are not meant to be stateful, and one should be very careful when
    using them as such. The cmd.run may be a thin enough wrapper that it
    doesn't matter, but in that case I would still prefer to use the state
    module over module.run on the exec module.
    Thanks for the explanation. It helps a lot for my understanding.

    --
    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.
  • Warren Turkal at Nov 5, 2014 at 6:13 pm

    On Wed, Nov 5, 2014 at 1:57 AM, wrote:
    Thanks Warren. Yes, it would be run wirth cmd.run, but it looks like a
    workaround for me.
    If you really don't care about the return code, it seems fine.
    Yes, in this case, you are absolutely right. I was persistent, because I
    had some use cases in my head in which the return code could be important.
    Well, I would just say don't overengineer the solution. If the command
    you're using has the semantics cmd.run needs, use it. If it doesn't, write
    a script and use cmd.script instead. If you're looking to communicate
    changes to other states, look into the cmd.wait_* variants.

    I find out that my snippet runs with Salt in version 2014.1.11 like
    expected, but in version 2014.1.13 (current version) the script produces
    the above error message. Is it possible that it is a bug?
    The change in behavior may be a bug.
    I opened an issue about this change in behaviour (
    https://github.com/saltstack/salt/issues/17182).
    Cool. Finding subtle bugs and fixing them is important.

    A common question about module.run. Is it the only way to use execution
    modules in a SLS file?
    Module.run is the way to run execution module functions from a state.
    However, states require specific information to be returned so that they
    can report things like changes (for requisites). Execution modules, in most
    cases, are not meant to be stateful, and one should be very careful when
    using them as such. The cmd.run may be a thin enough wrapper that it
    doesn't matter, but in that case I would still prefer to use the state
    module over module.run on the exec module.
    Thanks for the explanation. It helps a lot for my understanding.
    No prob.

    wt
    --
    Warren Turkal

    --
    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 @
postedNov 3, '14 at 2:41p
activeNov 5, '14 at 6:13p
posts8
users2

2 users in discussion

Sandra Kosmalla: 4 posts Warren Turkal: 4 posts

People

Translate

site design / logo © 2022 Grokbase