=== max__ is now known as Guest94787 [04:05] o/ [04:50] morning Dmitrii-Sh [04:51] morning jam [07:10] Dmitrii-Sh, feedback given on https://github.com/canonical/operator/pull/212 [07:14] jam: ty, I'll spend some time on it. I added .begin() in different test cases to be able to get to charm metadata (so that I can check whether a relation is a peer relation or not) [07:15] Dmitrii-Sh, I believe we have self._meta we don't need self.charm.meta IIRC [07:16] jam: ok, I think I missed this. If so, I can replace the check [07:52] Good morning folks [07:58] morning [08:29] good morning charmcaft! [08:29] Moin! [08:33] morning [10:01] jam: having some hardware issues, be there in a minute [10:23] hi everyone - is this a right place for a new developers to ask their questions about the new framework? :) [10:33] vgrevtsev: yep! [10:34] Chipaca: good to know, thanks - just starting writing my first charm, so I'll definitely have some questions around. As far as I understood, there are no single doc/howto, only READMEs from the different ops charms with some hidden knowledge? [10:35] vgrevtsev: yes :( [10:35] vgrevtsev: working on fixing that, but for now, yes [11:23] Muy buenos días a todos! [11:24] facubatista: 👋 [11:25] hola Chipaca! [11:25] facubatista: o/ [11:25] hola Dmitrii-Sh! [11:41] jam, I feel like the previous version of the branch was more clear: if the envvar is set, the logging setup is indicated to go to debug mode, which means two decissions that belongs to the logging setup: a) logger in debug level, b) also a handler to stderr [11:42] on a call, will chat with you in a sec [11:42] jam, now it feels mixed, it looks like which stream is decided outside the logging setup, and that stream is indicated to the logging setup, which when present, not only builds a handler for it (it's fine there) but also changes the level of the logger [11:42] * niemeyer => lunch [11:46] * Chipaca ⇝ also lunch [12:08] facubatista, so I don't have a huge problem with the fact that setting a 'debug_stream' means enabling debug messages. That said, since the log handler already filters at INFO, we could just have the log level always DEBUG? [12:08] the fact that handlers have separate levels from loggers is always a bit wonky [12:09] different levels for handlers and loggers is a good feature [12:09] they filter different levels for different purposes [12:09] I mean, they have different semantics [12:11] jam, we can put the JujuLogHandler always in DEBUG, as it just sends stuff to juju, which also presents the user a way to select the level [12:11] but the logger must be in INFO by default [12:16] jam, actually, this impacts in that interaction: when the user jumps into a debug hook, juju will start getting DEBUG logs, as we're chaning the logger level, which I think it's fine [12:16] the default is still info [12:33] jam, so? [12:34] facubatista, so... that isn't how it currently works, so I'm trying to parse out a bit of what your suggesting how we should make it work. And the various pieces at play. [12:35] jam, this is related: https://github.com/canonical/operator/issues/198 [12:35] we need to have in mind how this will end in its whole [12:38] https://github.com/canonical/operator/pull/216 - sent another interface for review. I'll need to modify the existing charms to adjust to this change. [12:38] Of note: as I introduce more complex types into interfaces, I feel the need to use some form of serialization. For example, even using timedate.delta for various health-checking timeouts requires me to do that. [12:43] datetime.timedelta? [12:43] yes [12:44] got it backwards while writing :^\ [12:44] :) [12:45] Dmitrii-Sh, if it is a timedelta, why wouldn't you just serialize a float point seconds? [12:48] jam: I'm assuming that's "some form of serialization" [12:49] jam: in this particular case I could covert datetime.delta to float and also expose a property on a type that does the reverse [12:50] Chipaca, fair enough, though there is a fair difference to say "use a float" vs "I need to encode things using JSON because I want to round trip a serialized form" [12:50] Chipaca, IIRC, charms.reactive defaulted to translating all relation-set values into JSON blobs [12:51] ew :) [12:52] jam, may you help me with something, as IIUC you already tested this IRL... see this: http://linkode.org/#ipk9mNkD5aiE8vA78xkUD1 <-- there I exercised debug-hooks, set up the envvar myself and run the hook, got the pdb prompt.. [12:52] jam, of course those two lines will not exist; if I write a message, it will appear after the other one? (like in node 2 of that linkode), or alone (like in node 3)? [12:52] @property [12:52] def timeout(self): [12:52] return self._timeout.total_seconds() [12:53] something like that ^ [12:53] facubatista, so you'll need juju 2.8 from the edge snap, and the command is "juju debug-code" if you want to test the new behavior. [12:53] facubatista, but the new behavior is in (3) [12:53] I intentionally skip the Juju message, because it isn't helpful when you are ending up in PDB [12:55] jam: but, yes, to use the same type on both sides of the relation I need to use something to serialize/deserialize more complex objects. Whether its pickle, JSON or other boilerplate code to fit the data into relation data bags [12:55] the question is how complex do we want it to be for somebody implementing an interface [12:56] Dmitrii-Sh, given the whole point of interfaces is to be the point of abstraction, I certainly wouldn't want Python types on the wire [12:57] even Pickle between Python isn't safe because on might be a Python3.5 running on Xenial, and the other is Python 3.8 running in Focal [12:58] facubatista, if you want to test it, you should be able to do "snap install --channel=edge juju --classic" and then 'juju bootstrap lxd' should leave you with a '2.8beta1' controller. [12:58] jam: yes, plus the code on both sides of a relation may be of different revisions [12:58] jam, so, it will be better to have a more complex text, like http://linkode.org/#Pu9DEIIWWybq5Q2eDSelJ [12:59] facubatista, yeah, I think something like that. [12:59] Chipaca, it worries me lying in line 6 ^ [12:59] is there a way we can tell ^D/exit was done and make sure the hook exits nonzero? [12:59] jam, can I upgrade juju and keep the same controller? how that works? [13:00] facubatista, if you have the new snap, you might be able to "juju upgrade-controller". However, if it is a 2.7 stable controller, getting it to a 2.8 beta can be a bit trickier, IIRC. [13:02] jam, I can totally destroy and re-bootstra, I just don't want to do that very often; do you think I will be able to just leave 2.8beta1 in my system? [13:02] Chipaca, just make him write the documentation before he can land his code, then it won't be a lie. [13:03] Though I believe the official discourse just switched to discourse.juju.is [13:03] like 3 days ago or something. [13:04] facubatista, until we hit official beta, Juju doesn't guarantee compatibility/upgrades. While it is coming real-soon-now and I don't see any particular problems I certainly wouldn't use it for anything you want to guarantee keep around. [13:04] other than that, things in 'edge' have passed the unit test suite, but not necessarily the full CI regression suite. [13:05] (I've always tended to run straight off develop/or a feature branch rather than edge, so I don't have a lot of experience with it) [13:12] jam, ack, thanks [14:12] niemeyer: just sent an invite - I hope you can make it. [14:19] Dmitrii-Sh: Thanks! If the meeting doesn't run over I will make it [14:19] niemeyer, I put the message here: https://docs.google.com/document/d/1H_3V19XGnEvUtE_tk2CFWmtiW8Zc4y1lvxTPz55VSJY/edit (the original one, and a newer already improved version below) [14:23] facubatista: Thanks, let's sync later today as your timezone is friendly to that :) [14:26] niemeyer, +1 [15:03] Dmitrii-Sh: niemeyer : I need to dig more into the mssql components and the solution I want to put in place before asking questions about how to transpose that to the framework itself. The more I read about it the less I'm sure of what I want to do haha. I will dig more about that and maybe we can reschedule the call in a few days? [15:04] It's a bit complex since the mssql components are only in preview mode for docker, no official doc about transposing it to k8s itself, so I'm experimenting [15:09] crodriguez: I think we can still have a call (even if it's going to be short) just to go over what's involved at a high level [15:09] and then dive into the details as we get more info [15:10] Sure Dmitrii-Sh [15:10] crodriguez: Yeah, I'd appreciate even just listening to what you've been up to, so we can learn about your initial views on the problems you're working through [15:11] okay np :) I just didn't want to waste anyone's time since I'm still figuring things out [15:18] crodriguez: No worries.. that's exactly the sort of opinion I'd be happy to learn about.. once you learn a bit more about the problem space and the candidate solutions, these early feelings will be replaced by feasible alternatives given what you've learned [15:20] crodriguez: Some of the idiosyncrasies might be worth fixing, though, if we can learn about them === narindergupta is now known as narinderguptamac [16:05] hi Dmitrii-Sh - are you able to have a quick sync now? [16:05] crodriguez: thanks for the feedback, feel free to reach out going forward [16:05] vgrevtsev: sure, just finished the last meeting [16:05] Dmitrii-Sh: https://meet.google.com/sxc-wcti-vko?authuser=1 [16:07] Chipaca: How's the Office Hours thing going? [16:07] niemeyer: still need to meet with tim v and look at when and how to do it (soon) [16:08] Chipaca: Ack, thanks [16:49] good news is i know what i'm charming :-) [16:56] many thanks Dmitrii-Sh - it became much more clearer for me now :) [16:56] * vgrevtsev starts charming [16:56] cheers [17:11] mmm... juju bootstrap crashed for juju from edge, will ask in #juju [17:16] * Chipaca EODs [17:20] Hi team [17:21] o/ [17:22] When I scale up my zookeeper or Kafka PODS does stop and start. [17:22] And when I run juju status I get a new juju unit [17:23] While pod name is same [17:23] For example kafka-k8s/0 becomes kafka-k8s/4 [17:23] While pod name remain same Kafka-k8s-0 [17:24] Due to that sometime storage volume gets stuck and new pod does not start successfully and get stuck because volume get stuck [17:24] Any ideas? [17:37] narindergupta: So you mean pods get destroyed and recreated but remain with the same name [17:37] ? [17:37] I am scaling up and there is change in spec [17:37] Juju status says pods stop and pods start [17:38] And I am expecting pod name to remain same which does [17:38] But juju unit changes [17:38] From Kafka/0 to Kafka/4 [17:38] niemeyer, ^ [17:40] narindergupta: That's a bit awkward.. I wasn't involved in the design of the k8s implementation so I don't yet know how that works internally, but I can't imagine how the unit would get destroyed and recreated but the pod would remain the same [17:40] That's what is happening with operator framework did not tried with reactive though [17:41] narindergupta: The operator framework doesn't have a saying if the entire unit is getting destroyed.. it's living inside the unit [17:42] So you are suggesting it is juju behavior? [17:42] We are calling set_spec whenever config change [17:43] self.model.pod.set_spec [17:43] narindergupta: Yes, the operator framework is a library to help you implementing the charm.. a charm is not deployed until juju says it should be [17:43] narindergupta: set_spec should not destroy your unit and recreate it [17:43] It is doing it [17:44] Not first time [17:44] But on config changes [17:44] But adding new unit [17:46] As adding unit in zookeeper required to change the number of units as part of zookeeper config [17:46] So I have to call set_spec during scale [17:46] up [17:46] Which is causing Destry old unit and create new one while pod remains the same [17:53] Actually whenever pod stop during upgrade Kafka unit gets terminated [17:54] narindergupta: We need someone that knows more deeply how the juju integration works.. what's your timezone? [17:54] I am US CST [17:54] Ok, so about 1PM now [17:55] narindergupta: How about we try to get hold of someone first thing tomorrow in your morning? [17:55] Sounds good to me [17:55] narindergupta: I'm keen on being present to understand as well how this is being done.. the behavior you describe doesn't seem to make sense, or I have a broken model in mind. So I'm keen to learn too. [17:56] Sure that would be helpful [17:56] narindergupta: Alright, can you please ping tomorrow when you get online? [17:56] Ok sounds good [17:56] narindergupta: Deal, thanks [17:57] facubatista: Are you around for that last call? [17:57] niemeyer, otp, what about in 10'? or you EODing already? I can hang... [17:57] facubatista: 10' is fine [17:58] niemeyer, thanks [17:58] np [18:14] niemeyer, ready [18:14] niemeyer, https://meet.google.com/veq-yfqm-kdk? [18:14] omw [20:29] * facubatista eods