[Freeipa-devel] tree reorganization proposal

Wed Jan 28 20:34:15 UTC 2009

On Wed, 2009-01-28 at 14:54 -0500, Rob Crittenden wrote:
> 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.

We should rename ipa-python to ipapython or ipa_python and put it in the
root of the tree so the client installer can import it in-tree.

> > 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.

Oh, I guess I was confused on this.  I thought they were being moved to
another tree.

> 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.

Come to think of it, this makes sense that git-mv doesn't retain the
sort of history you're looking for as git doesn't have real support for
renames (because its version-controlled files don't have a unique id
that persists throughout revisions and renames).  AFAIK, a rename in git
is really just deleting one file and then creating another with the same
content.  Off topic, but score another point for Jason's favorite DVCS
(which does have real rename support)!  ;)

> 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

I'm certainly on the same page here with you.  I'll flesh out setup.py
so it's ready to go.

There are details of the v1 tree I don't understand, so, like you said,
maybe what you're proposing isn't as difficult as it seems to me.

Let me know what else I need to do on my end to get things installable
ASAP.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20090128/7cf48956/attachment.sig>