[
https://issues.apache.org/jira/browse/BROOKLYN-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15993794#comment-15993794
]
Aled Sage commented on BROOKLYN-492:
------------------------------------
Note that https://issues.apache.org/jira/browse/BROOKLYN-496 means we can't use
{{brooklyn copy-state --transformations ...}} with persisted state generated
from brooklyn-karaf.
> 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)
