You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: