Fields changed

description: There are several basically copy and paste parts of the code that initialize resolv context. We should create a utility function that would return a resolv context with default settings.

Currently there are two timeout options:
CONFDB_DOMAIN_RESOLV_OP_TIMEOUT (aka dns_resolver_op_timeout) is a very
low-level setting that fine-tunes how long should c-ares talk to individual
nameservers before giving up and trying the next DNS server. It is not
documented and left out of configAPI. This option is passed to resolv context.
CONFDB_DOMAIN_RESOLV_TIMEOUT (aka dns_resolver_timeout) is a fail over
setting that tunes how long should a service resolution take. Keep in mind
that "service resolution" might involve talking to different DNS servers.

CONFDB_DOMAIN_RESOLV_TIMEOUT is handled as a separate tevent timer (see fo_resolve_service_activate_timeout() and fo_resolve_service_timeout()). We should make these functions generally accessible and reuse them in other parts of the code (namely sudo and ipa_dyndns).
=> There are several basically copy and paste parts of the code that initialize resolv context. We should create a utility function that would return a resolv context with default settings.

Currently there are two timeout options:
CONFDB_DOMAIN_RESOLV_OP_TIMEOUT (aka dns_resolver_op_timeout) is a very low-level setting that fine-tunes how long should c-ares talk to individual nameservers before giving up and trying the next DNS server. It is not documented and left out of configAPI. This option is passed to resolv context.
CONFDB_DOMAIN_RESOLV_TIMEOUT (aka dns_resolver_timeout) is a fail over setting that tunes how long should a service resolution take. Keep in mind that "service resolution" might involve talking to different DNS servers.

CONFDB_DOMAIN_RESOLV_TIMEOUT is handled as a separate tevent timer (see fo_resolve_service_activate_timeout() and fo_resolve_service_timeout()). We should make these functions generally accessible and reuse them in other parts of the code (namely sudo and ipa_dyndns).

Most probably this will end up as part of #941.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.10 beta

Fields changed

rhbz: => 0
type: defect => task

Fields changed

proposed_priority: => Nice to have

Cleaning the 1.10 milestones before putting tickets into it.

milestone: SSSD 1.10 beta => Temp milestone

Moving planned features and bug fixes into the 1.10 bucket.

milestone: Temp milestone => SSSD 1.10.0

Fields changed

milestone: SSSD 1.10.0 => Temp milestone

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: Temp milestone => SSSD 1.10 beta

Fields changed

priority: major => minor

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

mark: => 0

This is actually implemented since 584eda0

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
resolution: => duplicate
review: => 0
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2484

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.