brooklyn-dev mailing list archives

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

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 <alex.heneveld@cloudsoftcorp.com>
> 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.
>


Mime
View raw message