brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aledsage <...@git.apache.org>
Subject [GitHub] brooklyn-server issue #867: BROOKLYN-546: fix rebind of system bundles
Date Tue, 24 Oct 2017 21:42:16 GMT
Github user aledsage commented on the issue:

    https://github.com/apache/brooklyn-server/pull/867
  
    @ahgittin Still requires some more testing, but wanted to share this now for feedback.
    
    ----
    As discussed with @ahgittin, there was an additional rebind issue when loading the initial
catalog (and subsequently loading persisted bundles). Karaf will have cached OSGi bundles
for that initial catalog. The initial catalog would duplicate some of these - it couldn't
tell that the karaf bundle installed on the previous brooklyn run was identical to the bundle
it wanted to install (it can't yet see the persisted brooklyn-managed records, and it can't
understand osgi location `brooklyn:ID`).
    
    Possible solutions for that included:
    1) make `brooklyn:ID` osgi location be a checksum (so the same osgi location would be
used for two identical brooklyn-managed bundles).
    2) clear the karaf cache of brooklyn-managed bundles (e.g. all those with location in
the form `brooklyn:ID`), in the knowledge that the initial catalog and persisted state will
reinstall them.
    3) load initial catalog _after_ persistence (but we expect the initial catalog to tell
us whether to remove some items from persistence so this isn't a good option without major
re-work).
    4) if we're not certain that it's identical, then uninstall and reinstall the bundle (which
is what happens currently). This might be a problem if it's a core brooklyn module, but those
should have `mvn:` urls so it _can_ confirm whether it's a duplicate).
    5) rework rebind / initial catalog load so that we load placeholders for bundles that
have been persisted (enough to do the deduping or install things referenced in initial catalog
load).
    
    We opted for doing (1) and (4).
    
    ---
    Another issue (FAO @ahgittin) is that every time Brooklyn was started, we'd add to the
persisted state another copy of each core brooklyn bundle!
    
    This is because the initial catalog references things like `org.apache.brooklyn.policy`.
The `ManagedBundle` we create to represent it gets an auto-generated unique id. We see that
the bundle is already installed, so we don't re-install it in karaf (good). But we do still
persist it to the `/bundles` persisted state sub-directory.
    
    I've worked around that by black-listing `org.apache.brooklyn.*` from being persisted
(see `OsgiArchiveInstaller.isBlacklistedForPersistence(ManagedBundle)`. The assumption is
that those will always ship with Brooklyn - we should use just the version that is shipped
with the given release of Brooklyn.
    
    ---
    Another issue (similar, not yet fixed) is that we persist a new identical copy of `brooklyn-default-karaf-catalog`
every time we restart Brooklyn. This is because the `ManagedBundle` for the initial catalog
has an auto-generated unique id. As above, we do not install the duplicate bundle, but we
still persist it.
    
    Luckily rebind is not as bad as you might think! It spots that an identical bundle is
already installed, so doesn't install it or parse the catalog.bom of every copy that is in
persisted state.
    
    Possible solutions for this include:
    1) changing the persistence file/object names to use the `symbolicName_version.jar` format
(similar naming to the old `/catalog` directory).
    2) only persist the bundle if we actually installed it (i.e. it wasn't a duplicate).
    3) search persisted state for a duplicate, and don't add if it already exists.
    
    Option (1) is very tempting, given that is it's logical unique identity: we shouldn't
be persisting (and thus installing) multiple things with the same name:version. We'd need
to be careful with backwards compatibility if someone has `/bundles` that uses the unique
ids. We could later add additional checks to only replace the persisted file if its checksum
had actually changed.
    
    Option (2) feels wrong - what is persisted depends on what is in your karaf cache! For
example, if you change the persisted state directory then we wouldn't write out the initial
catalog to it because karaf would have cached those bundles from the previous run.


---

Mime
View raw message