+1 for option #1 with a default of None. On Wed, Jan 28, 2015 at 8:12 AM, Maxim Khutornenko <ma...@apache.org> wrote:
> Thanks David, I agree. Unless there are other opinions, I will proceed > with #1. > > On Tue, Jan 27, 2015 at 11:04 AM, David McLaughlin > <da...@dmclaughlin.com> wrote: > > The heartbeat requirement feature should be disabled by default, so I > think > > it's best to just do [1] and make it None by default in UpdateConfig and > > optional field in the thrift API. > > > > On Tue, Jan 27, 2015 at 10:21 AM, Maxim Khutornenko <ma...@apache.org> > > wrote: > > > >> We are working on AURORA-690 to support external service coordinated > >> job updates. The feature design was proposed in [1] and discussed in > >> [2]. > >> > >> The one remaining question I would like to discuss here is how to > >> expose the coordinated update configuration to the user. The > >> approaches as I see: > >> > >> 1. Expose "blockIfNoPulsesAfterMs" directly in UpdateConfig requiring > >> user to supply its value to indicate a coordinated update: > >> ... > >> update_config = UpdateConfig(pulse_interval_secs=60) > >> ... > >> While the most straightforward to implement, it may not deliver on > >> user's expectations. The external service may be unable to match a > >> requested job health refresh rate and potentially waste scheduler > >> performance with unnecessary pulseJobUpdate RPC calls. We may limit > >> the lower configurable bound for pulse_interval_secs to something sane > >> to address the latter but it will still not address the unmatched > >> health refresh rate issue. > >> > >> > >> 2. Expose a flag in UpdateConfig and hardcode a large enough (e.g. 1 > >> minute) interval internally. The Aurora client would then populate > >> "blockIfNoPulsesAfterMs" to default interval in case the > >> require_update_pulse flag is set: > >> ... > >> update_config = UpdateConfig(require_update_pulse=True) > >> ... > >> This is more user friendly but less flexible in terms of requirement > >> changes and still does not protect against external service health > >> refresh rate changes. > >> > >> > >> 3. Do not expose any coordinated update settings in a public schema > >> and require external service to act as a job update request proxy > >> mutating job update config on the fly before passing it to the > >> scheduler. > >> This is ideal from the external service controlling the health refresh > >> rate but may require too much hacking as we don't have a private job > >> config schema and relaying user's identity via an external service is > >> no fun from security perspective. > >> > >> > >> Any other options? I am personally leaning towards #1 with hardcoded > >> min value validation as the simplest solution. Users will be required > >> to have a knowledge of what refresh rate their health monitoring > >> system is capable of to configure pulse_interval_secs accordingly. > >> Thoughts? > >> > >> Thanks, > >> Maxim > >> > >> > >> [1] - > >> > https://github.com/maxim111333/incubator-aurora/blob/hb_doc/docs/update-heartbeat.md > >> > >> [2] - > >> > http://mail-archives.apache.org/mod_mbox/aurora-dev/201410.mbox/%3ccaotkfx7x2oipk4zfysos0uwzrizonkja3y15pvew5k4ynuh...@mail.gmail.com%3E > >> >
