[06:57] <mthaddon> Chipaca (although you're not here) thx! :)
[08:09] <Chipaca> morning all
[08:19] <mthaddon> Chipaca: morning! thx for the mock - that definitely works, just need to figure out why mocking GunicornK8sCharm directly doesn't work
[08:21] <Chipaca> mthaddon: as I read it, the first argument to patch() needs to be something you can import
[08:21] <Chipaca> so it doesn't work on methods nor attributes of a class
[08:21] <Chipaca> and doubly so for methods on attributes of attributes of attribtues of a class :-p
[08:22] <Chipaca> (because charm.unit is charm.model.unit is charm.framework.model.unit)
[08:23] <mthaddon> right, I see
[08:25] <mthaddon> 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] <Chipaca> mthaddon: a package and a module are different things
[08:29] <Chipaca> mthaddon: charm is indeed not a package
[08:29] <Chipaca> it is a module
[08:29] <Chipaca> mthaddon: took me a bit to notice that one :)
[08:30] <Chipaca> mthaddon: packages are modules that have modules in them
[08:30] <Chipaca> what it's saying is that it can't do "from charm.GunicornK8sCharm import blah"
[08:31] <Chipaca> (although AIUI it's actually trying something even deeper, ie importing charm.GunicornK8sCharm.model.unit
[08:31] <Chipaca> )
[08:33] <Chipaca> 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] <Chipaca> 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] <mthaddon> ack, thx for the info - will read up on that
[08:52] <moon127> 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] <Chipaca> moon127: yes
[08:55] <moon127> ta
[10:00] <Chipaca> the behaviour of subprocess.run() with shell=1 and multiline arguments on windows is less than good
[10:00] <Chipaca> grmbl
[10:25]  * bthomas does cart wheels
[10:26] <bthomas> Fixed problem with charm not updating status. Now get hook failed "start". Some progress .
[11:03] <facubatista> ¡Muy buenos días a todos!
[11:04] <facubatista> Chipaca, "the behaviour of .* on windows is less than good"
[11:09] <facubatista> Chipaca, hola! if I get to land https://github.com/canonical/charmcraft/pull/140 , I'll start the release process
[11:09] <mup> PR charmcraft#140: Always log the charmcraft version when indicated <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/140>
[11:45] <Chipaca> facubatista: +1
[11:45] <facubatista> Chipaca, thanks
[11:48] <facubatista> 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] <Chipaca> facubatista: fo sho
[12:01] <facubatista> ?
[12:01] <Chipaca> facubatista: for sure
[12:02] <facubatista> Chipaca, no meeting?
[12:02] <Chipaca> facubatista: michał set themselves as not going, so ¯\_(ツ)_/¯
[12:03] <facubatista> natalia is not "no" but neither "yes" :/
[12:19] <facubatista> Chipaca, improve as you will, and let me know, thanks! http://linkode.org/#AvxqcVJWEFzDCEGONFFN53
[12:22] <facubatista> Chipaca, I improved the order (forgot to do that), please check linkode's node 2
[12:40] <Chipaca> facubatista: specifities?
[12:40] <narindergupta> 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] <Chipaca> narindergupta: no
[12:40] <Chipaca> python 2 is not supported
[12:40] <narindergupta> Chipaca, so python3 is prerequisite for action
[12:41] <narindergupta> Chipaca, ok so we have to install it manually in k8s for Cassandra.
[12:43] <narindergupta> 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] <Chipaca> facubatista: check node 3 plz
[12:49] <facubatista> Chipaca, "commandline" or "command line"?
[12:49] <Chipaca> facubatista: both :-D
[12:50] <Chipaca> narindergupta: what exactly is the problem with set_results?
[12:51] <narindergupta> 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] <Chipaca> narindergupta: i mean, it's a mapping
[12:53] <Chipaca> it doesn't have to be "message"
[12:53] <narindergupta> yeah
[12:54] <narindergupta> event.set_results({"message": outputmes})
[12:54] <narindergupta> I have to use above command to setup the action message
[12:54] <Chipaca> narindergupta: because actions results are mappings
[12:55] <narindergupta> Chipaca, I understand it now and it took me sometime to understand it that's what I am trying to communicated.
[12:57] <narindergupta> Chipaca, this is what charmcraft provide event.set_result(
[12:57] <narindergupta>                 "Probability is too important to be left to the experts."
[12:57] <narindergupta>                 " -- Richard Hamming")
[12:57] <narindergupta> And which does not work.
[12:58] <Chipaca> d'oh, that's a bug
[12:59] <narindergupta> Chipaca, just one more query do we know which even get fired if we use juju remove-unit
[12:59] <Chipaca> facubatista: can we slip a fix for this into today's release
[13:00] <Chipaca> it's super small but it's a bug that breaks the action
[13:00] <Chipaca> anyway, heading into an interview now
[13:01] <facubatista> Chipaca, yes
[13:01] <facubatista> Chipaca, let's talk after your interview
[13:06] <jam> morning all
[13:15] <bthomas> good to have you back jam
[13:15] <jam>  o/
[13:34] <justinclark> hello o/
[13:47] <Chipaca> justinclark: ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄ  ｍｏｒｎｉｎｇ！
[13:50] <deej> 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] <deej> https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389345
[13:50] <deej> https://code.launchpad.net/~deej/charm-k8s-openldap/+git/openldap/+merge/389606
[13:51] <facubatista> hola justinclark
[13:51] <facubatista> Chipaca, so, which bug we should work on urgently?
[13:57] <Chipaca> deej: augh. will try to get to those right after the ones for moon127
[13:57] <Chipaca> facubatista: i don't think narinder filed it :-)
[13:57] <deej> Right on, ta!
[13:57] <Chipaca> facubatista: i'll try to repro it now, but it's easy to see
[13:57] <Chipaca> facubatista: the arg to set_result in _on_fortune_action in charm.py.j2 is wrong
[13:58] <Chipaca> facubatista: because set_result doesn't exist, and set_results takes a map
[13:58]  * justinclark is caffeinated
[13:58] <Chipaca> so it's all wongled
[13:59] <Chipaca> hmmmm
[13:59] <Chipaca> or maybe i'm confused and there is no bug
[13:59] <Chipaca> hmmmmm³
[13:59] <Chipaca> hah! mocks
[13:59] <Chipaca> yeah, it's a bug
[14:00] <Chipaca> the code tests that it does what it does, which is not what it should do
[14:11] <Chipaca> facubatista: charmcraft#141
[14:11] <mup> Issue charmcraft#141: action created with 'charmcraft init' calls nonexistent method set_result on the action event <Created by chipaca> <https://github.com/canonical/charmcraft/issues/141>
[14:12] <facubatista> Chipaca, you working on it or shall I?
[14:12] <drewn3ss> Am I right in that there's no way to unregister an observer in the code currently?
[14:12] <Chipaca> committing the fix
[14:12] <Chipaca> drewn3ss: yup
[14:13] <Chipaca> drewn3ss: what would you do that for? :)
[14:13] <drewn3ss> let me send the code for a better explanation.
[14:13] <drewn3ss> but basically, on_relation_joined of an interface Object may need to register itself to observe config_changed
[14:14] <drewn3ss> but on departed, if there are none left, it should stop responding to the hook
[14:14] <drewn3ss> I mean, it'll still be there and it will be a no-op because there's no related units
[14:14] <drewn3ss> the classic "scale-back" issues of charming.
[14:15] <Chipaca> drewn3ss: yeah, share code, because that didn't make sense to me when reading it
[14:15] <Chipaca> if you register interest in an event in an event handler, you'll never get called
[14:16] <Chipaca> so... i guess it already deregisters? always? unconditionally no matter what? :-p
[14:17] <drewn3ss> well, I first ran into this because I was observing config_changed from init of the object
[14:17] <drewn3ss> rather than from within the event
[14:17] <drewn3ss> and then it was observing config_changed before it was even attached
[14:17] <drewn3ss> which was not intended
[14:18] <Chipaca> drewn3ss: if your charm doesn't register to observe an event in its constructor, it will never 'get' that event
[14:19] <Chipaca> drewn3ss: the charm isn't "alive" all the time, it's brought up, constructed from zero, for every event
[14:20] <Chipaca> 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] <drewn3ss> https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/lib/interface_prometheus/operator.py?h=feature/public-charm#n31
[14:21] <Chipaca> facubatista: https://github.com/canonical/charmcraft/pull/142 alstublieft
[14:21] <mup> PR charmcraft#142: fix the action generated by 'charmcraft init' <Created by chipaca> <https://github.com/canonical/charmcraft/pull/142>
[14:22] <facubatista> ack
[14:24] <drewn3ss> 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] <drewn3ss> provider relations need to be able to react to config_changed
[14:25] <drewn3ss> and that needs to not have to be handled by the charmer, is my gut feeling
[14:26] <drewn3ss> 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] <drewn3ss> but I'm still going to have to register it and deregister it on joined/departed
[14:27] <drewn3ss> because I don't want to react to config_changed until I've got the relation available
[14:28] <drewn3ss> 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] <drewn3ss> 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] <Chipaca> 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] <Chipaca> 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] <drewn3ss> ok
[14:43] <drewn3ss> does that happen on failed hook --retry, too?
[14:44] <Chipaca> yes i don't think the charm gets to know it's a "retry"
[14:44] <drewn3ss> makes sense.
[14:44] <drewn3ss> thanks!
[14:44] <Chipaca> hth
[14:44] <drewn3ss> now I just have to ask why the original coder of this charm wanted to defer some of these events.
[14:44] <drewn3ss> looks like it's order of operations management
[14:45] <Chipaca> 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] <facubatista> narindergupta, may I have your review of https://github.com/canonical/charmcraft/pull/142 ? thanks
[14:46] <mup> PR charmcraft#142: fix the action generated by 'charmcraft init' <Created by chipaca> <https://github.com/canonical/charmcraft/pull/142>
[14:46] <drewn3ss> ah, ok.  so, a "schedule me later". rather than building a finite state machine.
[14:46] <drewn3ss> thanks, Chipaca!
[14:46] <facubatista> FSMs are hard
[14:48] <Chipaca> blessed be its noodly appendeges
[14:48] <facubatista> :)
[14:48] <Chipaca> ah no, wrong FSM
[14:48] <facubatista> Chipaca, also hard
[14:48] <drewn3ss> lol
[14:48] <Chipaca> facubatista: I remember the syncdaemon FSM
[14:49] <Chipaca> facubatista: I'm going to fix the indentation of 142 by choosing a shorter fortune
[14:49] <facubatista> Chipaca, oh yes
[14:49] <facubatista> Chipaca, good choice
[15:18] <facubatista> justinclark, bthomas, may I have a review on https://github.com/canonical/charmcraft/pull/142 ? thanks!
[15:18] <mup> PR charmcraft#142: fix the action generated by 'charmcraft init' <Created by chipaca> <https://github.com/canonical/charmcraft/pull/142>
[15:19] <bthomas> facubatista: having a look
[15:19] <facubatista> Ah, narindergupta  mentioned it's ok but didn't approve
[15:19] <facubatista> bthomas, thanks
[15:20] <narindergupta> facubatista, I have no option to approve may be I am not part of team?
[15:21] <narindergupta> facubatista, gotchu you approve now
[15:22] <facubatista> thanks!
[15:22] <facubatista> Chipaca, we need to wait for Travis, now
[15:41] <Chipaca> facubatista: we no longer need to wait for travis
[15:42] <facubatista> Chipaca, wonderful, thanks
[16:54] <Chipaca> 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] <Chipaca> mthaddon: er, i meant 'approve'
[16:55] <Chipaca> i'll look at the following one tomorrow
[17:02] <Chipaca> EOD becuase #nobrain
[18:10] <facubatista> Release done! Subproduct PR: https://github.com/canonical/charmcraft/pull/143
[18:10] <mup> PR charmcraft#143: New release (and improved howto) <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/143>
[18:15] <drewn3ss> \o/
[18:19] <drewn3ss> 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] <drewn3ss> projects where it may not be appropriate or possible to get them to add packaging to their interface?
[18:20] <drewn3ss> 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] <drewn3ss> technically, upstream is: https://github.com/tasdomas/juju-interface-prometheus
[18:23] <drewn3ss> while we could suggest a setup.py PR and then include our personal branch in requirements.txt, this seems unideal.
[18:25] <facubatista> drewn3ss, this interface is part of a charm?
[18:25] <drewn3ss> 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] <drewn3ss> https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/lib/interface_prometheus/operator.py?h=feature/public-charm
[18:27] <drewn3ss> 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] <facubatista> 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] <drewn3ss> hmm...how's that work?
[18:29]  * drewn3ss goes to see if that's in the readme
[18:29] <facubatista> 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] <facubatista> OTOH, charmcraft may grow the ability of downloading from charmhub in the future, but that's yet to discuss
[18:32] <drewn3ss> 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] <facubatista> drewn3ss, what do you mean with "the central consumer"?
[18:36] <drewn3ss> 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] <drewn3ss> so, ultimately, prometheus should be the project that owns this interface
[18:36] <drewn3ss> and should live in that charm's opslib, right?
[18:36] <drewn3ss> I, as the developer of one of 100 exporters shouldn't own the interface to the main/central consumer
[18:37] <facubatista> drewn3ss, you *could*, and people could use yours if let's say Prometheus Inc :p doesn't provide one
[18:38] <facubatista> I could provide another
[18:38] <facubatista> and eventually Prometheus Inc could provide another
[18:38] <drewn3ss> right, but we already have providers listed for several interfaces iin the reactive framework
[18:38] <facubatista> anybody can decide which interface to use through opslib mechanism
[18:38] <drewn3ss> is there anything you can point me to for opslib?
[18:39] <drewn3ss> I've been sifting the discourse w/out finding quite what I'm looking for.
[18:39] <drewn3ss> I did see ops-lib-pgsql is out on pypi
[18:39] <drewn3ss> and so docs on how to use the libs makes sense, but how do I distribute?
[18:40] <drewn3ss> and how do I make ensure namespace is clear and usable by me (ala snapstore registration of names)
[18:41] <facubatista> 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] <facubatista> we don't have much docs yet :(
[18:42] <drewn3ss> okay, so I'd have to publish and maintain the package in pypi
[18:42] <drewn3ss> but charmers have not had to do this in the past
[18:42] <facubatista> drewn3ss, if it's pip-installable, you can leave it in github, but you need the setup.py
[18:43] <facubatista> how was it distributed in the past?
[18:43] <drewn3ss> layer.yaml interface-prometheus
[18:45] <drewn3ss> https://github.com/juju/layer-index
[18:45] <facubatista> drewn3ss, noted, I'll talk about this with Chipaca, thanks
[18:45] <drewn3ss> much appreciated, thank you :)
[18:46] <facubatista> :)
[18:46] <drewn3ss> 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] <facubatista> ack
[18:47] <drewn3ss> (I also tried a lot of ways to get pip to just download a project w/out a setup.py and failed)
[18:48] <drewn3ss> 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] <drewn3ss> but, lord... -_-
[18:48] <drewn3ss> and to be clear, interface-prometheus is in our control, but elasticsearch interfaces are owned by omni-vector, for instance.
[18:49] <facubatista> drewn3ss, I have to run now, but for sure I'll focus on this
[18:49] <drewn3ss> thanks, m8.  have a good evening.
[18:50]  * facubatista -> tennis, bbl
[21:30]  * facubatista is back
[22:12]  * facubatista eods and eows
[22:12] <facubatista> see you all back on Monday