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.

Sign up for GitHub

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

Jump to bottom

Improvements to the daemon-managed WorkChains needed #318

Closed
giovannipizzi opened this issue Jan 17, 2017 · 6 comments
Closed

Improvements to the daemon-managed WorkChains needed #318

giovannipizzi opened this issue Jan 17, 2017 · 6 comments
Assignees
@muhrin @sphuber
Labels
topic/verdi topic/workflows
Milestone
v1.0.0

Comments

@giovannipizzi
Copy link
Member

We need to give the user the possibility to easily and clearly understand what the daemon is doing w.r.t. WorkChains.
Now, the only simple tool is verdi work list, but has some shortcomings (shows also JobCalculations, is not sorted, limits by default the number of results, does not give a clear information on what the different WorkCalculations are, ...).
Moreover, there should be a way to show only currently running WorkChains, by default (paralleling what verdi calculation list does).
@giovannipizzi
Copy link
Member Author

I'm going to create a branch now and already commit a partial fix to the first part. I will branch off the tutorial_ts_jan branch, so that if modifications are minor, we can put the fixes in that branch.

giovannipizzi added a commit that referenced this issue Jan 17, 2017
@giovannipizzi
First fixes for #318 to the verdi work list:
b1d3520 
- properly use the command line parameters (don't use sys.argv)
- remove default limit
- set by default order to be 'ascending' on ctime (internally:
  descending, then list is reverted, to take care of the 'limits'
  if specified - probably though it is not very efficient for
  long lists)
- replaced 'type' with the process label in the output table
- show only WorkCalculation rather than any Calculation
- put the QueryBuilder .order_by() after append, otherwise
  QB complains
@giovannipizzi
Copy link
Member Author

giovannipizzi commented Jan 17, 2017 •
edited
Loading

We need now a way to know

  • if a WorkChain is running (and therefore show it) or not (and by default hide it). Is there such a field that we can query for?
  • also, if would be good to know if the WorkChain was launched by the user, or it is a subWorkChain, so that by default we show only user WorkChains (and possibly subworkchains in a tree structure, like for the old workflows). Probably for this we just need to inspect the 'call' links?
  • Also (as Put in verdi command to show steps completed by WorkChains #226 stated) we should also show at which step we are in a WorkChain (also this was visible in the old verdi workflow list

@giovannipizzi giovannipizzi mentioned this issue Jan 19, 2017
Closed
@giovannipizzi giovannipizzi added this to the Feb17 release (v0.8.0) milestone Feb 27, 2017
sphuber pushed a commit that referenced this issue Feb 28, 2017
@giovannipizzi @sphuber
First fixes for #318 to the verdi work list:
8823cbb 
- properly use the command line parameters (don't use sys.argv)
- remove default limit
- set by default order to be 'ascending' on ctime (internally:
  descending, then list is reverted, to take care of the 'limits'
  if specified - probably though it is not very efficient for
  long lists)
- replaced 'type' with the process label in the output table
- show only WorkCalculation rather than any Calculation
- put the QueryBuilder .order_by() after append, otherwise
  QB complains
@sphuber sphuber modified the milestones: Pre-1.0 release, Feb17 release (v0.8.0) Mar 15, 2017
@sphuber
Copy link
Contributor

sphuber commented Mar 15, 2017

Changed the milestone to pre-1.0 release because more work on #318 needs to be done.

@sphuber
Copy link
Contributor

sphuber commented Aug 16, 2017

I was trying to implement the --project option that exists for verdi calculation list in order to be able to specify which attributes the user wants projected, but I cannot figure out how to make this work in click. It supports multivalue options, but then the exact number needs to be specified through nargs. I cannot find anything on how to enable an unknown number of options.

@broeder-j
Copy link
Member

broeder-j commented Oct 17, 2017 •
edited
Loading

Yes this is true. One solution I can think of is parsing a string like --project 'pk uuid time'? which you will split then for spaces and create the project from the resulting list. this would also allow for projecting several times the same thing --project 'pk uuid time pk label', which is currently not possible.

@sphuber sphuber mentioned this issue Nov 2, 2017
Merged
@sphuber
Copy link
Contributor

sphuber commented Nov 2, 2017

Fixed in PR #888
The project option was partially fixed by @vdikan in a PR into develop

@sphuber sphuber closed this as completed Nov 2, 2017
@sphuber sphuber modified the milestones: pre-1.0 release, v1.0.0 May 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@muhrin muhrin

@sphuber sphuber

Labels
topic/verdi topic/workflows
Projects
None yet
Milestone
v1.0.0
Development

No branches or pull requests
4 participants
@muhrin @sphuber @giovannipizzi @broeder-j