You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Aled Sage <al...@gmail.com> on 2017/09/26 08:53:01 UTC

Proposal: delete `--catalogReset`?

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



Re: Proposal: delete `--catalogReset`?

Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
+1

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 catalog.bom (have been noodling on this at [1] -- 
proposal to follow).

best
alex


[1] 
https://docs.google.com/document/d/1Lm47Kx-cXPLe8BO34-qrL3ZMPosuUHJILYVQUswEH6Y/edit?ts=59ca5a5e#heading=h.tr946lhtwsn2 
)


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 <al...@gmail.com> 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 •
> https://cloudsoft.io/
> Github: https://github.com/tbouron
> Twitter: https://twitter.com/eltibouron
>


Re: Proposal: delete `--catalogReset`?

Posted by Thomas Bouron <th...@cloudsoftcorp.com>.
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 <al...@gmail.com> 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 •
https://cloudsoft.io/
Github: https://github.com/tbouron
Twitter: https://twitter.com/eltibouron

Re: Proposal: delete `--catalogReset`?

Posted by Aled Sage <al...@gmail.com>.
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
>
>