brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aled Sage (JIRA)" <>
Subject [jira] [Commented] (BROOKLYN-492) Brooklyn upgrade tricky if using `brooklyn.libraries` for custom OSGi bundles
Date Tue, 02 May 2017 21:27:04 GMT


Aled Sage commented on BROOKLYN-492:

[~alex.heneveld] how would the newer versions of the catalog items get into the catalog, in
order to upgrade the instances? Are you thinking of an equivalent to the {{./bin/brooklyn
launch --catalogAdd ...}}, but for karaf? Or an offline tool for adding the new catalog items?
Or something else?

For your suggested hack/fix of "two bundles at the same version", are you thinking of us telling
karaf to install from two URLs, which point at the same version - where one may fail and then
the other succeed? That sounds unpredictable (e.g. the first, compiled against the old Brooklyn,
might install but subsequently give an exception like NoSuchMethodError when we try to instantiate
things). I don't think Karaf will let you have two installed bundles with the same symbolic
name + version.

How would the version ranges be in brooklyn.libraries? I presume you're thinking that the
bundle is installed by some other mechanism, so it just references symbolicName:versionRange?
The current customer use-case I'm thinking about is where the brooklyn.libraries contains
the url of a bundle, so that would be a specific version rather than a range.

> Brooklyn upgrade tricky if using `brooklyn.libraries` for custom OSGi bundles
> -----------------------------------------------------------------------------
>                 Key: BROOKLYN-492
>                 URL:
>             Project: Brooklyn
>          Issue Type: Bug
>            Reporter: Aled Sage
> When a user refers to their custom OSGi bundle in a catalog's {{brooklyn.libraries}}
section, this could make subsequent upgrade of Brooklyn more difficult.
> This is separate from Alex's email thread to dev@brooklyn "Making blueprint upgrades
easier - feature proposal" (i.e. it would not be solved by Alex's proposal). However, it's
worth thinking about that as well for a long-term holistic solution.
> ---
> Consider the following steps:
> * With Brooklyn 0.11.0:
>   * A user writes a custom OSGi bundle (e.g. containing their own custom policy or Java
entity or whatever), compiled against Brooklyn 0.11.0.
>   * The user creates a catalog item (v1.0), which references that bundle.
>   * The user deploys some apps that use this catalog item (with their state being persisted).
> * When Brooklyn 0.12.0 comes out, the user attempts to upgrade:
>   * The user tries to start 0.12.0, rebinding against their existing persisted state.
This reads the catalog, and thus attempts to install/active the user's custom OSGi bundle.
>   * Their custom bundle may fail to install (e.g. perhaps there are wiring errors due
to dependency changes between 0.11.0 and 0.12.0);
>     or alternatively perhaps the bundle loads, but the instances of the Java policy/entity
fail to be instantiated (e.g. 0.11.0 and 0.12.0 are not binary compatible, with the user's
code relying on some class/method that has changed).
>   * Rebind therefore might fails.
> * The user tries to update their custom OSGi bundle:
>   * The user updates their code and recompiles, to create a v2.0 of their bundle and
of their catalog item.
>   * However, they can't start 0.12.0 with the existing persisted state in order to add
the v2.0 catalog item, and upgrade their entities.
>   * The user might then try starting 0.11.0 up instead, and adding v2.0 of the catalog
item there.  
>     This might work, or it might lead to bundle wiring errors because v2.0 is incompatible
with Brooklyn 0.11.0.
> How likely this is to actually impact a user depends on: 1) what binary incompatible
changes we might make in Brooklyn between versions; and 2) what parts of Brooklyn the user's
Java code makes use of. Some power-users do some pretty sophisticated things, digging into
the less frequented classes of Brooklyn that on first blush might not be considered part of
our "api"!
> ---
> The long-term solution needs a lot more discussion on the dev@brooklyn mailing list.
> However, it might well revolve around being able to start Brooklyn into a usable state,
even when some blueprints/entities have errors. This is important so that errors can be resolved,
and so that errors in some blueprints don't cause the entire server to become unusable.
> This is particularly important for big companies using Brooklyn, where there is a separation
of teams: one team responsible for managing Brooklyn servers/upgrades, and other teams responsible
for writing blueprints / catalog items.
> ---
> A short-term solution could involve using offline tools to transform the persisted state
(e.g. using something like {{bin/brooklyn copy-state ... --transformations ...}}).
> Note that the {{copy-state}} commands are not readily available if one is using just
the Karaf distro of Brooklyn.
> Also note that {{./bin/brooklyn launch --catalogAdd ...}} is also not available if using
the Karaf distro of Brooklyn.

This message was sent by Atlassian JIRA

View raw message