Roadmap

This document describes some plans for the future of Greenwave. Items are listed in approximate order of importance.

Support for STOMP messaging

Like WaiverDB, we want to use Greenwave in environments which have a STOMP-compatible message bus (#107).

Per-package policies

The Greenwave focus document anticipated the need for per-package policies, as a way for package owners to opt in to extra checks. Therefore it was considered a low priority in the first implementation of Greenwave.

However, it turned out to be more important as a way to opt out of certain checks. For example, certain packages are too large to be tested by abidiff (see pull request 95). And the new Fedora CI Pipeline is only testing a small (but growing) subset of packages in the distribution (#61, #75).

Greenwave currently contains short-term solutions for both of those problems, but a more general way of expressing policies for specific packages is desired.

Finding the right value for “subject”

Greenwave is intentionally unaware of the meaning of the different keys and values making up the “subject” of each decision.

In the HTTP API, it is up to the caller to supply a suitable set of key-values describing the “subject” and Greenwave uses these as is to look up results in ResultsDB.

However this does not naturally translate into a message-driven asynchronous interface. When Greenwave receives a message about a new result or a new waiver, there is no clear way to determine which subset of the key-values make up the “subject” that consuming tools are interested in (#92).

And the design also led to some ambiguities when Bodhi needs a decision about an update which also consists of a set of builds (#68, #74).

It may be necessary to come up with a different design for how Greenwave and its consuming tools identify the “subject” of a decision.

User-defined policies

Greenwave currently represents policies as YAML configuration, which made the initial implementation very easy. However there is a downside: changing the policy effectively means changing Greenwave’s configuration. In the case of Fedora’s Greenwave deployment, this means patching Ansible roles (potentially with a freeze break exception), running a playbook to apply the configuration, and then having OpenShift re-deploy all pods.

As Greenwave becomes integral to the release process, we expect that users will be interested in defining their own policies. Here, “user” may mean people like distro QA representatives, product managers, or individual package owners. Every small tweak to the policy should not require the involvement of sysadmins.

This is related to the “per-package policies” item above. One possible way to support per-package policies is to make Greenwave consult a YAML policy file in the dist-git tree for each package when it makes a decision. Distro-wide policies would remain in Greenwave’s configuration. This design may be enough to satisfy this need for user-defined policies.

Another option is to replace the current YAML format for policies with a database representation, and provide an HTTP API, CLI, and web UI for viewing and updating policies.