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.
