Hi,

I wonder if there are plans to implement an auto-sleep behavior in
cloudfoundry, in which inactive apps would be automatically stopped after a
max inactivity threshold, and automatically restart upon arrival of traffic
on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of our
non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such feature
or would be interested in collaborating on an opensource implementation.

I drafted some specs for a java-based implementation we're planning to work
on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

For the autosleep feature why not but again only for non-prod application.

In my previous company, for DEV environment we stop application which have
been not updated since one month except some exception.
We considered that DEV is for active development.
Was just a batch script looking in the CCDB and calling cf-cli to stop
apps.

this feature request has come up occasionally, but rarely. this type of
feature is usually the most applicable to service providers with a free or
very low cost tier, where this can make a substantial difference in
increasing density.

you should consider rescheduling when moving out of the dormant state
(which may take awhile to send the container image to a new host), then you
have to account for resource reservations on the Cells anyway in case they
all wake up. one possibility is the common case to have the container image
pre-staged on a host and the Cell typically would have enough resources
available. in the case where it doesn't, then you reschedule and hold the
requests (up to a max # of requests for that app) longer. has some
interesting potential for DOS if not constrained.

the use of a route-service for implementation is an interesting idea, but
it does mean that every request for the app needs to go through a route
service even when the app is not sleeping, so i could also see other
alternative designs that stay out of the request path unless the app is
dormant. maybe that's something the system could do (after inactivity
period bind the app to a route-service) and when leaving the dormant state,
unbind the app from the route service.

it's probably most important to define "the what and why" of this feature
first, and then we can ask the routing eng team if they have ideas on how
to implement or if it makes sense as existing points of extension like a
service and the in-progress route service.

On Thu, Jul 30, 2015 at 5:58 PM, Gwenn Etourneau <getourneau(a)pivotal.io>
wrote:

For the autosleep feature why not but again only for non-prod application.

In my previous company, for DEV environment we stop application which have
been not updated since one month except some exception.
We considered that DEV is for active development.
Was just a batch script looking in the CCDB and calling cf-cli to stop
apps.






On Thu, Jul 30, 2015 at 7:46 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

I wonder if there are plans to implement an auto-sleep behavior in
cloudfoundry, in which inactive apps would be automatically stopped after a
max inactivity threshold, and automatically restart upon arrival of traffic
on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of
our non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such
feature or would be interested in collaborating on an opensource
implementation.

I drafted some specs for a java-based implementation we're planning to
work on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer

Thanks Gwenn and James for your feedback. Responses inline below

On Fri, Jul 31, 2015 at 7:57 AM, James Bayer wrote:

you should consider rescheduling when moving out of the dormant state
(which may take awhile to send the container image to a new host), then you
have to account for resource reservations on the Cells anyway in case they
all wake up. one possibility is the common case to have the container image
pre-staged on a host and the Cell typically would have enough resources
available. in the case where it doesn't, then you reschedule and hold the
requests (up to a max # of requests for that app) longer. has some
interesting potential for DOS if not constrained.

I would think that autosleep and auto-wakeup only make sense for apps that
can tolerate their traffic to be heldup for a while (i.e. time to schedule
the container image on a host), or alternatively tolerage their traffic to
transiently return 504 status code when wakingup. Apps that require better
availability and performance would be OK to pay for 2 permanent instances.

the use of a route-service for implementation is an interesting idea, but
it does mean that every request for the app needs to go through a route
service even when the app is not sleeping, so i could also see other
alternative designs that stay out of the request path unless the app is
dormant. maybe that's something the system could do (after inactivity
period bind the app to a route-service) and when leaving the dormant state,
unbind the app from the route service.

great idea, thanks! Implies the autosleep service would use some other way
to capture the incoming traffic signal (e.g. consume metron gorouter
metrics for the app), as to measure inactivity.

it's probably most important to define "the what and why" of this feature

first, and then we can ask the routing eng team if they have ideas on how
to implement or if it makes sense as existing points of extension like a
service and the in-progress route service.

Sounds good. Is the autosleep proposal document a good place to start this
"what and why" definition ? Should I made the document writeable by anyone
or just responding to incoming write access request sufficient ?

Guillaume.

On Thu, Jul 30, 2015 at 5:58 PM, Gwenn Etourneau wrote:

For the autosleep feature why not but again only for non-prod application.

In my previous company, for DEV environment we stop application which
have been not updated since one month except some exception.
We considered that DEV is for active development.
Was just a batch script looking in the CCDB and calling cf-cli to stop
apps.






On Thu, Jul 30, 2015 at 7:46 PM, Guillaume Berche wrote:

Hi,

I wonder if there are plans to implement an auto-sleep behavior in
cloudfoundry, in which inactive apps would be automatically stopped after a
max inactivity threshold, and automatically restart upon arrival of traffic
on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of
our non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such
feature or would be interested in collaborating on an opensource
implementation.

