Alternate brokers need alternate ConditionSets for Broker and Trigger

[grantr]

Problem
When implementing an alternate broker, we need to add/remove conditions to the ConditionSets on Broker and Trigger to reflect the characteristics of the alternate implementation. Currently ConditionSet is an unexported variable so it can't be modified for alternate implementations, requiring workarounds.

I know of two workarounds and neither are great:

• Ignore the standard ConditionSet and lifecycle methods, and create new ones that take the object as a parameter. This makes it harder to share code and leverage features like Switch KRShaped interface to retrieve entire condition set pkg#1307.
• Create a new Go type with its own ConditionSet. This makes the lifecycle interface consistent, but requires duplicating a ton of code that will be hard to keep in sync.

Solutions that could work better:

• Export the ConditionSet variable and replace it at init time with the desired one. This is fine when there's only one Broker class being reconciled per container, but doesn't work if there are two classes in a container.
• Inject the proper ConditionSet into the queued resource before reconciling. This is probably the "right" solution. The class-aware generated reconciler would have to understand what ConditionSet should be used.

/cc @n3wscott @whaught

[vaikas]

https://docs.google.com/document/d/1LFE4IwQ7yj6zjO7qwMSXDRfPk8ll9hSk6uCh2Xx--AE/edit#

If we do something like "inject proper condition set", do you foresee still needing something like proposed in that document?

[grantr]

Related but orthogonal. This issue is about how to manage the relationships between the broker's conditions. Fixing it doesn't add any new capabilities to the API. It would still be useful IMO for broker controllers to be able to set implementation-specific status information beyond condition status.

[vaikas]

Ack, that was my read as well, but wanted to check 👍

[pierDipi]

I'm interested in working on this.

For now, I would go ahead with: (1)

Export the ConditionSet variable and replace it at init time with the desired one. This is fine when there's only one Broker class being reconciled per container, but doesn't work if there are two classes in a container.

And as a longterm goal building this: (2)

Inject the proper ConditionSet into the queued resource before reconciling. This is probably the "right" solution. The class-aware generated reconciler would have to understand what ConditionSet should be used.

What do you think?

/assign

[pierDipi]

A solution to:

doesn't work if there are two classes in a container.

might be a map brokerClass -> ConditionSet and in GetConditionSet() apis.ConditionSet we return a ConditionSet accordingly.
Might it work?