[11:08] Where can I find a video of the operator day of the KubeCon ? [11:09] Alan21: let me check [11:11] I've searched for 20 min for videos of Juju at the Operator day but impossible to find any on my side [11:11] Alan21: I got an email with a recording, not sure if it's from kubecon or just before, i could fwd it to you [11:12] Alan21: i don't see the kubecon videos up yet [11:12] alan.zanatta@outlook.com please here :) [11:14] Alan21: by the date i think it was kubecon [11:14] the one of november [11:15] Alan21: yeah but there was also open infra just before it i think [11:15] but anyway this is from the 18th [11:15] so probably kubecon [11:15] (in any case, fwd'ed) [11:16] (and it was the same presentation, just more polished) [11:17] Thank you so much ! [11:19] no worries. it should be more widely available soon; i don't know why it isn't yet [12:09] Buenos días! [12:13] JoseMasson: 👋❗ [13:20] * Chipaca remembers most people appreciate a thing called 'lunch' [13:20] * Chipaca investigates [17:01] Is there a reason that the framework eschews controller-based unit storage for non-K8s charms? If it's available, is there a compelling reason to still prefer a local SQLite DB? [17:34] cory_fu: just performance [17:41] Hrm. Considering we expect a hook-level transaction anyway, it seems like it would be easy enough for the JujuStorage backend to just store things in memory and only invoke the hook tools during commit. I do know that the presence of the .unit-state.db file with potentially sensitive info stored in it has been raised as a concern in the past, and having unit stored data centralized in the controller could allow for consistent management [17:41] of encryption-at-rest. Anyway, just a thought.