Skip to content
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

Allow policy to be defined that checks for and cleans up "idle" applications #11

Open
pacphi opened this issue Feb 21, 2019 · 3 comments
Labels
feature New feature or request

Comments

@pacphi
Copy link
Collaborator

pacphi commented Feb 21, 2019

Add the ability to define a policy that when executed scans for apps with one or more app instances that have been in an "idle" state (e.g., idle could mean some minimum threshold of CPU or RAM consumption or HTTP traffic) over a configurable duration (e.g., idle for 24 hours).

Large scale enterprise development is messy,... folks forget they’ve left sh*t running and this capability would offer another way for operators to get control of finite compute capacity. You might be thinking why not employ an auto scaler and policy? Thing is it’s not always consistently set up and bound to applications. And what if you truly want to scale to 0? In this case we're favoring availability of "thickly provisioned" compute.

@pacphi pacphi added the feature New feature or request label Feb 21, 2019
@pacphi pacphi changed the title Allow policy to be defined that checks for "idle" applications Allow policy to be defined that checks for and cleans up "idle" applications Feb 21, 2019
@pacphi
Copy link
Collaborator Author

pacphi commented Mar 5, 2019

Note: "Scaling to 0" is not going to be a use case cf-butler will handle. It's only interested in enforcing house-keeping policies so operators who have to work with scarce resources can make them more available for developers. Scaling to 0 implies the app that was terminated will also be "revived" when network requests resume. When cf-butler learns how to reap "idle" instances, the corresponding apps will not be "revived" until a developer or CI/CD delegate re-deploys (ie., with cf push) them.

@pacphi
Copy link
Collaborator Author

pacphi commented Apr 16, 2019

So looks like there’s some precedent here: https://github.com/cloudfoundry-community/autosleep/blob/develop/spring-apps/autosleep-core/src/main/java/org/cloudfoundry/autosleep/worker/ApplicationStopper.java.

First chore, reimagine this imperative impl into a more functional impl.

The difference in operational behavior will be that we needn’t to incur overhead to spin up and bind service brokered instances for each app in a space or spaces then tear down after idle check and idle cleanup.

@pacphi
Copy link
Collaborator Author

pacphi commented Aug 20, 2019

What is the definition of an "idle" app or service? For apps do we set params like: cpu, memory thresholds? do we also consider traffic (query the RTR logs filtering specific requests). For service-instances the could be a little more difficult to determine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant