[salt-users] [Newbie question] Using cmd.retcode in a SLS file

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, [email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

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, [email protected]
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

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, [email protected]
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
[email protected].
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 [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

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, <[email protected] <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, [email protected]
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
[email protected] <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 [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

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 [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

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 [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

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 [email protected].
For more options, visit https://groups.google.com/d/optout.

reply | permalink

group	salt-users @
posted	Nov 3, '14 at 2:41p
active	Nov 5, '14 at 6:13p
posts	8
users	2

responses	expanded	Hotkey: s
font	variable	Hotkey: f
user style	avatars	Hotkey: a

[salt-users] [Newbie question] Using cmd.retcode in a SLS file

Search Discussions

Related Discussions

2 users in discussion