I drafted some specs for a java-based implementation we're planning to
work on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Hi Guillaume,

We have a similar motivation for such feature request for saving resources. We tried that our with a quickly implement POC and made similar experience as you have written in the document. Here is in short what we did:

* measure inactivity of an app – we took the time stamp of last log entry for an application and compared it with a fresh-hold – for the POC this was good enough but maybe a better measure is needed
* inactive apps – stop application and let all app routes point to a watch dog application
* watch dog – if a route is accessed then the watch dog wakes up the app, moves routes back to the app and redirects the request after app is up again

We played also with CPU, number of requests and other measures to scale up and down applications.

Challenges we did identify were:

* find the right measure for inactive apps
* start, stop or scale apps require permissions
* enable the feature only for dedicated orgs or spaces (e.g. a trial org)
* quick wakeup of app
* a deeper integration into CF could make sense (get better measures, better permission control, configure thresh hold for apps via CF CLI …)

We did implement this POC on top to the CC API. Using such feature in production will cause more issues and findings.

Regards,
Stephan


Von: Guillaume Berche
Antworten an: "Discussions about Cloud Foundry projects and the system overall."
Datum: Donnerstag, 30. Juli 2015 12:46
An: cf-dev
Betreff: [cf-dev] App autosleep support

Hi,

I wonder if there are plans to implement an auto-sleep behavior in cloudfoundry, in which inactive apps would be automatically stopped after a max inactivity threshold, and automatically restart upon arrival of traffic on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of our non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such feature or would be interested in collaborating on an opensource implementation.

I drafted some specs for a java-based implementation we're planning to work on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2] https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

Just FYI:

Spindown logic has once been (experimentally) implemented but seemed never
used:

*
https://github.com/cloudfoundry/cloud_controller_ng/commit/e7af12d832b07a56ad34ccc7bb27426d9e3e84bc
*
https://github.com/cloudfoundry/cloud_controller_ng/commit/e592281d1c3c5a7a359d1a87a8ffb1e74ff44b7f
*
https://github.com/cloudfoundry/cloud_controller_ng/commit/545cd8b5542a55e04b0c66f7cfc4ea3f55cf4572


The model of application has a deprecated flag named "production":

* http://apidocs.cloudfoundry.org/214/apps/creating_an_app.html

It seems to be intended to distinguish memory usage of "free" apps and
"paid" apps:

*
https://github.com/cloudfoundry/cloud_controller_ng/commit/ad4911f7349d2923acb3c6cc95e00a9fd66577b5
*
https://github.com/cloudfoundry/cloud_controller_ng/commit/5c07b49a66803c5539eb4be9ed4cbf9530f6303b



Klevenz, Stephan wrote

Hi Guillaume,

We have a similar motivation for such feature request for saving
resources. We tried that our with a quickly implement POC and made similar
experience as you have written in the document. Here is in short what we
did:

* measure inactivity of an app – we took the time stamp of last log
entry for an application and compared it with a fresh-hold – for the POC
this was good enough but maybe a better measure is needed
* inactive apps – stop application and let all app routes point to a
watch dog application
* watch dog – if a route is accessed then the watch dog wakes up the
app, moves routes back to the app and redirects the request after app is
up again

We played also with CPU, number of requests and other measures to scale up
and down applications.

Challenges we did identify were:

* find the right measure for inactive apps
* start, stop or scale apps require permissions
* enable the feature only for dedicated orgs or spaces (e.g. a trial
org)
* quick wakeup of app
* a deeper integration into CF could make sense (get better measures,
better permission control, configure thresh hold for apps via CF CLI …)

We did implement this POC on top to the CC API. Using such feature in
production will cause more issues and findings.

Regards,
Stephan


Von: Guillaume Berche
Antworten an: "Discussions about Cloud Foundry projects and the system
overall."
Datum: Donnerstag, 30. Juli 2015 12:46
An: cf-dev
Betreff: [cf-dev] App autosleep support

Hi,

I wonder if there are plans to implement an auto-sleep behavior in
cloudfoundry, in which inactive apps would be automatically stopped after
a max inactivity threshold, and automatically restart upon arrival of
traffic on their routes. Similar to google app engine default behavior [1]

I did not find mentions of this yet in mailing lists and trackers.

We feel at Orange that such feature can improve the density for some of
our non-prod use-cases (with environmental and financial benefits).

I'd like to know if someone in the community already worked on such
feature or would be interested in collaborating on an opensource
implementation.

I drafted some specs for a java-based implementation we're planning to
work on [2]. I'd love to hear feedbacks and suggestions on this.

Thanks in advance,

Guillaume.

[1] https://cloud.google.com/appengine/docs/java/modules/
[2]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

_______________________________________________
cf-dev mailing list

cf-dev(a).cloudfoundry

https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-App-autosleep-support-tp962p1049.html
Sent from the CF Dev mailing list archive at Nabble.com.