=== Dmitrii-Sh9 is now known as Dmitrii-Sh [06:18] is there a current documentation repo for making fresh shiny new charms using charmcraft? Other than the obvious readme in the repo (which is really good), there was some stuff on discourse which is somewhat out of date now given that we're not doing submodules and so on [08:18] bthomas: ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄｍｏｒｎｉｎｇ！ [08:20] Morning Chipaca [08:21] Chipaca: I may have a couple (probably more) questions today. I will try and type them here. Do you prefer I ask you in the morning or post lunch ? [08:21] This is for the hook documentation. [08:21] bthomas: why wait :) [08:21] Awesome thank you. [08:21] ask them now, and i'll answer when and if i'm able :) [08:21] irc is async \o/ [08:21] (less async than email, but hey) [08:22] Ok. I like to dig a bit before asking. So it will be intermittent through the day. [08:22] 👍 [08:23] please don't wait to ask 🙂 better wait for me to reply than that [09:07] Chipaca: I will number questions through the day. This is Q1) What is the operator interface for a leader to set some key/value pair ? (i.e. what is the equivalent of "leader-set" from the reactive world). Same question for "leader-get" [09:09] I am reading this reactive docs for leadership api : https://discourse.juju.is/t/implementing-leadership/1124 [09:37] Chipaca: Q2): I am going through the Hook Context and Tools docs at https://discourse.juju.is/t/the-hook-environment-hook-tools-and-how-hooks-are-run/1047 . How much of this is still valid in the operator framework ? For instance are all the environment variables (including relation variables) and hook tools still available to Operator Charm hooks ? [10:15] bthomas: leader-get and -set are not implemented by operator. I think (but would like jam to confirm) that it's because we haven't yet found a use case that wouldn't be better served by setting data on the peer relation. [10:16] (that's for Q1) [10:17] Got it. Thanks. [10:17] bthomas: re Q2, the hook environment and tools are what operator builds on to present the interface that it does to charmers. There shouldn't be a need to use things from the lower level, but they're there if needed (and if we see it being needed, we would typically model it inside operator somehow) [10:18] bthomas: munging Q1 and Q2, the pgsql interface uses leader-set and -get to poke at leader data directly (we think it would be better done on the peer relation, and that's part of an ongoing conversation) [10:24] Chipaca: In view of your answer to Q2 it sounds prudent to hide these lower level interfaces and not expose them in Charmhub documentation, thereby discouraging their use. I shall adopt this approach for now and followup with jam and jldev, regarding their viewpoint on the matter. [10:24] sgtm [11:12] ¡Muy buenos días a todos! [11:16] xavpaice, did you check this tutorial? https://discourse.juju.is/t/how-to-build-a-charm-using-modern-tools/3246 [12:26] PR operator#401 closed: fix docstring on Harness.add_relation_unit WRT events [12:27] Chipaca: Your response to Q1 implies that only Juju decides which unit is leader. A Charm can not decide this. Correct me if I am wrong here. [12:28] ah, the problem with "do X if Y" is that ¬Y means I can do *anything* :-D [12:30] Indeed. But Charm can not set leadership since it has no means to trigger and leader_elected event or leader_settings_chagned event. [12:33] bthomas: electing leadership is beyond the abilities of the proles^Wcharms [12:34] Ok thanks. I get it quorum sensing, paxos and the like, is stuff a charm would rather leave to Juju :-). [12:38] I asked the question because the discourse hook doc linked above suggests a Charm may decide if a unit is the leader, in the leader-elected doc lines (quoted) "If the election process is done internally to the application, other code should be used to signal the leader to Juju." [12:39] bthomas: that's the application deciding it's the leader, not the charm [12:44] Chipaca: In that case, the differences between an application deciding its leader and the units deciding their leader is not obvious. It is not clear if and why a cham needs to be aware of or respond to an "applications electing leader". [12:44] bthomas: I don't follow [12:48] Chipaca: I was just explaining why I asked the question if we can assume that only Juju decides the leader unit. I pointed out that the current charm hook docs suggest that "application" may make the leadership decision "internally" . I interpreted your response as meaning leadership among units is different from leadership within the application. I did not understand this response and was trying to probe it further. [12:49] bthomas: in the normal case, juju decies who the leader is, and sends an event to the charm to that effect, and the charm reconfigures the application (or whatever is needed to implement "you be the leader now") [12:49] Got it . Thanks. [12:49] bthomas: in some cases instead the application itself decides who the new leader is, and needs to arrange some way to tell juju [12:49] bthomas: this way does not involve the charm [12:50] Chipaca: Ah I see now. Do we need to document this, if it does not involve the Charm ? [12:51] no, i don't think we do [12:51] great thank you. [13:20] bthomas: could i get a review of https://github.com/canonical/charmcraft/pull/150 ? [13:20] PR charmcraft#150: when failing to create hard link attempt to use shutil.copy2 [13:20] Chipaca: will do [13:33] Chipaca: Q3) Since a Charm is expected to use relation data rather than setting leader data, only one use case remains for the "leader_settings_changed" event. This is the use case of notifying the current leader, that it will no longer be the leader. Is this correct ? However soon after this event, one would also expect a "leader_elected" event to also invariably fire, when the new leader is elected. Can I hence say, that the [13:33] of the leader_settings_chagned event is solely, for a leader to do, what needs to be done, in order to relinquish leadership. [13:35] * bthomas goes to make some coffee [13:54] huh, first time i've seen "* Chipaca has quit (Ping timeout: 240 seconds)" myself === majduk__ is now known as majduk_ === karimsye_ is now known as karimsye === nicolasbock_ is now known as nicolasbock [14:06] * Chipaca brb [16:56] i'm off for now (run + dinner + etc), will bb(much)l [20:06] Chipaca, jam, a pattern I've seen a lot is this (quite useful) sequence: [20:06] msg = "whatever we want to communicate" [20:06] logger.info(msg) [20:06] self.unit.status = MaintenanceStatus(msg) [20:06] I wonder if we could provide a shortcut for that [20:07] maybe something like `self.unit.status = MaintenanceStatus(msg, log=True)` (or even log by default) [20:20] facubatista, I know 'juju show-status-log' will tell you about the various value the status went through, but it doesn't appear in the default log messages [20:22] Chipaca or facubatista in case bthomas comes back, it feels like he has it backwards. leader_settings_changed notifies *non* leaders that the settings have changed, leader_elected is telling the unit that they are now the leader. [20:27] jam, thanks [21:35] jam: ah, thanks. I'll let him know in the morn.