#1083 move the resolover cache handling from fail over to a new layer atop resolver
Closed: wontfix 4 years ago by pbrezina. Opened 12 years ago by jhrozek.

The asynchronous resolver currently always performs online resolution and returns TTL of the result. The decision on whether to reuse the cached result or resolve online again is done in the layer above the resolver - the fail over code.

We should move the cache evaluation into the resolver itself or create a very thin layer on top of the resolver. This would help other consumers of the resolver such as the upcoming referral chasing code.


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

Fields changed

owner: somebody => jhrozek

Fields changed

status: new => assigned

Fields changed

priority: major => blocker

Fields changed

milestone: SSSD 1.7.0 => Referrals

Fields changed

rhbz: => 0

Fields changed

blockedby: =>
blocking: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
priority: blocker => critical
selected: =>

Fields changed

milestone: SSSD Referrals Feature => NEEDS_TRIAGE
review: => 0

Fields changed

priority: critical => major
summary: move the resolover cache handling from fail over to resolver itself => move the resolover cache handling from fail over to a new layer atop resolver

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11 beta

Fields changed

blocking: => #2394
changelog: =>

Fields changed

mark: => 0

This is definitely the right thing to do, but we won't touch the resolver code unless the changes are required by the 1.13 failover/resolver RFEs we plan.

milestone: SSSD 1.13 beta => SSSD 1.13 backlog
owner: jhrozek => somebody
status: assigned => new
type: defect => enhancement

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

Refactoring the resolver and failover is out of scope of 1.14.

milestone: SSSD 1.14 beta => SSSD 1.15 beta
sensitive: => 0

Metadata Update from @jhrozek:
- Issue marked as blocked by: #2394
- Issue set to the milestone: SSSD Future releases (no date set yet)

7 years ago

Metadata Update from @thalman:
- Custom field blocking reset (from #2394)
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

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/2125

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.

Login to comment on this ticket.

Metadata