Re: scheduler

Eric Malm <emalm@...>

Hi, Corentin,

Diego, like the DEAs, supports evacuation of LRP instances during
controlled shutdown of a cell VM (the analog of a single DEA in Diego's
architecture). If you're using BOSH to deploy your Diego cluster and you
redeploy to scale down the number of cell VMs, BOSH will trigger evacuation
via the `drain` script in the rep job template. This will cause that cell's
rep process to signal to the rest of the system via the BBS that its
instances should be started on the other cells. Once those instances are
all placed elsewhere, or the drain timeout is reached, the cell will finish
shutting down. If you're not using BOSH to deploy your cluster, the drain
script template in diego-release should show you how to trigger the rep to
evacuate manually.

If you're reducing the size of your deployment, you should of course ensure
that you have sufficient capacity in the scaled-down cluster to run all
your application instances, with some headroom for staging tasks and
placement of high-memory app instances. Diego's placement algorithm
currently prefers an even distribution of instances across availability
zones and cell VMs, so its ideal placement results in roughly the same
amount of capacity free on each cell.

Diego itself does not include an autoscaling mechanism for long-running
processes, although it does now report instance CPU/disk/memory usage
metrics through the loggregator system. One could use that to build an
autoscaler for CF apps via the CC API; if existing autoscalers use those
fields from the 'stats' endpoint on the CC API, they should continue to
function with the Diego backend. Likewise, Diego has no knowledge of its
provisioner (BOSH or otherwise), so it can't scale its own deployment
automatically, but one could automate monitoring Diego's capacity metrics
(also emitted through the loggregator system) and scaling up or down the
cell deployment in response to certain capacity thresholds.

Eric, CF Runtime Diego PM

On Wed, May 27, 2015 at 5:22 AM, Corentin Dupont <> wrote:

Some other questions:
- is there a consolidation mechanism? From what I can see from the videos,
Diego is only doing load balancing when allocating an application to a DEA.
What is more important to us is to consolidate: we want to minimize the
number of DEAs.
Is there an extensibility mechanism to the scheduler?

- is there an auto-scaling mechanism? I'm thinking of auto-scaling at two
At application level, it would be nice to have auto-scaling in the
manifest.yml: if some KPI goes up, launch more instances.
At DEA level, a bit like in bosh-scaler: if DEAs are full, launch a new


On Tue, May 26, 2015 at 5:25 PM, Onsi Fakhouri <ofakhouri(a)>

Diego is very much usable at this point and we're encouraging beta
testers to start putting workloads on it. Check out for all things Diego.

Diego supports one off tasks. It's up to the consumer (e.g. Cloud
Controller) to submit the tasks when they want them run. We'd like to
bubble this functionality up to the CC but it's not a very high priority at
the moment.


Sent from my iPad

On May 26, 2015, at 8:21 AM, Corentin Dupont <> wrote:

Another question, what is the status of Diego? Is there an expected date
for its release?
Is it useable already?
If I understand correctly, Diego doesn't supports cron-like jobs, but
will facilitate them?

On Tue, May 26, 2015 at 5:08 PM, James Bayer <jbayer(a)> wrote:

those are exciting use cases, thank you for sharing the background!

On Tue, May 26, 2015 at 2:37 AM, Corentin Dupont <cdupont(a)
Hi James, thanks for the answer!
We are interested to implement a job scheduler for CF. Do you think
this could be interesting to have?

We are working in a project called DC4Cities (
were the objective is to make data centres use more renewable energy.
We want to use PaaS frameworks such as CloudFoundry to achieve this
The idea is to schedule some PaaS tasks at the moment there is more
renewable energies (when the sun is shining).

That's why I had the idea to implement a job scheduler for batch jobs
in CF. For example one could state "I need to have this task to run for 2
hours per day" and the scheduler could choose when to run it.

Another possibility is to have application-oriented SLA implemented at
CF level. For example if some KPIs of the application are getting too low,
CF would spark a new container. If the SLA is defined with some
flexibility, it could also be used to schedule renewable energies. For
example in our trial scenarios we have an application that convert images.
Its SLA says that it needs to convert 1000 images per day, but you are free
to produce them when you want i.e. when renewable energies are available...

On Mon, May 25, 2015 at 7:29 PM, James Bayer <jbayer(a)> wrote:

there is ongoing work to support process types using buildpacks, so
that the same application codebase could be used for multiple different
types of processes (web, worker, etc).

once process types and diego tasks are fully available, we expect to
implement a user-facing api for running batch jobs as application processes.

what people do today is run a long-running process application which
uses something like quartz scheduler [1] or ruby clock with a worker system
like resque [2]


On Mon, May 25, 2015 at 6:19 AM, Corentin Dupont <
cdupont(a)> wrote:

To complete my request, I'm thinking of something like this in the

- name: virusscan
memory: 512M
instances: 1

*schedule: - startFrom : a date endBefore : a
date walltime : a duration*
* precedence : other application name moldable :

What do you think?

On Mon, May 25, 2015 at 11:25 AM, Corentin Dupont <
cdupont(a)> wrote:

---------- Forwarded message ----------
From: Corentin Dupont <>
Date: Mon, May 25, 2015 at 11:21 AM
Subject: scheduler
To: cf-dev(a)

Hi guys,
just to know, is there a project to add a job scheduler in Cloud
I'm thinking of something like the Heroku scheduler (
That would be very neat to have regular tasks triggered...


Corentin Dupont
Researcher @

cf-dev mailing list

Thank you,

James Bayer

Thank you,

James Bayer


Corentin Dupont
Researcher @

cf-dev mailing list


Corentin Dupont
Researcher @

cf-dev mailing list

Join to automatically receive all group messages.