[SSSD] [PATCHES] Drop-redundant-sysdb_ctx-parameter

Michal Židek mzidek at redhat.com
Tue Nov 12 11:30:13 UTC 2013


On 11/12/2013 12:23 PM, Jakub Hrozek wrote:
> On Tue, Nov 12, 2013 at 12:18:32PM +0100, Michal Židek wrote:
>> On 11/09/2013 06:07 AM, Simo Sorce wrote:
>>> On Fri, 2013-11-08 at 16:41 +0100, Michal Židek wrote:
>>>> Hello,
>>>>
>>>> these patches (made by Jakub and me) remove redundant sysdb_ctx
>>>> parameter from sysdb API in functions that are closely bound to some
>>>> domain (sss_domain_info already contains sysdb_ctx, so there is no need
>>>> to pass it as a separate parameter).
>>>
>>> Looks ok, but please separate the patches that fix the names (last one
>>> of the set) and one patch that includes removeal of unused functions in
>>> separate patchset. Keep this one exclusively to handle the removal and
>>> don't be tempted to sneak in any other change, because those will get
>>> lost in the noise.
>>
>> Ok. I will send the patch with the parameter name in a different thread
>> after this lands in master. But the patch that merges
>> ipa_selinux_common.c and ipa_selinux.c files is required to apply the
>> rest of the patches so I kept it here, and just split into separate
>> patch.
>>
>>>
>>>> NOTE:
>>>> This is the first wave of sysdb refactoring effort. Other sysdb changes
>>>> will follow, including ticket
>>>> https://fedorahosted.org/sssd/ticket/2129
>>>> (Always store users with FQDN with hardcoded format), which is change
>>>> that should simplify handling of 'name' attribute and avoid code
>>>> patterns like this:
>>>>
>>>> if (IS_SUBDOMAIN) {
>>>>      parse name and domain part from 'name' attribute using
>>>>      regular expression (requires initialization of names_ctx).
>>>> } else {
>>>>      'name' attribute contains only name
>>>> }
>>>>
>>>> In other words, we should store data in unified manner for main domains
>>>> as well as for subdomains and avoid the need for regular expressions
>>>> when simply need to parse name and domain portion from the 'name'
>>>> attribute. Alternatively we might store name and domain portions in
>>>> separate attributes instead of one FQDN attribute.
>>>
>>> Separate attributes looks like it would be more robust, but then you
>>> have to deal with potential name conflicts with subdomains, so you may
>>> have little choice here, short of creating subtrees for subdomains.
>>>
>>> Have you already thought about how to upgrade an existing DB ?
>>> I am a bit concerned about all the renames, it may take a *lot* of time
>>> if done at startup, and the DB is big, as a lot of indexes needs to be
>>> fixed. Perhaps we can drop all indeces, do all renames and then rebuild
>>> indeces ...
>>
>> I thought it is not a big deal since it happens only once after
>> upgrade of SSSD. Maybe just syslog with message something like
>> 'Converting databese to new sysdb format version. This may take some
>> time depending on the size of the database.'... or something like
>> that.
>
> I think Simo was concerned about the upgrade taking too long.
>
> I think we should build a large test database (hundreds of thousands of
> entries) and attempt to upgrade it to see the performance. Then we'll at
> least have an idea how expensive or cheap the upgrade might be.

This is good idea. At least we will know if we are talking about seconds 
or minutes.




More information about the sssd-devel mailing list