Hi Brooklyners,
Since the Catalog was overhauled many years ago with the TypeRegistry
approach, we have had support in the back-end for custom types and for
custom plan formats. The former is useful e.g. if you want to add a new
type to be used as a config key or initializer. The latter is useful if
the usual entity-centric CAMP YAML isn't the native format. The latter
is extensible, using the TypePlanTransformer OSGi service at runtime, so
new bundles can register services to support new format types -- e.g.
TOSCA, Kubernetes, pick your poison. The only requirements are that the
service register the type saying what its supertypes are and is then
able to instantiate it when requested (using whatever it wants,
including calling to a CLI or REST endpoint). We've also added a
BeanWithType transformer (specify "format: bean-with-type" in the
catalog BOM) to use simple POJO/Jackson YAML deserialization, which has
been really useful for Initializers.
There are two related features that would complete this nicely:
* Offer a similar extensible approach to resolving the overall
artifact/bundle added to the catalog: currently _within_ the
catalog.bom file one can define the format for items, but the BOM YAML
format is required, and there is a simple try/catch to allow upload of
just a BOM YAML or a ZIP which contains either catalog.bom or OSGi
metadata (or both); having an extensible "services" mechanism for
scoring and resolving catalog bundles would allow Apache Brooklyn to
handle other items being added to the catalog in their native format
with no extra metadata. Similar to TypePlanTransformer, the e.g.
BundleInstallResolver would be responsible for scoring its applicability
and adding the items to the catalog. It could lean on the existing
catalog.bom format to do so, or it could replace that with its own
reading of what items are within the bundle. For instance a
BundleInstallResolver could accept a Dockerfile or a Helm Chart or a
TOSCA CSAR or a CloudFoundry project, and make it known within the catalog.
* On the REST API, when deploying or adding to catalog, add an argument
so that the caller can specify the format of the artifact being deployed
or added to the catalog. This will link one-to-one with: for
deploying, the TypePlanTransformer; and for adding to catalog, the (new)
BundleInstallResolver. By default auto-detect will operate, asking
services to score their applicability. (eg. if it's a ZIP with a
catalog.bom the current OsgiArchiveInstaller will score 1.0, if it's
OSGi but no catalog.bom then score 0.2.) Currently, deployment will use
auto-detect against all TypePlanTransformers, with no way on the API to
specify a format. And for adding to catalog, it is only the BOM YAML or
ZIP-with-BOM-and-or-OSGi formats that are supported.
I think this could go a long way to making Apache Brooklyn more
accessible, because with just a small code investment, the software can
then support potentially many other existing deployment formats,
reducing (removing!) the need for a consumer to learn the Apache
Brooklyn syntax for plans and bundles.
I propose to work on the above and welcome any thoughts from the community.
Once the API is updated it would be good to add a CLI argument to
support this. I might could do with help here!
Best
Alex
