[06:57] Chipaca (although you're not here) thx! :) [08:09] morning all [08:19] Chipaca: morning! thx for the mock - that definitely works, just need to figure out why mocking GunicornK8sCharm directly doesn't work [08:21] mthaddon: as I read it, the first argument to patch() needs to be something you can import [08:21] so it doesn't work on methods nor attributes of a class [08:21] and doubly so for methods on attributes of attributes of attribtues of a class :-p [08:22] (because charm.unit is charm.model.unit is charm.framework.model.unit) [08:23] right, I see [08:25] so the message "ModuleNotFoundError: No module named 'charm.GunicornK8sCharm'; 'charm' is not a package" is a little confusing because you can import charm (we're doing that earlier in the tests), but you can't import the specific thing I was trying to mock [08:29] mthaddon: a package and a module are different things [08:29] mthaddon: charm is indeed not a package [08:29] it is a module [08:29] mthaddon: took me a bit to notice that one :) [08:30] mthaddon: packages are modules that have modules in them [08:30] what it's saying is that it can't do "from charm.GunicornK8sCharm import blah" [08:31] (although AIUI it's actually trying something even deeper, ie importing charm.GunicornK8sCharm.model.unit [08:31] ) [08:33] mthaddon: and reading https://github.com/python/cpython/blob/3.8/Lib/unittest/mock.py#L1546 what it does is drop the last .foo, and then walk the other things importing them [08:34] ie if you say patch('foo.bar.baz.quux') it'll import foo, foo.bar, foo.bar.baz, and then grab quux from the last one [08:34] ack, thx for the info - will read up on that [08:52] Chipaca: Do you think we could get a review of https://code.launchpad.net/~moon127/charm-k8s-unifi-poller/+git/charm-k8s-unifi-poller/+merge/389643 today now we discussed and pushed changes? It would be nice to get that landed. [08:54] moon127: yes [08:55] ta [10:00] the behaviour of subprocess.run() with shell=1 and multiline arguments on windows is less than good [10:00] grmbl [10:25] * bthomas does cart wheels [10:26] Fixed problem with charm not updating status. Now get hook failed "start". Some progress . [11:03] ¡Muy buenos días a todos! [11:04] Chipaca, "the behaviour of .* on windows is less than good" [11:09] Chipaca, hola! if I get to land https://github.com/canonical/charmcraft/pull/140 , I'll start the release process [11:09] PR charmcraft#140: Always log the charmcraft version when indicated [11:45] facubatista: +1 [11:45] Chipaca, thanks [11:48] Chipaca, let's take a look at https://github.com/canonical/charmcraft/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.4.0 ? The three issues there are not finished, but progressed enough and we can aim those to 0.5.0 now, let's move them? [12:01] facubatista: fo sho [12:01] ? [12:01] facubatista: for sure [12:02] Chipaca, no meeting? [12:02] facubatista: michał set themselves as not going, so ¯\_(ツ)_/¯ [12:03] natalia is not "no" but neither "yes" :/ [12:19] Chipaca, improve as you will, and let me know, thanks! http://linkode.org/#AvxqcVJWEFzDCEGONFFN53 [12:22] Chipaca, I improved the order (forgot to do that), please check linkode's node 2 [12:40] facubatista: specifities? [12:40] Chipaca, at last I was able to run the action but I have install python3 as python2 was not sufficient enough to run the action. Is it something we can change? [12:40] narindergupta: no [12:40] python 2 is not supported [12:40] Chipaca, so python3 is prerequisite for action [12:41] Chipaca, ok so we have to install it manually in k8s for Cassandra. [12:43] Chipaca, also event.set_results({"message": outputmes}) it seems it took me sometime to understand the format. Do you think it can make it easy for others in framework. [12:48] facubatista: check node 3 plz [12:49] Chipaca, "commandline" or "command line"? [12:49] facubatista: both :-D [12:50] narindergupta: what exactly is the problem with set_results? [12:51] Chipaca, there is no problem just to understand the how parameter passed took me sometime. I was expected just message string but I have provide "message": "string" [12:53] narindergupta: i mean, it's a mapping [12:53] it doesn't have to be "message" [12:53] yeah [12:54] event.set_results({"message": outputmes}) [12:54] I have to use above command to setup the action message [12:54] narindergupta: because actions results are mappings [12:55] Chipaca, I understand it now and it took me sometime to understand it that's what I am trying to communicated. [12:57] Chipaca, this is what charmcraft provide event.set_result( [12:57] "Probability is too important to be left to the experts." [12:57] " -- Richard Hamming") [12:57] And which does not work. [12:58] d'oh, that's a bug [12:59] Chipaca, just one more query do we know which even get fired if we use juju remove-unit [12:59] facubatista: can we slip a fix for this into today's release [13:00] it's super small but it's a bug that breaks the action [13:00] anyway, heading into an interview now [13:01] Chipaca, yes [13:01] Chipaca, let's talk after your interview [13:06] morning all [13:15] good to have you back jam [13:15] o/ [13:34] hello o/ [13:47] justinclark: ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄｍｏｒｎｉｎｇ！ [13:50] Chipaca: If you've got a chance to have a look back at the MPs on the openldap charm it'd be appreciated, there's a couple bits of cleanup I'd like to get landed but it'd be nice to get these out of the way first [13:50] https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389345 [13:50] https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389606 [13:51] hola justinclark [13:51] Chipaca, so, which bug we should work on urgently? [13:57] deej: augh. will try to get to those right after the ones for moon127 [13:57] facubatista: i don't think narinder filed it :-) [13:57] Right on, ta! [13:57] facubatista: i'll try to repro it now, but it's easy to see [13:57] facubatista: the arg to set_result in _on_fortune_action in charm.py.j2 is wrong [13:58] facubatista: because set_result doesn't exist, and set_results takes a map [13:58] * justinclark is caffeinated [13:58] so it's all wongled [13:59] hmmmm [13:59] or maybe i'm confused and there is no bug [13:59] hmmmmm³ [13:59] hah! mocks [13:59] yeah, it's a bug [14:00] the code tests that it does what it does, which is not what it should do [14:11] facubatista: charmcraft#141 [14:11] Issue charmcraft#141: action created with 'charmcraft init' calls nonexistent method set_result on the action event [14:12] Chipaca, you working on it or shall I? [14:12] Am I right in that there's no way to unregister an observer in the code currently? [14:12] committing the fix [14:12] drewn3ss: yup [14:13] drewn3ss: what would you do that for? :) [14:13] let me send the code for a better explanation. [14:13] but basically, on_relation_joined of an interface Object may need to register itself to observe config_changed [14:14] but on departed, if there are none left, it should stop responding to the hook [14:14] I mean, it'll still be there and it will be a no-op because there's no related units [14:14] the classic "scale-back" issues of charming. [14:15] drewn3ss: yeah, share code, because that didn't make sense to me when reading it [14:15] if you register interest in an event in an event handler, you'll never get called [14:16] so... i guess it already deregisters? always? unconditionally no matter what? :-p [14:17] well, I first ran into this because I was observing config_changed from init of the object [14:17] rather than from within the event [14:17] and then it was observing config_changed before it was even attached [14:17] which was not intended [14:18] drewn3ss: if your charm doesn't register to observe an event in its constructor, it will never 'get' that event [14:19] drewn3ss: the charm isn't "alive" all the time, it's brought up, constructed from zero, for every event [14:20] drewn3ss: so one thing you _could_ do (and I'm not saying it's a good idea) is set a flag in stored state and use that in __init__ to observe or not a certain event [14:21] https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/lib/interface_prometheus/operator.py?h=feature/public-charm#n31 [14:21] facubatista: https://github.com/canonical/charmcraft/pull/142 alstublieft [14:21] PR charmcraft#142: fix the action generated by 'charmcraft init' [14:22] ack [14:24] and where it's instantiated in the code https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/src/charm.py?h=feature/public-charm#n55 [14:25] provider relations need to be able to react to config_changed [14:25] and that needs to not have to be handled by the charmer, is my gut feeling [14:26] though, hmm...now that I'm thinking about it, I need to be able to update the config of the relation on config-changed, so maybe that's the wrong place to put it. [14:26] but I'm still going to have to register it and deregister it on joined/departed [14:27] because I don't want to react to config_changed until I've got the relation available [14:28] actually, yeah, that should only be reacting to changes of it's own config...nvm, I see your point, and it's not something I need now, but I will need to de-register in the future, I feel. or just ensure it's a no-op when I get there because there are no related units. [14:39] ok, I've put the code in the riight path now, but I think I need to figure out what event.defer() does. [14:42] drewn3ss: event.defer marshals the event and plops it into a database, and it's then at the top of the queue the next time the charm comes up to handle an event [14:43] drewn3ss: so i guess the exception to the '1 event per charm invocation' is deferreds, which get to run before the event that caused the charm to be built [14:43] ok [14:43] does that happen on failed hook --retry, too? [14:44] yes i don't think the charm gets to know it's a "retry" [14:44] makes sense. [14:44] thanks! [14:44] hth [14:44] now I just have to ask why the original coder of this charm wanted to defer some of these events. [14:44] looks like it's order of operations management [14:45] drewn3ss: there is a need for something a charmer can used to say "don't bother me at all until all these things are true", which is the dependencies thing [14:46] narindergupta, may I have your review of https://github.com/canonical/charmcraft/pull/142 ? thanks [14:46] PR charmcraft#142: fix the action generated by 'charmcraft init' [14:46] ah, ok. so, a "schedule me later". rather than building a finite state machine. [14:46] thanks, Chipaca! [14:46] FSMs are hard [14:48] blessed be its noodly appendeges [14:48] :) [14:48] ah no, wrong FSM [14:48] Chipaca, also hard [14:48] lol [14:48] facubatista: I remember the syncdaemon FSM [14:49] facubatista: I'm going to fix the indentation of 142 by choosing a shorter fortune [14:49] Chipaca, oh yes [14:49] Chipaca, good choice [15:18] justinclark, bthomas, may I have a review on https://github.com/canonical/charmcraft/pull/142 ? thanks! [15:18] PR charmcraft#142: fix the action generated by 'charmcraft init' [15:19] facubatista: having a look [15:19] Ah, narindergupta mentioned it's ok but didn't approve [15:19] bthomas, thanks [15:20] facubatista, I have no option to approve may be I am not part of team? [15:21] facubatista, gotchu you approve now [15:22] thanks! [15:22] Chipaca, we need to wait for Travis, now [15:41] facubatista: we no longer need to wait for travis [15:42] Chipaca, wonderful, thanks [16:54] mthaddon: i think you forgot to 'accept' https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389345 when you did 'looks good to me' [16:54] mthaddon: er, i meant 'approve' [16:55] i'll look at the following one tomorrow [17:02] EOD becuase #nobrain === ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.8.0 || charmcraft 0.4.0 [18:10] Release done! Subproduct PR: https://github.com/canonical/charmcraft/pull/143 [18:10] PR charmcraft#143: New release (and improved howto) [18:15] \o/ [18:19] facubatista: I'm working on developing a new operator interface (what would have been a layer) to be included in https://launchpad.net/interface-prometheus. This interface layer, like many others from the reactive layer repository, does not have a setup.py to define the python package. What does your team suggest for distribution, management, and inclusion of interface modules from upstream [18:19] projects where it may not be appropriate or possible to get them to add packaging to their interface? [18:20] I was seeing the readme suggests no need for submodules, but I'm wondering if this is the only solution, or if charmcraft might have another solution up it's sleeve? [18:22] technically, upstream is: https://github.com/tasdomas/juju-interface-prometheus [18:23] while we could suggest a setup.py PR and then include our personal branch in requirements.txt, this seems unideal. [18:25] drewn3ss, this interface is part of a charm? [18:25] yeah. I'll point you at current code. I want to move this interface into a public repo for use in all prometheus-exporter charms. [18:26] https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/lib/interface_prometheus/operator.py?h=feature/public-charm [18:27] I'm still mid-dev cycle, but trying to find the apporpriate home for things like this, and it seems it'd be ideal to put it in the current interface project. [18:28] drewn3ss, on one side, if you put the interface under the opslib directory, then everybody having your charm could make use of it (using the operator's opslib import feature) [18:29] hmm...how's that work? [18:29] * drewn3ss goes to see if that's in the readme [18:29] drewn3ss, but still leaves us to how people would get hold of your charm... currently it will need to have a setup.py to be pip-installed, being that from PyPI or directly from github [18:30] OTOH, charmcraft may grow the ability of downloading from charmhub in the future, but that's yet to discuss [18:32] I think we've got a transition timing issue to solve. I like the ops.lib idea, but the owner of this interfaced should be the central consumer, which isn't getting ported to operator any time soon. [18:35] drewn3ss, what do you mean with "the central consumer"? [18:36] Well, thinking about distribution of this interface from a product perspective, this is an interface that is used to connect many different exporters to prometheus [18:36] so, ultimately, prometheus should be the project that owns this interface [18:36] and should live in that charm's opslib, right? [18:36] I, as the developer of one of 100 exporters shouldn't own the interface to the main/central consumer [18:37] drewn3ss, you *could*, and people could use yours if let's say Prometheus Inc :p doesn't provide one [18:38] I could provide another [18:38] and eventually Prometheus Inc could provide another [18:38] right, but we already have providers listed for several interfaces iin the reactive framework [18:38] anybody can decide which interface to use through opslib mechanism [18:38] is there anything you can point me to for opslib? [18:39] I've been sifting the discourse w/out finding quite what I'm looking for. [18:39] I did see ops-lib-pgsql is out on pypi [18:39] and so docs on how to use the libs makes sense, but how do I distribute? [18:40] and how do I make ensure namespace is clear and usable by me (ala snapstore registration of names) [18:41] drewn3ss, for opslib we don't have namespaces, you can push to PyPI a project 'drew-prometheus', which can have your interface under the opslib directory, and that will be enough for me to use it [18:41] we don't have much docs yet :( [18:42] okay, so I'd have to publish and maintain the package in pypi [18:42] but charmers have not had to do this in the past [18:42] drewn3ss, if it's pip-installable, you can leave it in github, but you need the setup.py [18:43] how was it distributed in the past? [18:43] layer.yaml interface-prometheus [18:45] https://github.com/juju/layer-index [18:45] drewn3ss, noted, I'll talk about this with Chipaca, thanks [18:45] much appreciated, thank you :) [18:46] :) [18:46] I'm just concerned that we have a lot of projects already established with owners for charm interfacing, and I don't want to reinvent all of that. [18:46] ack [18:47] (I also tried a lot of ways to get pip to just download a project w/out a setup.py and failed) [18:48] would be interesting if we could define a generic project that had a setup.py and took #egg as a variable to go hunt for the non-packaged module :) [18:48] but, lord... -_- [18:48] and to be clear, interface-prometheus is in our control, but elasticsearch interfaces are owned by omni-vector, for instance. [18:49] drewn3ss, I have to run now, but for sure I'll focus on this [18:49] thanks, m8. have a good evening. [18:50] * facubatista -> tennis, bbl [21:30] * facubatista is back [22:12] * facubatista eods and eows [22:12] see you all back on Monday