[Freeipa-devel] tree reorganization proposal

[Rob Crittenden]

Jason Gerard DeRose wrote:
> On Tue, 2009-01-27 at 14:34 -0500, Rob Crittenden wrote:
>> Now that I've muddled things up by importing Jason's tree into the 
>> master branch, here is how I propose we clean it up.
>>
>> I'm purposely excluding Makefiles for now. I'm not sure they are going 
>> to be needed as we can probably cover the installation as part of 
>> setup.py. I'm particularly worried about my suggestion of 
>> ipaserver/tools. I'm not sure how flexible the python setuputils is to 
>> not include subdirs when it creates packages, and to move things around. 
>> This is mostly based on cosmetic and tidiness reasons. I still need to 
>> figure out how to build rpms from these.
>>
>> mkdir ipaserver/install
>> mv ipa-server/ipaserver/* ipaserver/install
>>
>> mkdir ipaserver/tools
>> mkdir ipaserver/tools/man
>> mv ipa-server/ipa-install/ipa-* ipaserver/tools
>> mv ipa-server/ipa-install/ipactl ipaserver/tools
>> mv ipa-server/ipa-upgradeconfig ipaserver/tools
>> mv ipa-server/ipa-ldap-updater ipaserver/tools
>> mv ipa-server/ipa-fix-CVE-2008-3274 ipaserver/tools
>> mv ipa-server/man/* ipaserver/tools/man
>>
>> mv ipa-server/ipa-install/share ipaserver
>> mv ipa-server/ipa-install/updates/* ipaserver/updates
>>
>> mkdir ipaserver/install
>> mv ipa-server/ipaserver/* ipa-server/install
>>
>> mv ipa-server/selinux ipaserver
>> mv ipa-server/ipa-kpasswd ipaserver
>> mv ipa-server/ipa-slapi-plugins ipaserver
>>
>> I think after this we can remove everything in ipa-server.
>>
>> The resulting directories will look something like:
>>
>> ipalib/
>> ipa-python/
>> ipaserver/tools/
>> ipaserver/
>> ipaserver/tools/
>> ipaserver/tools/man/
>> ipaserver/share/
>> ipaserver/install/
>> ipaserver/updates/
>> ipaserver/ipa-kpasswd/
>> ipaserver/ipa-slapi-plugins/
>> ipaserver/selinux/
>> ipawebui/
>> tests/
>> ipa-client/
>>
>> ipa-admintools is going away and the radius tools and functionality will 
>> be folded into the server as time permits.
>>
>> I suspect that ipa-python will be folded into ipalib at some point. Most 
>> of it is already re-implemented as it is. It very much depends on what 
>> the client installer will look like and whether we will include one in 
>> this tree or require people to use SSSD.
>>
>> Lots of this is just moving things from ipa-server into ipaserver which 
>> make Jason wince.
> 
> Well, okay, I'll admit it does.  I really appreciate the work you've
> done on this, Rob... this looks like lot of work, and tedious at that.
> 
> However, I still question the value of this type of merge.  I might be
> the only one who feels this way, but I think this is going to cost us a
> lot of time.  IMHO, it's much more productive to merge what's needed
> than to merge everything and then slowly figure out what isn't needed.

I think the steps look harder than it actually will be. The code base is 
rather small and huge chunks will be going away. We will end up carrying 
some cruft for a while but we can take another pass at it in the future.

> Aside from the issue of having to slowly remove depreciated code, I
> guess I see two possible approaches here:
> 
> We could:
> 
>         1. Merge v2 code into v1.
>         
>         2. Write a layer to glue the v1 code into v2 for features we are
>         missing in v2.
>         
>         3. Someday re-write the v1 code we are using or at least add
>         some badly needed unit tests (not to mention fixing various
>         Unicode/i18n bugs).

The only thing lacking unicode would be the installer and the current 
client. The only glue code needed is in getting things to build and 
install nicely together. It is really just a packaging issue.

All I'm really proposing is doing away with ipa-server and moving the 
few things we need into more logical places. ipa-admintools goes away 
easily. Simo wanted to keep the old client code so we need that and 
ipa-python. That is just about all there is.

> Or we could:
> 
>         1. Using the v1 code as a reference, quickly implement missing
>         functionality in v2, building this functionality up layer by
>         layer with good unit tests and correct Unicode/i18n behavior
>         from the get-go.
> 
> In this particular situation, I think the second approach will only take
> 25%-50% of the time that the first would.
> 
> Also, as far as I know, the only major piece from v1 that we're missing
> in v2 is the install/configure functionality.  Is this correct?  And
> this functionality really needs to be re-implemented to be
> plugin-friendly anyway.

There is also ipa-kpasswd, the DS plugins, the replication management 
tools (though they may be able to be done via the framework), some other 
misc tools, the basic client code and its library.

The installer is relatively modular now, it just lacks a way to 
automatically pick up new components and control the order of 
operations. IMHO it is adequate for now, despite being hardcoded. There 
are a lot of other things that we could be working on.

> And aren't we planning on moving the DS plugins into a separate tree
> anyway?

No, they are going to remain.

One of the goals of this was to retain as much revision history as 
possible. It now looks like git-mv drops history so it may well be just 
as easy to merge into Jason's tree the things we like from the v1 code 
rather than the other way around. I don't think the end-result would be 
much different though.

What I really want is to get this to a point very quickly where we can 
install and test the new XML-RPC engine in a full installation.

rob