[11:07] <facubatista> ¡Muy buenos días a todos!
[11:17] <bthomas> Morning facubatista
[11:18] <facubatista> hola bthomas
[11:19] <bthomas> Looks like there is no easy way to debug charms on microk8s. juju debug-log does not show logging messages from the charm because even the smallest update interval of 1min is to slow to capture the logs. Any of the other means debug-hooks, debug-code etc are not supported on k8s.
[11:20] <bthomas> facubatista: if you have some time for a 1:1 anytime I will be much obliged.
[11:21] <facubatista> bthomas, in ~10' it's fine
[11:22] <bthomas> facubatista: awesome thank you ping me when you are ready
[11:33]  * facubatista could use a review on this dead simple branch https://github.com/canonical/charmcraft/pull/133
[11:33] <mup> PR charmcraft#133: Added a note in the release howto about sending a mail when done <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/133>
[11:34]  * bthomas looking at https://github.com/canonical/charmcraft/pull/133
[11:36] <facubatista> bthomas, anytime now, I'm in https://meet.google.com/fqw-mdqc-dsf
[11:36] <bthomas> facubatista: going now
[11:59] <facubatista> bthomas, join #juju
[12:55] <moon127> hey all, I've added charmcrafters as a reviewer on the MP for unifi-poller charm being written in IS - https://code.launchpad.net/~moon127/charm-k8s-unifi-poller/+git/charm-k8s-unifi-poller/+merge/389643
[13:10] <facubatista> moon127, ack, thanks
[13:22] <justinclark> bthomas, I'm not sure about microk8s, but I can do juju ssh into units in a charmed-kubernetes bundle (the machines are LXD). Could you maybe juju deploy kubernetes-core and then deploy charms to that bundle?
[13:23] <justinclark> Not sure if that'll work, but just offering suggestions.
[13:28] <facubatista> another easy small PR for review, thanks! https://github.com/canonical/charmcraft/pull/134
[13:28] <mup> PR charmcraft#134: Use original permissions when creating a dir at building time <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/134>
[13:41] <justinclark> I'll take a look now facubatista
[13:42] <facubatista> thanks
[14:02] <justinclark> I have a (potentially noob) question: When looking at the docs, I see that leader units can set application data [1], but the only way I've found to set application data is through a relation. So my question: is there a way to access the application data directly rather than through a relation?
[14:02] <justinclark> [1] https://ops.readthedocs.io/en/latest/index.html#ops.model.RelationData
[14:03] <bthomas> justinclark: thank. Will look into charmed kubernetes
[14:03] <justinclark> bthomas: just a heads up - it's pretty resource intensive. You might have better luck with kubernetes-core bundle.
[14:03] <bthomas> got it
[14:06] <justinclark> Context for my question: when a relation_changed hook fires, I want to save some data that comes through that relation (host and port) to the main application's data.
[14:08] <justinclark> I currently have a silly looking line like this: event.relation.data[self.app]['data-sources'][event.relation.id] = {...}
[14:10] <justinclark> I think it would be much nicer to access app data directly but I don't know if that even makes sense in the context of Juju / operator framework.
[14:10] <bthomas> I am looking at those docs myself and can see "They are allowed to read remote unit and application data." But it does not elaborate.
[14:10] <bthomas> "They" reffers to units.
[14:28] <facubatista> justinclark, what happens if you do ...
[14:28] <facubatista> relation_data = event.relation.data[self.unit]
[14:28] <facubatista> relation_data[somekey] = somevalue
[14:28] <facubatista> ?
[14:28] <justinclark> Yeah that would clean things up. Let me try something like that.
[14:30] <justinclark> facubatista, Is there a rule of thumb for what kind of data should be stored at the unit level vs. application level?
[14:30] <justinclark> (Again, probably showing my newness to charming)
[14:32] <facubatista> IIUC you set the information to the application at the other end of the relation
[14:33] <facubatista> not the unit
[14:33] <facubatista> that `[self.unit]` I'm doing above is because you have the data for the apps in both units
[14:39] <justinclark> So if my Grafana charm accepts a Prometheus relation, setting event.relation.data[self.app] would set prometheus app data rather than Grafana app data?
[14:43] <justinclark> Okay, so I think what I actually need is to store the data in the charm's StoredState: https://ops.readthedocs.io/en/latest/index.html#ops.framework.StoredState
[14:43] <justinclark> Basically, I'm just trying to make Grafana data source information (host/port/etc.) easily accessible.
[15:27] <facubatista> justinclark, yes, you can store stuff in the charm's StoredState (btw, you should call that "store", not "state", as we want to get away of tha misnaming: it's a general store, not the "state of the charm")
[15:31] <facubatista> another easy PR: https://github.com/canonical/charmcraft/pull/135
[15:31] <mup> PR charmcraft#135: Support the global options also after the command is given <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/135>
[17:08] <facubatista> mthaddon, just took a look at the charm-k8s-gunicorn MP, added some comments
[17:45] <crodriguez__> Does anyone know if it is possible to define the metadata in pod_spec_set for a role ? I want to turn this into a pod_spec, and the metadata field is not recognized with the way I do it https://pastebin.canonical.com/p/zQSXfQGnkq/
[17:49] <crodriguez__> I get this https://pastebin.canonical.com/p/RYXNzDW6z6/
[17:59] <mup> Issue operator#390 opened: Only one role allowed <Created by camille-rodriguez> <https://github.com/canonical/operator/issues/390>
[18:02] <crodriguez__> I opened that bug in case you can do something about it in the framework itself. Idk if it is more juju than ops though
[21:28]  * facubatista eods
[21:28] <facubatista> and eows
[21:28] <facubatista> see you all on Monday