Koji 2.0 planning

Peter Robinson pbrobinson at gmail.com
Sun Jun 7 13:44:50 UTC 2015


On Tue, Jun 2, 2015 at 4:43 AM, 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.
>
> 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

I'd like to add to this more granular access control, groups etc. It
would be great if every task could be assigned groups and each group
could be given things like Read, Execute, Execute scratch, Delete, Tag
etc style of ACLs.

One of the requests we get on occasion is the ability for someone to
run image scratch builds, at the moment to do that you need to be
admin as there's no ability for non admin to do image builds, but we'd
likely want enough granularity to differentiate between scratch versus
official builds.

Peter


More information about the koji-devel mailing list