9:22 a.m.
On Fri, Feb 19, 2016 at 02:34:17PM +0100, Pavel Březina wrote:
I'm sending this on behalf of Pavel Reichl...
Hi,
during devconf week Jakub asked us to send a few overview paragraphs about
features we will be working on in forth coming months. Implementation
details will be discussed in design documents as usually.
I and Pavel Březina will be working together on SSSD control tool - SSSCTL.
Main purpose of this task is to make administration & debugging tasks more
user friendly and thus hopefully save time of users, support and us
developers.
SSSCTL will be mostly CLI/TUI client using the SSSD infopipe as a server
that will be providing necessary data and will perform/delegate commands to
the SSSD providers and responders.
Capabilities of the tool:
1) online/offline state - https://fedorahosted.org/sssd/ticket/385
Users have repeatedly asked for simple mean how to check if data provider id
offline or online without need to check logs (if logging is enabled at all).
OK, we just need to make it clear in the docs that the state can change
over time either with another lookup or even with a periodic task or as
a result of external change (netlink notification etc..)
2a) Report whether the entry is present in SSSD cache -
https://fedorahosted.org/sssd/ticket/2166
2b) Check if the cached entry is valid and refresh if appropriate -
https://fedorahosted.org/sssd/ticket/2166
I think 2a and 2b are more or less the same, what the admins are
interested in is whether an entry was returned from the cache or
refreshed. So I guess publishing the dataExpireTimestamp on the bus
would do?
2c) Measure the time an operation took (useful in performance tuning) -
https://fedorahosted.org/sssd/ticket/385
IIRC when we brainstormed about the idea we were thinking about a ring
buffer that would keep track of the last 10 back end requests and their
start/stop time, correct?
3) Failover status - Current state of failover process {connecting to
server, waiting, failed, succeeded)
4) Display server to which provider is connected to -
https://fedorahosted.org/sssd/ticket/385
Did you already think about how this would be exposed? As part of the
domain object on the bus or as a new status object (I think I would
prefer the latter, at least because I don't think anyone except root
should read this info..)
5) Display current debug level of a component
6) Generate memory report
Usually when user is observing a memory leak we provide him a special build
that generates talloc report which we can then analyze. Using this tool
customer would simply select SSSD component that is supposed to leak memory
and generate the talloc report immediately.
7) Force reload - restart of components?
Hmm, I thought this was a separate task, which would add a command to
sss_cache that actually removes the caches? This would be handy when we
start adding more files (secrets especially) to /var/lib/sss/ to prevent
someone from accidentally deleting these files...
Work dependency:
1) Data provider refactoring
2) Extend interface between DP and IFP -
https://fedorahosted.org/sssd/ticket/2957,
https://fedorahosted.org/sssd/ticket/2954
I think only these two should be part of the Alpha release and all other
tickets should be in Beta.
> 3) Extend public interface of IFP
> 4) Tool (logic + user interface) - https://fedorahosted.org/sssd/ticket/385
> _______________________________________________
> sssd-devel mailing list
> sssd-devel(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org