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 to divide them into different charms -- this didn't.
Now I can see each unit has its own sqlite so these states won't come
across.
On 04/18/2017 10:16 AM, Marco Ceppi wrote:
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 <fx...@lenovo.com
<mailto:fx...@lenovo.com>> wrote:
Replying my own question:
charmhelpers.core.unitdata shows how states are stored --
"reactive.state.xyz <http://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 DB.
Can someone verify this?
On 04/18/2017 08:50 AM, 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 trigger anymore.
>
> So does this mean states have a namespace by the charm it belongs?
>
--
Feng xia
Engineer
Lenovo USA
Phone: 5088011794
fx...@lenovo.com <mailto:fx...@lenovo.com>
Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums
--
Juju mailing list
Juju@lists.ubuntu.com <mailto:Juju@lists.ubuntu.com>
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
--
Feng xia
Engineer
Lenovo USA
Phone: 5088011794
fx...@lenovo.com
Lenovo.com
Twitter | Facebook | Instagram | Blogs | Forums
--
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju
