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

Make jobs.list_jobs show the same format for remote job-caches as for local cache #23131

Closed
bemeyert opened this issue Apr 28, 2015 · 9 comments
Labels
Bug broken, incorrect, or confusing behavior P2 Priority 2 Platform Relates to OS, containers, platform-based utilities like FS, system based apps Returners severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around stale
Milestone

Comments

@bemeyert
Copy link

Hi all,

It would be very useful to have the same format in jobs.list_jobs for all returners. Under version 2014.7.5 the output of jobs.list_jobs with a local job-cache looks like this:

[root@salt salt]# salt-run jobs.list_jobs
20150428110219511091:
----------
Arguments:
    - fuba.projects.project
Function:
    state.sls
StartTime:
    2015, Apr 28 11:02:19.511091
Target:
    fuba-lamp-dev-01.office.com
Target-type:
    glob
User:
    root

and the output with Redis or MySQL as returner just shows the JIDs:

[root@salt salt]# salt-run jobs.list_jobs
- 20150428145221306767
- 20150428145715408562

One can see that the output with the local cache is much more useful.

Cheers

@basepi
Copy link
Contributor

basepi commented Apr 28, 2015

Agreed. There are a number of places that are not as standardized as they should be with regards to returners. Thanks for filing this!

@basepi basepi added Bug broken, incorrect, or confusing behavior severity-low 4th level, cosemtic problems, work around exists P2 Priority 2 Returners labels Apr 28, 2015
@basepi basepi added this to the Approved milestone Apr 28, 2015
@jfindlay jfindlay added Core relates to code central or existential to Salt and removed Core relates to code central or existential to Salt labels May 26, 2015
@bemeyert
Copy link
Author

@whiteinge According to Lothiraldan/saltpad#57 (comment) I thought I add you to this issue.

@whiteinge
Copy link
Contributor

Thank you. I indeed missed this one.

@whiteinge whiteinge added severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around and removed severity-low 4th level, cosemtic problems, work around exists labels May 29, 2015
@whiteinge
Copy link
Contributor

Bumping the severity because API changes like this will break people's tools that use Salt programatically via Python or via salt-api.

@arthurzenika
Copy link
Contributor

we're interrested in this fix too.

@kerncore
Copy link
Contributor

Very important to this fix it
Thanks

@bemeyert
Copy link
Author

Any news on this front? Cheers

@basepi basepi added Platform Relates to OS, containers, platform-based utilities like FS, system based apps ZRELEASED - Boron and removed Core relates to code central or existential to Salt labels Aug 25, 2015
@basepi
Copy link
Contributor

basepi commented Aug 25, 2015

Unfortunately no, but I did label it for consideration for the next release.

@stale
Copy link

stale bot commented May 19, 2018

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 added the stale label May 19, 2018
@stale stale bot closed this as completed May 26, 2018
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 P2 Priority 2 Platform Relates to OS, containers, platform-based utilities like FS, system based apps Returners severity-medium 3rd level, incorrect or bad functionality, confusing and lacks a work around stale
Projects
None yet
Development

No branches or pull requests

7 participants