kaxil commented on PR #62816:
URL: https://github.com/apache/airflow/pull/62816#issuecomment-4001132383
Good question — and I think we should go further than just extras. The right
approach for Airflow is **separate connection types** for the cloud providers
that need distinct credentials.
Airflow's connection form doesn't support conditional fields (no way to
show/hide fields based on a dropdown). But it does have an established pattern
for this: the Google provider ships 5 connection types
(`google_cloud_platform`, `gcpcloudsql`, `gcpcloudsqldb`, `gcpbigquery`,
`dataprep`). Amazon ships 5 (`aws`, `chime`, `emr`, `redshift`, `athena`). Each
has its own hook subclass with tailored form fields.
We should follow the same pattern:
| Connection Type | Covers | Form Fields |
|---|---|---|
| `pydanticai` | OpenAI, Anthropic, Groq, Mistral, Deepseek, Ollama, etc. |
API Key, Base URL (optional), Model |
| `pydanticai_azure` | Azure OpenAI | API Key, Azure Endpoint, API Version,
Model |
| `pydanticai_bedrock` | AWS Bedrock | Region, Profile Name, Model |
| `pydanticai_vertex` | Google Vertex | Project, Location, Model |
Each connection type is a hook subclass that overrides `conn_type`,
`get_ui_field_behaviour()`, and the credential-to-provider mapping. Users pick
the right connection type, see only the relevant fields, and everything just
works.
The generic `pydanticai` type covers most providers — anything that accepts
`api_key` + `base_url`. Only the 3 cloud providers with non-standard auth get
their own types.
Implementation-wise, each subclass is small:
```python
class PydanticAIAzureHook(PydanticAIHook):
conn_type = "pydanticai_azure"
hook_name = "Pydantic AI (Azure OpenAI)"
@staticmethod
def get_ui_field_behaviour() -> dict[str, Any]:
return {
"hidden_fields": ["schema", "port", "login"],
"relabeling": {"password": "API Key", "host": "Azure Endpoint"},
"placeholders": {"host": "https://myapp.openai.azure.com/"},
}
```
The provider-specific credential mapping lives in an overridable method on
the base class. No if/elif chains, no `inspect.signature`, no generic extras
dumping.
This is a clean follow-up PR after the base hook lands — it doesn't need to
block Azure support in this PR. For this PR, the explicit Azure branch in
`_provider_factory` is fine as a first step. The separate connection types are
the proper long-term solution.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
