Make sure periodical tasks use randomization #4646
Labels
Comments
aplopez
added a commit
to aplopez/sssd
that referenced
this issue
Jun 2, 2022
For several tasks the random offset was set to 0. Made then use a configurable offset. The default values are based on the associated period's default value. Some changes: 1) ad_machine_account_password_renewal_opts becomes period:initial_delay[:offset] If offset is not specified, it is considered to be 0 for compatibility (same behavior as before). If the whole string is not specified, the default is 86400:750:300 2) refresh_expired_interval could not be greater than entry_cache_timeout. In that situation, it was set to 0.75 * entry_cache_timeout. Now, refresh_expired_interval + refresh_expired_interval_offset cannot be greater than entry_cache_timeout. In that situation, refresh_expired_interval is set to 0.70 * entry_cache_timeout, and refresh_expired_interval_offset becomes refresh_expired_interval * 0.1. This makes a 5% variation around 75% (70%~80%). :config: New option 'ldap_enumeration_refresh_offset' to set the maximum period deviation between enumeration updates. Defaults to 30 seconds. :config: New option 'subdomain_refresh_interval_offset' to set the maximum period deviation when refreshing the subdomain list. :config: New option 'dyndns_refresh_interval_offset' to set the maximum period deviation when updating the client's DNS entry. Defaults to 0. :config: New option 'refresh_expired_interval_offset' to set the maximum period deviation when refreshing expired entries in background. :config: New option 'ldap_purge_cache_offset' to set the maximum time deviation between cache cleanups. Defaults to 0. :config: Option 'ad_machine_account_password_renewal_opts' now accepts an optional third part as the maximum deviation in the provided period (first part) and initial delay (second part). If the period and initial delay are provided but not the offset, the offset is assumed to be 0. If no part is provided, the default is 86400:750:300. Resolves: SSSD#4646
aplopez
added a commit
to aplopez/sssd
that referenced
this issue
Jun 2, 2022
For several tasks the random offset was set to 0. Made then use a configurable offset. The default values are based on the associated period's default value. Some changes: 1) ad_machine_account_password_renewal_opts becomes period:initial_delay[:offset] If offset is not specified, it is considered to be 0 for compatibility (same behavior as before). If the whole string is not specified, the default is 86400:750:300 2) refresh_expired_interval could not be greater than entry_cache_timeout. In that situation, it was set to 0.75 * entry_cache_timeout. Now, refresh_expired_interval + refresh_expired_interval_offset cannot be greater than entry_cache_timeout. In that situation, refresh_expired_interval is set to 0.70 * entry_cache_timeout, and refresh_expired_interval_offset becomes refresh_expired_interval * 0.1. This makes a 5% variation around 75% (70%~80%). :config: New option 'ldap_enumeration_refresh_offset' to set the maximum period deviation between enumeration updates. Defaults to 30 seconds. :config: New option 'subdomain_refresh_interval_offset' to set the maximum period deviation when refreshing the subdomain list. :config: New option 'dyndns_refresh_interval_offset' to set the maximum period deviation when updating the client's DNS entry. Defaults to 0. :config: New option 'refresh_expired_interval_offset' to set the maximum period deviation when refreshing expired entries in background. :config: New option 'ldap_purge_cache_offset' to set the maximum time deviation between cache cleanups. Defaults to 0. :config: Option 'ad_machine_account_password_renewal_opts' now accepts an optional third part as the maximum deviation in the provided period (first part) and initial delay (second part). If the period and initial delay are provided but not the offset, the offset is assumed to be 0. If no part is provided, the default is 86400:750:300. Resolves: SSSD#4646
aplopez
added a commit
to aplopez/sssd
that referenced
this issue
Jun 3, 2022
For several tasks the random offset was set to 0. Made then use a configurable offset. The default values are based on the associated period's default value. Some changes: 1) ad_machine_account_password_renewal_opts becomes period:initial_delay[:offset] If offset is not specified, it is considered to be 0 for compatibility (same behavior as before). If the whole string is not specified, the default is 86400:750:300 2) refresh_expired_interval could not be greater than entry_cache_timeout. In that situation, it was set to 0.75 * entry_cache_timeout. Now, refresh_expired_interval + refresh_expired_interval_offset cannot be greater than entry_cache_timeout. In that situation, refresh_expired_interval is set to 0.70 * entry_cache_timeout, and refresh_expired_interval_offset becomes refresh_expired_interval * 0.1. This makes a 5% variation around 75% (70%~80%). :config: New option 'ldap_enumeration_refresh_offset' to set the maximum period deviation between enumeration updates. Defaults to 30 seconds. :config: New option 'subdomain_refresh_interval_offset' to set the maximum period deviation when refreshing the subdomain list. :config: New option 'dyndns_refresh_interval_offset' to set the maximum period deviation when updating the client's DNS entry. Defaults to 0. :config: New option 'refresh_expired_interval_offset' to set the maximum period deviation when refreshing expired entries in background. :config: New option 'ldap_purge_cache_offset' to set the maximum time deviation between cache cleanups. Defaults to 0. :config: Option 'ad_machine_account_password_renewal_opts' now accepts an optional third part as the maximum deviation in the provided period (first part) and initial delay (second part). If the period and initial delay are provided but not the offset, the offset is assumed to be 0. If no part is provided, the default is 86400:750:300. Resolves: SSSD#4646
aplopez
added a commit
to aplopez/sssd
that referenced
this issue
Jun 3, 2022
For several tasks the random offset was set to 0. Made then use a configurable offset. The default values are based on the associated period's default value. Some changes: 1) ad_machine_account_password_renewal_opts becomes period:initial_delay[:offset] If offset is not specified, it is considered to be 0 for compatibility (same behavior as before). If the whole string is not specified, the default is 86400:750:300 2) refresh_expired_interval could not be greater than entry_cache_timeout. In that situation, it was set to 0.75 * entry_cache_timeout. Now, refresh_expired_interval + refresh_expired_interval_offset cannot be greater than entry_cache_timeout. In that situation, refresh_expired_interval is set to 0.70 * entry_cache_timeout, and refresh_expired_interval_offset becomes refresh_expired_interval * 0.1. This makes a 5% variation around 75% (70%~80%). :config: New option 'ldap_enumeration_refresh_offset' to set the maximum period deviation between enumeration updates. Defaults to 30 seconds. :config: New option 'subdomain_refresh_interval_offset' to set the maximum period deviation when refreshing the subdomain list. :config: New option 'dyndns_refresh_interval_offset' to set the maximum period deviation when updating the client's DNS entry. Defaults to 0. :config: New option 'refresh_expired_interval_offset' to set the maximum period deviation when refreshing expired entries in background. :config: New option 'ldap_purge_cache_offset' to set the maximum time deviation between cache cleanups. Defaults to 0. :config: Option 'ad_machine_account_password_renewal_opts' now accepts an optional third part as the maximum deviation in the provided period (first part) and initial delay (second part). If the period and initial delay are provided but not the offset, the offset is assumed to be 0. If no part is provided, the default is 86400:750:300. Resolves: SSSD#4646
aplopez
added a commit
to aplopez/sssd
that referenced
this issue
Jun 15, 2022
For several tasks the random offset was set to 0. Made then use a configurable offset. The default values are based on the associated period's default value. Some changes: 1) ad_machine_account_password_renewal_opts becomes period:initial_delay[:offset] If offset is not specified, it is considered to be 0 for compatibility (same behavior as before). If the whole string is not specified, the default is 86400:750:300 2) refresh_expired_interval could not be greater than entry_cache_timeout. In that situation, it was set to 0.75 * entry_cache_timeout. Now, refresh_expired_interval + refresh_expired_interval_offset cannot be greater than entry_cache_timeout. In that situation, refresh_expired_interval is set to 0.70 * entry_cache_timeout, and refresh_expired_interval_offset becomes refresh_expired_interval * 0.1. This makes a 5% variation around 75% (70%~80%). :config: New option 'ldap_enumeration_refresh_offset' to set the maximum period deviation between enumeration updates. Defaults to 30 seconds. :config: New option 'subdomain_refresh_interval_offset' to set the maximum period deviation when refreshing the subdomain list. :config: New option 'dyndns_refresh_interval_offset' to set the maximum period deviation when updating the client's DNS entry. Defaults to 0. :config: New option 'refresh_expired_interval_offset' to set the maximum period deviation when refreshing expired entries in background. :config: New option 'ldap_purge_cache_offset' to set the maximum time deviation between cache cleanups. Defaults to 0. :config: Option 'ad_machine_account_password_renewal_opts' now accepts an optional third part as the maximum deviation in the provided period (first part) and initial delay (second part). If the period and initial delay are provided but not the offset, the offset is assumed to be 0. If no part is provided, the default is 86400:750:300. Resolves: SSSD#4646
aplopez
added a commit
to aplopez/sssd
that referenced
this issue
Jun 22, 2022
For several tasks the random offset was set to 0. Made then use a configurable offset. The default values are based on the associated period's default value. Some changes: 1) ad_machine_account_password_renewal_opts becomes period:initial_delay[:offset] If offset is not specified, it is considered to be 0 for compatibility (same behavior as before). If the whole string is not specified, the default is 86400:750:300 2) refresh_expired_interval could not be greater than entry_cache_timeout. In that situation, it was set to 0.75 * entry_cache_timeout. Now, refresh_expired_interval + refresh_expired_interval_offset cannot be greater than entry_cache_timeout. In that situation, refresh_expired_interval is set to 0.70 * entry_cache_timeout, and refresh_expired_interval_offset becomes refresh_expired_interval * 0.1. This makes a 5% variation around 75% (70%~80%). :config: New option 'ldap_enumeration_refresh_offset' to set the maximum period deviation between enumeration updates. Defaults to 30 seconds. :config: New option 'subdomain_refresh_interval_offset' to set the maximum period deviation when refreshing the subdomain list. :config: New option 'dyndns_refresh_interval_offset' to set the maximum period deviation when updating the client's DNS entry. Defaults to 0. :config: New option 'refresh_expired_interval_offset' to set the maximum period deviation when refreshing expired entries in background. :config: New option 'ldap_purge_cache_offset' to set the maximum time deviation between cache cleanups. Defaults to 0. :config: Option 'ad_machine_account_password_renewal_opts' now accepts an optional third part as the maximum deviation in the provided period (first part) and initial delay (second part). If the period and initial delay are provided but not the offset, the offset is assumed to be 0. If no part is provided, the default is 86400:750:300. Resolves: SSSD#4646
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3625
The ptask API already supports that the periodical task does not occur at exactly the same times, but with a random offset. But the vast majority of the periodical tasks doesn't use that. We should make sure to review whether they did.
This might be useful in environments like compute clusters where it's likely that all nodes are brough up at the same time - having the periodical tasks non-random might result in all nodes issuing updates at same time.
Comments
Comment from jhrozek at 2018-01-22 15:54:03
cc @Firstyear
Comment from jhrozek at 2018-02-06 10:44:25
From sssd-devel discussion where Pavel noted:
However, we must make sure that randomized schedules still make sense (e.g. sudo smart refresh inteval << sudo full refresh interval).
Comment from jhrozek at 2018-02-14 22:50:53
Metadata Update from @jhrozek:
Comment from thalman at 2020-03-11 14:03:57
Metadata Update from @thalman:
The text was updated successfully, but these errors were encountered: