brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Heneveld <>
Subject Re: Proposal: delete `--catalogReset`?
Date Wed, 27 Sep 2017 14:22:06 GMT


good point Thomas, if someone wants to reset they should point at a new 
persistence location,
because other persisted state will go haywire otherwise.

adding might be useful on upgrades but that's a separate topic and am 
thinking that should be
done via the default (have been noodling on this at [1] -- 
proposal to follow).




On 27/09/2017 14:54, Thomas Bouron wrote:
> Hi Aled.
> I think this is the right thing to do. As you said, this does not exists in
> the karaf world and would even be tricky to implement now that we move to
> bundlised all the things. Plus, if it can remove old and not used code, I'm
> all in for it.
> Best.
> On Tue, 26 Sep 2017 at 11:13 Aled Sage <> wrote:
>> p.s. And also *delete* `--catalogAdd` from classic (again it's not
>> supported in Karaf).
>> We sould be encouraging people to use `br catalog add ...` after
>> Brooklyn is started, or updating the .bom file at their
>> `default.catalog.location`, rather than using this command line option.
>> Aled
>> On 26/09/2017 09:53, Aled Sage wrote:
>>> Hi all,
>>> TL;DR: I propose we *delete* support for `--catalogReset`, for the
>>> next release. It's not supported in karaf mode, and it's dangerous
>>> (could break rebind of entities)!
>>> Note that I'm not suggesting deprecate. We've moved to karaf as the
>>> default in 0.12 release, so effectively the functionality has already
>>> disappeared (in the recommended way of running Brooklyn).
>>> ---
>>> In classic mode, we have support for `--catalogReset`. This works in
>>> combination with `--rebind ...` to tell Brooklyn that it should delete
>>> the persisted catalog (reseting it to the default initial catalog),
>>> while keeping the rest of the persisted state as-is.
>>> We don't support this in Karaf mode, and no-one has missed it.
>>> It is dangerous: if you have an entity instance then that will be
>>> persisted along with a catalogItemId, but resetting the catalog might
>>> cause that catalog item to disapear. This can cause serious problems
>>> when we try to rebind that entity instance (because we've lost type
>>> information).
>>> It is better to explicitly manage the catalog via
>>> additions/deprecations/removals.
>>> This is yet another example of where we can (slightly) simplify our
>>> startup/catalog code by removing unnecessary functionality.
>>> ---
>>> Slightly longer term, we want to rethink how we load the catalog (from
>>> "initial" and persisted state): rebind is confusing when upgrading
>>> Brooklyn, because it keeps the persisted catalog and doesn't
>>> automatically add any of the catalog items/versions for the new
>>> Brooklyn version. One has to do that addition manually.
>>> But that will be a topic for a new email thread!
>>> Aled
>> --
> Thomas Bouron • Senior Software Engineer @ Cloudsoft Corporation •
> Github:
> Twitter:

View raw message