+1

Worth noting that this is fairly significant access change. Root on hub (currently required to change policy) is much stricter than admin perm in koji. This is not necessarily a problem but something to think about.

While the policy parser is deliberately limited and should be safe (good unit test coverage even), it is still effectively parsing and executing text. We need to be certain before we open that up via a routine api call.

Making it easier to change policy also makes it easier to break Koji, so we may want to add more safeguards in along with this.

There are a couple ways we might implement this. We could create a new table to store the policy, or we could go more generic and call it a hub config table (though we really don't want to open up all of hub config via the api). Another option would be to store such config in special builds inside a tag.

The policy data is complex, so we wouldn't be able to capture much of its structure in the schema. Likely we'd just have each policy as a big text value.

Either way may want some short cache interval. I don't think we want to check for policy updates every call.

How about a "policy version" integer that's incremented on every update to the policy? If it's not equal to the last time we checked policy version, reload the policy. Integer checks are cheap, and we avoid any complex caching logic.

How about a "policy version" integer that's incremented on every update to the policy? If it's not equal to the last time we checked policy version, reload the policy. Integer checks are cheap, and we avoid any complex caching logic.

If we did it in the db, then I think I'd want the table to be versioned, so we'd just use the event id.

If we did it with a "config build" in a special tag, then we'd just be checking for updates to that tag.

Separate build isn't probably much better than what we have today. Instead of deploying script to prod, building of special rpm is still needed which takes some time. So I would like to create API for that with storage in database. Part of the call should be running tests we currently use before deploying policy.
Furthermore, test will be better as they'll be run on hub, so they will use all plugins configured there.
Should we think about more granular admin/supersuperuser permissions? Maybe in relation with #327 ?

If we used a separate build, it would probably not be an rpm, but a new btype that contains just the config file and is created via cg import.

...but yeah, might be overloading builds a bit much

Part of the call should be running tests we currently use before deploying policy.

Sure, we can do very basic validation, but it's easy to imagine folks wanting custom validation here. There could be interaction with plugins, or other infra.

Should we think about more granular admin/supersuperuser permissions?

I think so.

dropping for now