[
https://issues.apache.org/jira/browse/BROOKLYN-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15983730#comment-15983730
]
Alex Heneveld commented on BROOKLYN-492:
----------------------------------------
Would being able to trigger upgrades on startup/rebind not solve this? IE tell
Brooklyn to upgrade all instances of the catalog item before instantiating,
thus pulling in the 0.12.0-compatible custom java bundles? That's what I was
thinking in my proposal -- though it might need to be made explicit and there's
a fair bit of work to get there.
As an immediate hack/fix does OSGi allow you to provide two bundles at the same
version with different upstream dependent versions? This is an abuse of
versions but if you install two variants of the custom bundle with the same
version but different dependencies, and we could rely on OSGi to eliminate
bundles that aren't compatible, that would solve the problem.
The proposal also calls for version ranges. Going forward I think open-ended
version ranges e.g. "[1.1.0,1.2)" gives a nice way to be able to supply an
upgraded java bundle without cheating versions and without having to force
upgrades of catalog items. (The ranges could be in brooklyn.libraries or we
could deprecate that and just piggy-back on a MANIFEST.MF.)
> Brooklyn upgrade tricky if using `brooklyn.libraries` for custom OSGi bundles
> -----------------------------------------------------------------------------
>
> Key: BROOKLYN-492
> URL: https://issues.apache.org/jira/browse/BROOKLYN-492
> 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
(v6.3.15#6346)
