How to de-register a runtime?

[duongnt]

Elyra comes with Airflow and KFP by default, however I'd imagine a lot of organizations only use one of those or something else. Having an Airflow pipeline editor in the launcher when it's not supported at all is very confusing for end users.

Right now it's not obvious to me how to remove a runtime, for example Airflow if we're not using it.

[kevin-bates]

Thank you for starting this discussion, this is a good question.

Right now, I suspect you'd need to go to your elyra package installation location and actually remove elyra/metadata/schemas/airflow.json (or perhaps better, update the namespace reference to something bogus). You'd also have to repeat that step on each subsequent upgrade. 👎

With BYO schemas, you'd simply uninstall the runtime provider package except when that provider is Elyra. As a result, I think we'll need to add a configurable, list-valued trait, named something like active_runtimes. The SchemaManager would still walk the entrypoints but could skip the load if the entrypoint name (i.e., the schema name) is not in the list of configured active_runtimes. This would also be a bit more friendly in shared environments in which other runtime packages may need to co-exist.

Actually, this is backwards because the SchemaManager should not be aware of any such configuration or schemaspace name - especially if we make the metadata service its own separate server extension. Therefore, I think the SchemaManager should go about its business relative to what schemas to load and, instead, let the PipelineProcessorRegistry be the thing that uses the active_runtimes trait to determine which runtime processor to load.

This would imply a few things:

1. The front-end runtimes editor gets its runtimes schemas from the Pipeline service rather than the Metadata service. These might as well live on the PipelineProcessorRegistry.
2. We should add schema_name as an abstract property on RuntimePipelineProcessor. This way, the PipelineProcessorRegistry can walk its list of configured runtime processors to get a list of schemas. This also prevents us from having to require that Runtimes schema names must match the registered RuntimePipelineProcessor entrypoint name. (although we already implement the built-in processors this way - that is, their "type" matches the schema name).
3. Site admins need to be aware of what runtimes are to be supported (as they should be already) so as to set the active_runtimes configurable trait correctly.

Thoughts?

[ptitzler]

This should be resolved when #2259 is merged (~ Elyra v.3.8.0)