Separating Conforma from Konflux

[adambkaplan]

The current state of Conforma is tightly coupled to Konflux, which is not surprising given this project's origins and history. As a result, most if not all of the current documentation assumes that Conforma and its tools (ec, the EnterpriseContract custom resource, and the newer KNative Conforma controller) are utilized as part of a Konflux deployment.

The situation is even worse for the current policy catalog. The current collection for the most part assumes data is generated from Konflux using specific pipelines and processes. The catalog even includes policies that are specific to an individual corporate entity - Red Hat. As a result, it is exceptionally difficult for a new Conforma user to design policies for artifacts that are not built on Konflux.

I would like to propose that Conforma as a project separate its identity from Konflux, and treat it as an adopter. I suggest the following:

• Removing refernces to Konflux in the current Conforma documentation
• Treating the policy repository in Conforma to become a general-purpose policy library for the community, which can be "imported" through a defined procedure (is this feasible?).
• Reconsidering the design of any controllers or CRDs such that they can exist independently of Konflux.

I think would also help if policies document their expected inputs, since it is not clear what many current policies require as input.

[simonbaird]

💯

Yeah, totally agree.

[lcarva]

Agree! This is long overdue.

I'd like to add to the list the input to the ec validate image command which is currently in the format of a SnapshotSpec. I don't think there's anything wrong with that format, but that is another dependency on Konflux. Maybe we can come up with a self-containing format that is compatible with that one, or, even better, use a well-adopted standard format (which may not exist).

[ggallen]

Maybe this would also be an opportunity to update or change any old "Enterprise Contract" or "ec" references to reflect the new name of Conforma.

For example, the EnterpriseContractPolicy CRD could become ConformaPolicy or simply Policy (which gets my vote).

[simonbaird]

Yeah, I think that's also a good idea. We intentionally delayed the renaming of the CRD until after all the other renaming efforts were completed, but now I think it's time.

[adambkaplan]

Should "de-coupling" this CRD + controller from Konflux also be considered in scope?

[arewm]

I think would also help if policies document their expected inputs, since it is not clear what many current policies require as input.

I talked with @lcarva about a topic related to this some time ago. What I feel like would be even better is if the expected inputs were specified in a way so that they could be retrieved independently of the policy evaluation. Then those inputs could be passed to the policy evaluation in addition to the images themselves.