Re: Any news on Tasks in CF Diego?
Koper, Dies <diesk@...>
If you’re interested in the CLI UX, refer to the stories in the following epic:
In this iteration, there is no CLI command to retrieve the logs of certain task – mainly because in the log stream we have no identifier unique to a single task.
Cloud Foundry Product Manager - CLI
From: Nicholas Calugar [mailto:ncalugar(a)pivotal.io]
Sent: Saturday, October 22, 2016 12:12 PM
To: Andreas Mueller; Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: Any news on Tasks in CF Diego?
My apologies, I didn’t intend to imply that app logs were the only channel for the task starter to consume the task results. The V3 Task resource will contain the result in the form of state of SUCCEEDED or FAILED. What I meant by, "state is left up to the developer”, is the task code should offload anything that needs persisted from the task run. For example, the task could stream data to a service, write to a database, write a file to a blobstore, etc. The platform is just responsible for running the task and logs shouldn’t be relied upon for state or results.
The log source for tasks are “APP/TASK/<task_name>”. You’ll see something like “APP/TASK/0E858E94/0” in the log stream. Please note, the 0 is the instance id which will always be 0 as there is never more than 1 task.
The sequence id was added for the CLI UX and is never sent to the backend. This allows the CLI to uniquely identify a task within an app without exposing the GUID or the non-unique Task name.
I think this will all become a lot more clear when we complete the CLI UX, we are hoping to finish that work in the coming weeks.
Product Manager - Cloud Foundry API
Pivotal Software, Inc.
On October 21, 2016 at 12:55:55 AM, Andreas Mueller (andr.mueller(a)sap.com<mailto:andr.mueller(a)sap.com>) wrote:
thanks a lot for the quick and helpful response, which is in line with the latetest "release candidate" version of the V3 REST API docu.
So, the app log is the only channel for the task starter to consume the task results and multiple tasks with the same name can be started in parallel on a single app droplet.
Based on these facts I'd assume that the log lines belonging to the task can be easily identified in the app's log, by means of the task name and newly introduced sequenceId.
Could you please elaborate a bit more on the detailed format (source tagging) of log lines produced by an task belonging to an app?
I've found a hint in  (at that time there was no sequenceId, yet), but there does not seem to be some official documentation yet, about how exactly log lines produced by an app's task can be identified and grouped together.
Thanks and kind regards,