Koji 2.0 planning

Brian Stinson brian at bstinson.com
Sun Jun 7 13:49:33 UTC 2015


On Jun 07 14:44, Peter Robinson wrote:
> 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.

+1

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

Read/NoRead ACLs would nicely enable people doing builds of sources under embargo. 

> 
> Peter

--Brian 


More information about the koji-devel mailing list