Richard-
Good points. To your questions:
> Is it necessary to always wrap stuff in a bundle?
No, and currently we don't. But I think the model becomes clearer if we
do, all catalog items (registered types) are contained in a bundle.
Note that this gives us a way to preserve an uploaded `catalog.bom`
which currently we do not have.
> Can the version number be omitted from all places except once?
Yes, I think this should be the case.
> bundle [of] multiple items ... now be treated as a unit?
I think /bundles is probably a separate REST endpoint with list, list
contents, and delete supported. In the catalog UI I imagine the
containing bundle is shown when you look at a type, you can click it to
see details of that bundle including contents, and there is a way to
list bundles.
> attempt to delete one [item] ... permitted?
As you say for legacy compatibility we have to. However I'd like to
deprecate this once everything is in a bundle and we support bundle
deletion. Once item deletion is done, we can remove the persistence of
individual catalog items; persisting the bundles is sufficient to
persist the catalog (reading BOMs from bundles on rebind). This
simplifies things which is always good. It also means if we want a
"don't delete things in use" check, and when we do upgrades, it suffices
to look for references to a bundle rather than references to specific types.
Also, I think the search path should always contain bundles. That gives
us a way to to do the above checks. Currently it contains items, and
for a transitional period it may need to contain both, but we should
de-empahsise catalog items for search purposes.
We should also deprecate the use of `libraries` anywhere other than the
top-level in catalog.bom. That makes the dependency tree simpler (it's
just among bundles, delegated to OSGi), and I'm pretty sure there's no
use case for the complexity.
Best
Alex
On 20/06/2017 11:17, Richard Downer wrote:
Alex,
On 19 June 2017 at 17:39, Alex Heneveld <[email protected]>
wrote:
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).
A great proposal. The blueprint developer stories in Brooklyn (which is
where I am at the moment) are coming together really well recently, but the
relationship between bundles and catalog items is an odd one, and it'd be
great to get a consistent story around this.
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.
Is it necessary to always wrap stuff in a bundle? Could catalog items not
exist independently of a bundle? (I'm not expressing an opinion about if
this is a good or bad idea, just wondering what your thinking is.)
* 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.
+1. Can the version number be omitted from all places except once in either
catalog.bom or MANIFEST.MF?
* 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.
+1
Does anyone oppose any of the above, or have further questions?
It all sounds good, and the compromises acceptable. A further question:
If a bundle contains multiple items, would these items now be treated as a
unit in the catalog? Say I upload a bundle which contains a couple of
items, then use the `br` tool or Brooklyn web UI to inspect the individual
items, and attempt to delete one. Would this be permitted? Ideally, no,
this would not be permitted, but that would be another change in behaviour
(and a breaking API change).
Cheers
Richard.
