Per-Application Crash Configuration

[onsi]

This is low hanging fruit that would satisfy a feature I've often heard requested of CF:

https://github.com/pivotal-cf-experimental/diego-dev-notes/blob/master/proposals/per-application-crash-configuration.md

Thoughts?

[fraenkel]

If no crash policy is provided, is there a default defined somewhere the is configurable or is it hard coded? The answer may trigger more questions.

[onsi]

The thought was that it would be configurable.

You say "I want the default" by putting nothing in the desiredlrp. That way if an operator modifies the default we'll pick I up (ie no data migration - that would be terrible).

Always open to hearing "that's way too complicated" ;)

On Saturday, January 24, 2015, Michael Fraenkel notifications@github.com wrote:

If no crash policy is provided, is there a default defined somewhere the is configurable or is it hard coded? The answer may trigger more questions.

— Reply to this email directly or view it on GitHub https://github.com/pivotal-cf-experimental/diego-dev-notes/issues/18#issuecomment-71346220 .

[fraenkel]

Thats what I wanted to hear. I realize that if the defaults change, you get whatever you get. But then again, you never knew nor cared what you got so its all good.

[jbayer]

for comparison, k8s currently has a very simple policy for pods on cursory glance: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/pod-states.md#examples

as well as some long discussions in past issues: https://github.com/GoogleCloudPlatform/kubernetes/issues/127

[onsi]

Chatted with @tedsuo and @hsiliev about this. Updated the doc to reflect that the DefaultCrashRestartPolicy lives in the BBS and can be updated without a BOSH deploy.

Also: emailed vcap-dev.

[fraenkel]

This is going to create a problem. If we allow BOSH to define a default and the Receptor can update it, when do we do which on re-deploys?

[onsi]

Perhaps I wasn't clear. In the updated proposal, you can't modify the defaults via BOSH. They only live in the BBS and can be queried/modified via the receptor API. This makes this something that a CF admin sets and modifies using the CC API.

In general moving away from bosh-configuring the sorts of knobs that can be dynamically updated at runtime is A Good Thing™ that we should tend towards.

[fraenkel]

But somehow it gets there the first time and we manage not to lose it?

[onsi]

that's all in there too -- if you don't set it it's the default. otherwise, if it's set in CC NSYNC's bulker will pick it up and make sure it's up-to-date in the BBS

[fraenkel]

Missed the part that the default is now hard-coded and non-configurable.

[onsi]

Added stories with +crash-restart-policy tag