[Freeipa-devel] FreeIPA Copr repo plan

[Jakub Hrozek]

On Mon, Nov 10, 2014 at 12:07:46PM +0100, Martin Kosek wrote:
> Hi guys,
> 
> Some time ago we started managing FreeIPA Copr repos (mkosek/freeipa) with a
> target to have the latest greatest FreeIPA available for older arches (read -
> RHEL/CentOS) and to allow people using older stable Fedoras (read - Fedora 20)
> try FreeIPA 4.0+ releases which brought in several dependencies.
> 
> So far this was a more ad hoc approach, I think a more firm plan and tools are
> due. I see several questions that needs to be decided:
> 
> 1) What Copr repos do we want to maintain and what should be the expectations?
> My take:
> 
> a) mkosek/freeipa: latest and greatest *released* FreeIPA. Built for F20+,
> EPEL-7.0. Jan, this is the one you use in the FreeIPA CentOS container, right?
> Does it fit your needs?

+1

> 
> b) Branch repos: as mkosek/freeipa Copr repo would contain only the latest and
> greatest release, would it make sense to have a Copr repo with *releases* per
> supported branch to give users a choice? I.e.
> * mkosek/freeipa-4.1
> * mkosek/freeipa-4.0
> These repos are there already, but not used consistently. I do not think we
> should build all the dependency chain (too much overhead) for older systems
> (F20/EPEL). But I assume we could at least build the freeipa SRPM itself for
> these systems if it uses "mkosek/freeipa" as additional build root in Copr.

Is it worth it? Is the older supported branch some kind of LTM or just
happens to be alive because of some Fedora or RHEL release using it?

I think there is value in providing early access to RHEL/CentOS users
prior to dumping the RPMs onto them, but maintaining the repos is hard,
I think we should only commit to this work if there is a use-case.

> 
> c) Daily repos
> Should we deprecate old John's repos
> (http://www.freeipa.org/page/Downloads#Bleeding_Edge) which is difficult to
> maintain and replace them with Copr ones? I.e. to have common repo (e.g.
> mkosek/freeipa-daily) built for the supported Fedoras (F20, F21, rawhide ATM)
> including dependencies?

Is there a build script or other infrastructure that would make the new
repo easy to maintain (easier than John's repo)? In general I think there
is quite a bit of value in the daily builds -- we can ask users if their
problem goes away with the latest builds and we could even use this for
some CI setups and we know early if something breaks.

> 
> Should it contain daily master builds for all tracked projects (FreeIPA, SSSD,
> 389 DS, bind-dyndb-ldap)? Or do we simply want to let distribute it across
> projects "mkosek/freeipa-master", "someone/sssd-master",
> "someone/389-ds-base-master? Second option may scale better better, the list of
> such repos may be maintained somewhere (freeipa.org wiki).

I think I might be missing something, but why do you think separate
repos are better?

> 
> 
> 2) We will need to have some tool chain and Jenkins CI jobs watching these
> repos to make sure the build & run deps are OK. So far I used the attached 2
> clumsy bash scripts to handle the repos build and one for analysis. But we will
> need something better.
> 
> 
> 3) Scalability of the approach
> Some dependencies are more difficult to maintain than the others. Especially
> the PKI ones often required custom Java packaging (resteasy-base) or a
> complicated dependency chain (the latest jackson-jaxrs-json-provider). It would
> be great if PKI team helps with this effort, as Lukas proposed. Downside is
> that mkosek/freeipa installation would require 2 Copr repos. But maybe we could
> have a job syncing the PKI build/runtime dependencies directly to FreeIPA copr.
> Whatever works and scale.

I thought you could 'include' one repo in another with COPR? Wouldn't
that solve the problem?