rhuss
commented
5 years ago The idea is that CRs only populate
spec, as is typically done. We are hacking the CRD to include additional info for registry purposes, but we do not expect users to configure in their CRs theregistrysection. I added a description there saying something like: "Internal information for registry purposes. Users should not set this property"
tbh, that is indeed very hackish and totally confuses types with values. Also misusing the openAPI "pattern" field to be used as concrete values does not feel right. According to the openAPI documentation pattern "SHOULD be a valid regular expression, according to the ECMA 262 regular expression dialect" (so e.g. "." should be escaped if they are meant to be dots like in google.storage.object.archive) and its purpose is according to the schema validation specification :
5.8. pattern
The value of this keyword MUST be a string. This string SHOULD be a
valid regular expression, according to the ECMA 262 regular
expression dialect.
A string instance is considered valid if the regular expression
matches the instance successfully. Recall: regular expressions are
not implicitly anchored.Although it's only a recommendation (SHOULD), I wonder why we wouldn't follow that. Also, the purpose of this field is for validation of a given value, not as a value for itself.
To be honest, I would expect a cleaner design for an official API and not marking parts of a CRD as 'internal' via documentation and re-intepreting an openApi schema. Why not choosing a new entity which contains a CRD and the event-type values as two distinct objects as properties (like eg more or less a ClusterServiceVersion managed by the Operator Lifecycle Manager does) ?
Only because something is technically possible doesn't mean it should be (mis)used for any purpose.
gcsCredsSecret: name: my-key key: key.json
How would this be translated to the CLI ? like in --arg gcsCredsSecret='{name:"my-key", key:"key.json"}' ? and the client trying to parse the argument as json and putting it as value into the gcsCredsSecret field ?
This might work in this simple example, but for more complex sources (as mentioned the Camel source comes to mind), I'm afraid that this quickly becomes ugly, leading to huge CLI command lines which not much benefit over having plain yaml files.
matzew
n3wscott
nachocano
grantr
sixolet
knative-prow-robot
Problem In working through #1381 one of the key things that we have found when targeting the user experience is that discoverability is highly important. For motivations, we look to the Scenarios for Knative Eventing.
To recap the 3 scenarios describe there
FaaS - directly connect an importer (specific instance) to a consumer
Event-Driven - current implementation of Broker + Trigger
Black-box integration - scenario 3 is a specialization of both scenarios 1 and 2. From a developer’s viewpoint, consuming events is just like scenario 2 (Event-Driven) in that if an event is available on my cluster, I am able to trigger off of it.
The current registry implementation is event type centric (the CRD is literally called EventType). This works really well for scenario 2 (on-cluster, event-driven scenario) and scenario 3 (black-box integration).
This works less well for scenario 1 (FaaS) because it makes discovery of events via source more difficult to build. This doesn’t mean that the existing registry is wrong our less useful. There is currently one entry in the registry per event type, this is actually a tuple of Source and Type.
We propose introducing a new importer registry.
This gives the overall registry 2 components working together to facilitate discovery and configuration of events. The importer registry will be responsible for informing a user (and tooling) of which producers they may solicit what events from and how to configure those importers.
When an importer is configured, the importer is responsible for populating the EventType appropriately.
As a concrete example, the importer registry tells me that I can get Google Cloud Storage “finalize” events by instantiating the GCSSource kind. If two GCSSource objects are created for finalize events, the finalize event type should only appear in the EventType registry once. The EventType should reflect which importers are providing that type (can be an annotations, status, etc. to be designed).
Persona: Event Consumer
Exit Criteria A CLI can be written that can programmatically discovery and configure importers.
Time Estimate (optional): 5d