Koji 2.0 planning

Adam Miller maxamillion at fedoraproject.org
Tue Jun 2 14:07:12 UTC 2015


On Mon, Jun 1, 2015 at 10:43 PM, Mike McLean <mikem at redhat.com> 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.

This is extremely exciting! Thanks for kicking off the discussion.

I was curious if there are any thoughts on the topic of whether this
would be a complete rewrite or continued iteration on the current code
base?

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

+1 to everything! Looking forward to having these items (and possibly
more as the conversation continues) hashed out so people can start
working on them! :)

-AdamM

>
>
>
>
> --
> buildsys mailing list
> buildsys at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/buildsys


More information about the koji-devel mailing list