Hi All-
With bundles now being neatly supported for add and remove, I think it
makes sense to use make the "bundle" a first-class concept in managing a
brooklyn catalog (type registry).
The basic idea is that users will work with ZIPs (or directories if
using the br CLI), where a "catalog.bom" is in the root; this is a
bundle, and operations like add/remove/update apply to the bundle.
Increasingly people are doing this for additions, so it seems pretty
obvious that delete should follow suit, and something like a "/bundles"
REST endpoint is appropriate.
You can still upload just a catalog.bom file; in this proposal it will
be wrapped in a bundle (internally, hidden from user). A bundle name
and version will have to be inferred/guessed for backwards
compatibility, and probably we should deprecate supplying a BOM which
doesn't define a bundle name and version.
If a ZIP/folder is supplied, it doesn't have to contain any OSGi bundle
definition; that call all be inferred. If a MANIFEST.MF is supplied,
any bundle name/version given there must of course match that in the
catalog.bom file. If dependent bundles are declared, they are obeyed at
runtime and can be used to find things (pretty much identically to how
we treat "libraries" in the catalog.bom.)
There are two subtle issues that arise:
* Versions - It would normally make sense for everything in a bundle to
have the same version number, viz. the version number of the bundle. We
don't need to enforce this, but I'm thinking we should deprecate and
WARN if this is the case because I don't think there's any compelling
reason to do otherwise. There is a question mark over what this version
should look like, because bundles must follow OSGi versioning and that
is different to strict semver and to the very casual "almost anything
you want" versioning style of maven and permitted by Brooklyn so far. I
wlll send a follow-up thread on this topic.
* Search Paths - Bundles fix an issue where types have implicit version
dependencies. Consider an "acme-cluster" of "acme-node" entities,
defined in a bundle. If I release a 1.0 version of this, and then a 2.0
version, I'd probably expect the 1.0 acme-cluster to load 1.0 acme-node
entities, and same for 2.0. But currently any reference to "acme-node"
takes the latest version, even if there is a different version in the
same bundle. Shifting to bundles, I think we should change this, so
that versions of items in the same bundle (or on the OSGi or library
search path for that bundle) are preferred over more recent versions in
the repository. (And since we will follow OSGi loading, we can also, if
we need to, use OSGi config to say that "acme" bundle requires a given
version _range_ for some other bundle, to have more control over
dependency versions when required.)
For most users and blueprints this will cause no changes. However there
are some changes to note:
* If people have been sloppy with versions or metadata, in most cases
they will get a warning
* In some cases if uploading a ZIP, the catalog.bom may need to be
edited (the upload will give a clear error, and it should not expect rebind)
* When a type is referenced with no version, the loading semantics may
change if that type is in the same bundle (this is probably what the
user expects)
Does anyone oppose any of the above, or have further questions?
Best
Alex
[1] https://github.com/apache/brooklyn-server/pull/672
