Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot get highstate style output with salt.states.tomcat.war_deployed #12840

Closed
perdurabo93 opened this issue May 16, 2014 · 4 comments · Fixed by #12844
Closed

Cannot get highstate style output with salt.states.tomcat.war_deployed #12840

perdurabo93 opened this issue May 16, 2014 · 4 comments · Fixed by #12844
Labels
Bug broken, incorrect, or confusing behavior help-wanted Community help is needed to resolve this severity-low 4th level, cosemtic problems, work around exists
Milestone

Comments

@perdurabo93
Copy link
Contributor

I'm running salt 2014.1.3 (I cant use 2014.1.4 because of #12699). I've got a simple state that deploys a war file to a local tomcat server like so:

MyApp:
  tomcat:
    - war_deployed
    - name: /MyApp
    - war: salt://workspace/myapp/target/Myapp-1.0.0.war

When I attempt to deploy it after that version is already deployed, I get an output like this from salt-call -l debug state.sls myapp , which is as expected:

[DEBUG   ] Loaded no_out as virtual quiet
[DEBUG   ] Loaded json_out as virtual json
[DEBUG   ] Loaded yaml_out as virtual yaml
[DEBUG   ] Loaded pprint_out as virtual pprint
local:
----------
          ID: MyApp
    Function: tomcat.war_deployed
        Name: /MyApp
      Result: True
     Comment: /MyApp in version MyApp-1.0.0 is already deployed
     Changes:   

Summary
------------
Succeeded: 1
Failed:    0
------------
Total:     1

However, when I do a fresh deploy, theres a python error and the output goes from the well formatted "highstate" style, to a very ugly "pprint" style:

[DEBUG   ] Loaded no_out as virtual quiet
[DEBUG   ] Loaded json_out as virtual json
[DEBUG   ] Loaded yaml_out as virtual yaml
[DEBUG   ] Loaded pprint_out as virtual pprint
[DEBUG   ] Loaded no_out as virtual quiet
[DEBUG   ] Loaded json_out as virtual json
[DEBUG   ] Loaded yaml_out as virtual yaml
[DEBUG   ] Loaded pprint_out as virtual pprint
[DEBUG   ] Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/salt/output/__init__.py", line 35, in display_output
    display_data = get_printout(out, opts)(data).rstrip()
  File "/usr/lib/python2.6/site-packages/salt/output/highstate.py", line 44, in output
    return _format_host(host, hostdata)[0]
  File "/usr/lib/python2.6/site-packages/salt/output/highstate.py", line 128, in _format_host
    comment = ret['comment'].join(' ').replace('\n',
AttributeError: 'dict' object has no attribute 'join'

[DEBUG   ] Loaded no_out as virtual quiet
[DEBUG   ] Loaded json_out as virtual json
[DEBUG   ] Loaded yaml_out as virtual yaml
[DEBUG   ] Loaded pprint_out as virtual pprint
              ----------
              local:
                  ----------
                  tomcat_|-MyApp_|-/MyApp_|-war_deployed:
                      ----------
                      __run_num__:
                          0
                      changes:
                          ----------
                          deploy:
                              deployed /MyApp in version MyApp-1.0.0
                      comment:
                          ----------
                          fullname:
                              MyApp##MyApp-1.0.0
                          mode:
                              running
                          sessions:
                              0
                          version:
                              MyApp-1.0.0
                      name:
                          /MyApp
                      result:
                          True

This happens even when I invoke the state with "--out=highstate".

@basepi
Copy link
Contributor

basepi commented May 16, 2014

It appears that that state is erroneously putting a dictionary in the Comment field on successful runs. The highstate outputter is hitting an exception as a result and we're falling back on the default outputter. Thanks for the report, we'll get this fixed.

@basepi
Copy link
Contributor

basepi commented May 16, 2014

I've fixed the traceback, so the highstate outputter should start working again for this state. But it won't be especially pretty, as the 'Comment' is supposed to be a string, and apparently the author made it a dict in some cases.

@perdurabo93
Copy link
Contributor Author

While we're altering states/tomcat.py, can we get a "force=True" option added to the salt.states.tomcat.war_deployed to match the same functionality in salt.modules.tomcat.deploy_war?

@basepi
Copy link
Contributor

basepi commented May 16, 2014

I did not actually modify tomcat.py. I just added logic to the highstate outputter to allow for dictionaries in the comment field.

Would you mind opening another issue for that feature request, @perdurabo93? Sounds like it would be straightforward to add, but I don't want to forget about it.

perdurabo93 added a commit to perdurabo93/salt that referenced this issue May 19, 2014
-Added "force" (default false) option commensurate with force option in salt.modules.tomcat.deploy_war to allow forced deployment of a .war even if the version strings match.  
-Forced successful deploy comment to be a string instead of dict to compensate for saltstack#12840
basepi pushed a commit that referenced this issue Jun 25, 2014
-Added "force" (default false) option commensurate with force option in salt.modules.tomcat.deploy_war to allow forced deployment of a .war even if the version strings match.
-Forced successful deploy comment to be a string instead of dict to compensate for #12840
Conflicts:
	salt/states/tomcat.py
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug broken, incorrect, or confusing behavior help-wanted Community help is needed to resolve this severity-low 4th level, cosemtic problems, work around exists
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants