Re: Any news on Tasks in CF Diego?
Hi Andreas,toggle quoted message Show quoted text
This is a lot, but I’ll try my best to help. I encourage you to stop by our
 Slack channel anytime for a quick chat.
1. The V3 Task resource should eventually end up in either
SUCCEEDED or FAILED
state. If the state is FAILED, the result.failure_reason will have a human
readable message, e.g. "Exited with status 1”. Task logs will appear in
the log stream of the app. Otherwise, state is left up to the developer.
2. I think this is the same question and answer as #1. If not, maybe
let’s chat in Slack and update this thread.
3. I think you are asking about the “V3 CLI Plugin”. This was only
intended to help developers validate the API, and is definitely not
full-featured. We are working with the CLI team to properly expose a
coherent Tasks UX.
4. The Task Completion Callback URL is an internal Diego Tasks feature
and is not exposed to the enduser.
As for when the Tasks feature will be ready to use, we are working very
closely with the CLI team to expose an MVP of Tasks. Aside from a few minor
changes, the API in CF-245 appears to be supporting this effort.
Product Manager - Cloud Foundry API
Pivotal Software, Inc.
On October 20, 2016 at 4:45:46 AM, Andreas Mueller (andr.mueller(a)sap.com)
we at SAP are very interested in the new task feature, because we currently
run some dummy/fake apps, in order to simulate task-like behavior, which
includes some cumbersome app log parsing. The promises of the tasks are
exactly what we are looking for, since the starter of the task would just
like to see the result of the task action in some convenient and easy to
Unfortunately we currently know of a number of older and newer resources
(URLs) with information on the task topic, which do not give much
information on the details of the result handling and seem to even be
slightly contradicting in some low level details.
As a starting point, it would be good to know the most recent official
documentation on the tasks (for the task implementor and consumer).
To shortly summarize, our most important questions from task implementation
and consumption perspective are:
1) How does the task implementation provide its result - either through
process exit code and stderr/out or via tracing (+ optional/internal result
file)? Is there some definite contract or at least best-practice for the
task implementation side?
2) How does the infrastructure collect the task result and especially how
is it exposed to the consumer? In the V3 API docu there’s just a result
JSON object, with only one “failure_reason” property. We’d also expect the
process exit code and maybe stdout/err to be part of the result JSON. Or in
case the (optional) ResultFile and callback URL are the way to go, there
should be some env var exposed to the task implementation, so that one
knows to which file the result data shall be written.
3) It seems like the result from the V3 REST API is not exposed via the V3
tasks client command (at least in its current state)?
4) Is the “Task Completion Callback URL” mechanism that is mentioned in
several sources only intended for internal use by client implementations,
or also for external consumers?
It would also be interesting, when the tasks will be ready to use.
In the talk on V3 given on European CF Summit (in Sept. in Frankfurt) the
following statement on tasks was given ( – slides 46/47):
“When? Very soon (~ next few weeks)”
I’ll add some more detailed observations about the potential result handing
as a second post.
Thanks a lot and kind regards,
Andreas Mueller – SAP SE