aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David McLaughlin <da...@dmclaughlin.com>
Subject Re: Coordinated update configuration
Date Tue, 27 Jan 2015 19:04:26 GMT
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 <maxim@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/%3CCAOTkfX7x2oipk4ZFysoS0uWZRizOnKJA3y15pvEW5K4YnUHw-A@mail.gmail.com%3E
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message