-
Notifications
You must be signed in to change notification settings - Fork 13
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
Expose execution status as virtual property on job resource - teraslice api #3770
Comments
In teraslice-cli we give the job a registered status if there isn't an execution
|
I talked with Kimbro about this a little bit today and he suggested if we chose to go this route we should probably make a distinction between this "virtual property" (if there's a word for this someone let me know) and the other properties. That way if we start extending the use of this technique, they will all be grouped together. So maybe something like "_ex": {
"status": "running"
} |
Perhaps the extra property would only be included if |
This PR: only added the functionality to |
This PR makes the following changes: ## New Features - Adds a feature introduced on #3792 into the `v1/jobs` endpoint - Now you can list several jobs with their associated ex information in one api call ## Documentation - Updated `management api` docs to reflect changes to `v1/jobs` endpoint ## Bumps - **teraslice** from `v2.6.1` to `v2.6.2` Ref to issue #3770
Would it make sense to expose the
ex._status
property as.status
or perhaps.exStatus
on the Teraslice job API resources?I would expect this to be implemented by making a request to see if a current ex exists for the job, if so, return it's status, if not, return ... 🤷
This would simplify a lot of client side logic. I am not sure what the downsides would be. The extra DB requests of course. Anything else?
See also #535 , this is effectively a duplicate of that.
The text was updated successfully, but these errors were encountered: