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
mailto:alex.kavan...@canonical.com>> wrote:
Hi
On Tue, Apr 18, 2017 at 1:50 PM, fengxia mailto:fx...@lenovo.com>> wrote:
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 t
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 how states are sto
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 D
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 defined in other layers.
>>
>> 2. Use the same se
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 => @when
> don't trigg
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
