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)
Hi Mike,
Exciting news! My initial thoughts are scattered below.
On 06/01/2015 10: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)
I'd also ask for the ability to migrate packages from one namespace into another - effectively replacing the one that exists there currently.
• 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
Depending on what you mean by this, I've wondered if kojira could be replaced by a post action hook.
= Yet more changes =
• store all task requests by named args ∘ (for ease of inspection) • get rid of tagBuild tasks
For the SL koji, I've a plugin that triggers off of tagBuild to run some tests. While I'm not tied directly to the tagBuild itself, I am tied to "I finished building any package successfully against tag X".
• 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)
May I also request Database Schema migration? Some other open source projects (django 1.8, wordpress) have frameworks for allowing the application to maintain its own schema. I suspect this may simplify new installs and version upgrades.
On 06/02/2015 09:37 AM, Pat Riehecky wrote:
Hi Mike,
Exciting news! My initial thoughts are scattered below.
Indeed :D
On 06/01/2015 10: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)
I'd also ask for the ability to migrate packages from one namespace into another - effectively replacing the one that exists there currently.
Yes, that is part of the plan.
An open question is whether is makes sense for a build to be able to occupy multiple namespaces at the same time. I would be very interested to hear about possible use cases from the community.
It should also be possible for a build to not occupy a namespace (null namespace). Scratch builds would likely become such null-namespace builds.
• 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
Depending on what you mean by this, I've wondered if kojira could be replaced by a post action hook.
At the moment, kojira doesn't handle garbage collection (that's the koji-gc utility), but I think kojira can evolve into a more general server side daemon.
I would like to push more of both gc logic and repo regen logic into hub side triggers and/or more specialized calls.
= Yet more changes =
• store all task requests by named args ∘ (for ease of inspection) • get rid of tagBuild tasks
For the SL koji, I've a plugin that triggers off of tagBuild to run some tests. While I'm not tied directly to the tagBuild itself, I am tied to "I finished building any package successfully against tag X".
You should still be able to trigger off of tag events on the hub side.
What sort of tests do you run and how expensive are they?
I think very involved testing is better accomplished with automated tagging workflows (e.g. build into a -candidate tag, promote to base tag).
• 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)
May I also request Database Schema migration? Some other open source projects (django 1.8, wordpress) have frameworks for allowing the application to maintain its own schema. I suspect this may simplify new installs and version upgrades.
I need to look into this. I do not want to use Django, but I know several projects use Alembic.
On 06/02/2015 11:51 AM, Mike McLean wrote:
May I also request Database Schema migration? Some other open source projects (django 1.8, wordpress) have frameworks for allowing the application to maintain its own schema. I suspect this may simplify new installs and version upgrades.
I need to look into this. I do not want to use Django, but I know several projects use Alembic.
I do hear good things about Alembic[1]
Pat
Link provided for those having issues finding it [1]https://bitbucket.org/zzzeek/alembic
On Mon, Jun 1, 2015 at 10:43 PM, Mike McLean mikem@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
On 06/02/2015 10:07 AM, Adam Miller wrote:
On Mon, Jun 1, 2015 at 10:43 PM, Mike McLean mikem@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?
Not a complete rewrite, more of an extreme refactor. Koji does a lot of things well and I don't want to lose the good parts. Some areas will see major changes, others less so. Also, I expect to move a lot of code around so that it is more sensibly organized.
On 06/02/2015 11:43 AM, 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
better tests and improve the test coverage. better reports.
= 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
refactor db access api, introduce an ORM (SQLAlchemy for example) to simplify the code writing too much raw DB-API invocations and SQLs. However, whatever ORM is adopted, it must be careful to use, or it may hurt the performance easily.
= 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)
-- buildsys mailing list buildsys@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/buildsys
Regards, Chenxiong Qi
On 06/01/2015 10: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 thought of a few more "extras" I'd like to propose: - kojid plugin sync kojid has a plugin architecture, it would be nice if the hub could say "Hey, you should have these plugins" and kojid could then fetch them over some kind of API
- "fewer" settings within the koji-hub.conf (or any koji config) I'd love to see nearly any setting that can be set, being set over an API and stored in the database. Mostly that makes it easier for me to backup and restore the database in a disaster.
On Tue, Jun 2, 2015 at 4:43 AM, Mike McLean mikem@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
On Jun 07 14:44, Peter Robinson wrote:
On Tue, Jun 2, 2015 at 4:43 AM, Mike McLean mikem@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
koji-devel@lists.fedorahosted.org
-
Adam Miller -
Brian Stinson -
Chenxiong Qi -
Mike McLean -
Pat Riehecky -
Peter Robinson