Closed onsi closed 9 years ago
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.
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 .
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.
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
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.
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?
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.
But somehow it gets there the first time and we manage not to lose it?
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
Missed the part that the default is now hard-coded and non-configurable.
Added stories with +crash-restart-policy
tag
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?