I see. Thanks for the pointer. This is very helpful in our design.
On 04/18/2017 09:30 AM, Marco Ceppi wrote:
On Tue, Apr 18, 2017 at 8:57 AM Alex Kavanagh
> wrote:
Hi
On Tue, Apr 18, 2017 at 1:50 PM, fengxia
Marco,
I'm modeling a complex workload which may end up having a lots of
states. So before going down that path I want to understand better how
to modularize these states instead of laying all flat. So I thought of
putting them into different layers within a single charm -- this works.
Then
No, because it's a sqlitedb per unit of charm. So a charm collocated on the
same machine will still have its own state.
Can I ask what you're looking to achieve?
Marco
On Tue, Apr 18, 2017, 10:05 fengxia wrote:
> Replying my own question:
>
> charmhelpers.core.unitdata shows
Replying my own question:
charmhelpers.core.unitdata shows how states are stored --
"reactive.state.xyz" is saved in a sqlite3 as a string. So if split
states in multiple charms, I think it will still work if deploying these
charms to the same unit because they will be registered in the same
On Tue, Apr 18, 2017 at 8:57 AM Alex Kavanagh
wrote:
> Hi
>
>
> On Tue, Apr 18, 2017 at 1:50 PM, fengxia wrote:
>
>> I did a quick experiment:
>>
>> 1. Created two layers in one charm, each layer has a few states,
>> set_state() can trigger @when
Hi
On Tue, Apr 18, 2017 at 1:50 PM, fengxia wrote:
> I did a quick experiment:
>
> 1. Created two layers in one charm, each layer has a few states,
> set_state() can trigger @when defined in other layers.
>
> 2. Use the same set of states, now splitting them in two charms =>
I did a quick experiment:
1. Created two layers in one charm, each layer has a few states,
set_state() can trigger @when defined in other layers.
2. Use the same set of states, now splitting them in two charms => @when
don't trigger anymore.
So does this mean states have a namespace by the