You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The common.messaging abstraction should discover common messaging
queue providers using the same mechanism as we have for other core
extensions. Previously common.messaging had the optional (but not
really) dependencies to other providers, but that was not needed
and introduced unnecessary coupling.
By switching to our built-in discovery mechanism we get immediately
all the niceties of provider discovery mechanisms:
* queue is provided by the actual provider where the service or
integration already is implemented (sqs -> amazon provider, in
the future kafka -> kafka provider)
* queues are discovered from installed providers
* there is no coupling or imports between common.messaging and the
providers that implement messaging, the dependency is in the other
way - providers that implement messaging depend on common.messaging
* airflow providers queues CLI and providers core extensions
documentation is automatically generated
Copy file name to clipboardExpand all lines: airflow-core/src/airflow/provider.yaml.schema.json
+12
Original file line number
Diff line number
Diff line change
@@ -467,6 +467,18 @@
467
467
}
468
468
}
469
469
},
470
+
"queues": {
471
+
"type": "array",
472
+
"description": "Message Queues exposed by the provider",
473
+
"items": {
474
+
"name": {
475
+
"type": "string"
476
+
},
477
+
"message-queue-class": {
478
+
"type": "string"
479
+
}
480
+
}
481
+
},
470
482
"source-date-epoch": {
471
483
"type": "integer",
472
484
"description": "Source date epoch - seconds since epoch (gmtime) when the release documentation was prepared. Used to generate reproducible package builds with flint.",
0 commit comments