Koji 2.0 planning

[Jay Greguske]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/01/2015 11:43 PM, Mike McLean wrote:
> It's been eight years since koji 1.0. In that time Koji has grown a
> lot, but always incrementally and with great care to avoid
> breaking compatibility. Over the years, we've found numerous things
> that we wanted to add or change, but that we dismissed as too big,
> too complicated, or too invasive.
> 
> Bumping the major release number gives use the freedom to shake
> things up a bit. Koji 2.0 is about making major changes, otherwise
> it would just be koji 1.13.
> 
> Koji 2.0 will take some time. We will maintain Koji 1.x until 2.0
> is sufficiently stable. Some features (e.g. content generators)
> will also appear in 1.x.
> 
> The list below is probably not complete, it is ambitious, and it
> is certainly open to discussion. If you are a Koji user, or
> otherwise invested in Koji, then you are encouraged to join in. I
> expect there will be a lot to say, so I've created a new mailing
> list devoted specifically to Koji development.
> 
> https://lists.fedorahosted.org/mailman/listinfo/koji-devel
> 
> Also, apologies for the tense summary listing. I can certain
> expound on any of these as necessary. I hope this suffices to start
> some conversation.
> 
> 
> = High level goals =
> 
> • better documentation • more community involvement •
> refactor/modernize code • more modular design ∘ content generators 
> ∘ broader, better plugin framework • better support for different
> types of build processes • better support for for different types
> build output • make hard-wired restrictions more configurable •
> easier to deploy • better qa process • better release process
> 
> 
> = Highlights/Major changes =
> 
> • python3 support ∘ the bulk of the code will target python 2.6 +
> python-six ∘ we'll create a basic client lib for older systems (e.g
> rhel5 clients/builders) • drop xmlrpc in favor a json based rpc •
> build namespaces ∘ allow for use cases that require multiple builds
> of the same NVR (or NVRA) • refactor task scheduling • extend
> content generator support ∘ content generators will land in 1.x
> fairly soon, but in 2.0 they will be more integral ∘ refactor kojid
> to use content generator calls ∘ (possibly) tighter integration in
> the db • unify handling of rpms with other build types in the db ∘
> e.g. unify rpminfo and archiveinfo tables • support different ways
> of building (possibly via content generators) • utilize jsonb
> fields in postgres • modular auth ∘ make it easier to add new auth
> mechanisms ∘ support openid auth • improve plugins ∘ make the
> plugin framework cleaner and more pythonic ∘ support plugins in cli
> and web ui • improve/update web ui ∘ drop cheetah templates in
> favor of python-jinja2 ∘ more parity with cli ∘ history browsing ∘
> landing page search or history ∘ support plugins • change how tag
> pkglists (and blocking) work • refactor package ownership •
> refactor uploads • more flexible gc
> 
> = Yet more changes =
> 
> • store all task requests by named args ∘ (for ease of inspection) 
> • get rid of tagBuild tasks • drop odd event refererences in favor
> of timestamps • streamlined cli options • marker files for many
> things on disk • more history data • drop modpython support •
> policy code ∘ more robust syntax ‣ test negation ‣ OR ‣
> parentheses ‣ quoted strings ∘ multiple result policies
> (non-terminal actions) ∘ all-matches policy (needed for
> scheduler?) ∘ break action (breaks out of nesting) ∘ stop action
> (halts processing of an all-matches policy)
> 
> 

I would like to see 2 features in Koji:
- - know how to build installation media
- - managed signed repositories of RPM content

If those existed, and we overloaded the use of package groups with
comps data, that would virtually eliminate the need for mash, pungi,
distill, and puddle. A compose would become a series of brew commands
to write out signed repos and installation media.

Is that an oversimplification, or a real goal?

- - Jay



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQEcBAEBAgAGBQJVjDvpAAoJEMzORChHoQ3ag1MIAJGmahWzC5Jn0M3PhFV7IRFX
AU3pgJ4m7LF01tfBYkRZhsTnK3IMQqWhh11RoTB9OkwqsLZu7T0JHbHYVoZW5hWo
DjWG/9DDVDEXIRbs3yolyBWbmVFfrkbeIs0yLc5oQeZpBhfUY2gkjcTzvuK41CrC
dDK0LMiywJSnRiO+TH6s7PSnDgr06mgzALD6keue/e+rC9QXcZ95AiLqCFKKVTnT
x7s4JJNVXt1llU/0odw7ZD207NaAw534TljdfjO2Le3g/ZeiEUhfTSn3jsmnLGPK
R6wzRfuWxMTj7SpkjiUsaQ/xVW7qQRmQ+++fbf7LlIfkKykSe3Qg7fOotTW9GBQ=
=mM3r
-----END PGP SIGNATURE-----