brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: Bundles in Brooklyn
Date Tue, 20 Jun 2017 11:42:34 GMT


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 `` 
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  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.


On 20/06/2017 11:17, Richard Downer wrote:
> Alex,
> On 19 June 2017 at 17:39, Alex Heneveld <>
> 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 "" 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 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
>> * 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.

View raw message