CalvinKirs opened a new pull request, #65644:
URL: https://github.com/apache/doris/pull/65644
### What problem does this PR solve?
Kernel plugin families (filesystem, connector, authentication, lineage)
currently have no unified, queryable inventory: to know which plugins are
loaded on an FE, one has to read logs. This PR adds a unified
`information_schema.plugins` system table listing all successfully loaded
kernel plugins of the currently connected FE.
Columns: `PLUGIN_NAME`, `PLUGIN_TYPE`, `PLUGIN_VERSION`, `SOURCE`,
`DESCRIPTION`.
Design points:
- `(plugin_type, plugin_name)` is the primary key, enforced at load time:
the first registration wins and is never silently overridden, so a directory
jar can never displace a built-in plugin.
- `name()` / `description()` are snapshotted once at load time; querying the
table never executes plugin code. A broken self-report fails the load.
- Plugin names are validated at load (trimmed, non-blank, <=64 chars,
`[A-Za-z0-9._-]`); an invalid name fails the load for external plugins.
- `PLUGIN_VERSION` comes from the jar MANIFEST `Implementation-Version`
(NULL when unavailable), never from plugin interface methods.
- Only successfully loaded plugins appear; load failures go to logs. No
status/fail_reason columns.
- Querying requires global ADMIN privilege; non-admin users see no rows.
- View semantics are per-FE: the BE scanner RPCs the currently connected FE
(same pattern as `catalog_meta_cache_statistics`), so per-FE jar deployment can
be audited connection by connection.
Implementation:
- `fe-extension-spi`: add `default String description()` to `PluginFactory`
(empty by default, zero migration cost).
- `fe-extension-loader`: new process-wide `PluginRegistry` (load-time
snapshots only) and `PluginNames` validation; `DirectoryPluginRuntimeManager`
snapshots name/description and reads `Implementation-Version` from the jar
containing the factory class.
- The four family managers register BUILTIN/EXTERNAL rows; filesystem and
connector managers now also reject external providers whose name conflicts with
an already-registered one.
- FE: `SchemaTable` definition + `MetadataGenerator` data source; thrift
`TSchemaTableName.PLUGINS`. Reuses the existing MySQL-compat
`TSchemaTableType.SCH_PLUGINS`.
- BE: new `schema_plugins_scanner` wired into `schema_scanner`.
Example:
```
mysql> SELECT * FROM information_schema.plugins;
+-------------+----------------+----------------+---------+---------------------------+
| PLUGIN_NAME | PLUGIN_TYPE | PLUGIN_VERSION | SOURCE | DESCRIPTION
|
+-------------+----------------+----------------+---------+---------------------------+
| hdfs | FILESYSTEM | NULL | BUILTIN |
|
| jdbc | CONNECTOR | NULL | BUILTIN |
|
| oidc | AUTHENTICATION | 4.0.0 | EXTERNAL| OIDC
authentication |
+-------------+----------------+----------------+---------+---------------------------+
```
### Release note
Add `information_schema.plugins` system table listing loaded kernel plugins
(filesystem/connector/authentication/lineage) of the currently connected FE;
requires ADMIN privilege.
### Check List (For Author)
- Test
- [x] Unit test: `PluginRegistryTest`,
`DirectoryPluginRuntimeManagerMetadataTest`
- [x] Regression test:
`regression-test/suites/query_p0/schema_table/test_plugins_schema.groovy`
- Behavior changed:
- [x] Yes, new `information_schema.plugins` table (additive only).
- Does this need documentation?
- [x] Yes, `information_schema.plugins` should be documented as a new
system table.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
