| mthaddon | Chipaca (although you're not here) thx! :) | 06:57 |
|---|---|---|
| Chipaca | morning all | 08:09 |
| mthaddon | Chipaca: morning! thx for the mock - that definitely works, just need to figure out why mocking GunicornK8sCharm directly doesn't work | 08:19 |
| 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:21 |
| Chipaca | (because charm.unit is charm.model.unit is charm.framework.model.unit) | 08:22 |
| mthaddon | right, I see | 08:23 |
| 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:25 |
| 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:29 |
| 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:30 |
| Chipaca | (although AIUI it's actually trying something even deeper, ie importing charm.GunicornK8sCharm.model.unit | 08:31 |
| Chipaca | ) | 08:31 |
| 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:33 |
| 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:34 |
| 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:52 |
| Chipaca | moon127: yes | 08:54 |
| moon127 | ta | 08:55 |
| Chipaca | the behaviour of subprocess.run() with shell=1 and multiline arguments on windows is less than good | 10:00 |
| Chipaca | grmbl | 10:00 |
| * bthomas does cart wheels | 10:25 | |
| bthomas | Fixed problem with charm not updating status. Now get hook failed "start". Some progress . | 10:26 |
| facubatista | ¡Muy buenos días a todos! | 11:03 |
| facubatista | Chipaca, "the behaviour of .* on windows is less than good" | 11:04 |
| 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:09 |
| Chipaca | facubatista: +1 | 11:45 |
| facubatista | Chipaca, thanks | 11:45 |
| 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? | 11:48 |
| Chipaca | facubatista: fo sho | 12:01 |
| facubatista | ? | 12:01 |
| Chipaca | facubatista: for sure | 12:01 |
| facubatista | Chipaca, no meeting? | 12:02 |
| Chipaca | facubatista: michał set themselves as not going, so ¯\_(ツ)_/¯ | 12:02 |
| facubatista | natalia is not "no" but neither "yes" :/ | 12:03 |
| facubatista | Chipaca, improve as you will, and let me know, thanks! http://linkode.org/#AvxqcVJWEFzDCEGONFFN53 | 12:19 |
| facubatista | Chipaca, I improved the order (forgot to do that), please check linkode's node 2 | 12:22 |
| 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:40 |
| narindergupta | Chipaca, ok so we have to install it manually in k8s for Cassandra. | 12:41 |
| 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:43 |
| Chipaca | facubatista: check node 3 plz | 12:48 |
| facubatista | Chipaca, "commandline" or "command line"? | 12:49 |
| Chipaca | facubatista: both :-D | 12:49 |
| Chipaca | narindergupta: what exactly is the problem with set_results? | 12:50 |
| 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:51 |
| Chipaca | narindergupta: i mean, it's a mapping | 12:53 |
| Chipaca | it doesn't have to be "message" | 12:53 |
| narindergupta | yeah | 12:53 |
| 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:54 |
| narindergupta | Chipaca, I understand it now and it took me sometime to understand it that's what I am trying to communicated. | 12:55 |
| 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:57 |
| Chipaca | d'oh, that's a bug | 12:58 |
| 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 | 12:59 |
| Chipaca | it's super small but it's a bug that breaks the action | 13:00 |
| Chipaca | anyway, heading into an interview now | 13:00 |
| facubatista | Chipaca, yes | 13:01 |
| facubatista | Chipaca, let's talk after your interview | 13:01 |
| jam | morning all | 13:06 |
| bthomas | good to have you back jam | 13:15 |
| jam | o/ | 13:15 |
| justinclark | hello o/ | 13:34 |
| Chipaca | justinclark: ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄ ｍｏｒｎｉｎｇ！ | 13:47 |
| 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:50 |
| facubatista | hola justinclark | 13:51 |
| facubatista | Chipaca, so, which bug we should work on urgently? | 13:51 |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| Chipaca | the code tests that it does what it does, which is not what it should do | 14:00 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| Chipaca | so... i guess it already deregisters? always? unconditionally no matter what? :-p | 14:16 |
| 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:17 |
| Chipaca | drewn3ss: if your charm doesn't register to observe an event in its constructor, it will never 'get' that event | 14:18 |
| Chipaca | drewn3ss: the charm isn't "alive" all the time, it's brought up, constructed from zero, for every event | 14:19 |
| 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:20 |
| 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:21 |
| facubatista | ack | 14:22 |
| 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:24 |
| 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:25 |
| 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:26 |
| drewn3ss | because I don't want to react to config_changed until I've got the relation available | 14:27 |
| 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:28 |
| 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:39 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:48 |
| 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 | 14:49 |
| 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:18 |
| bthomas | facubatista: having a look | 15:19 |
| facubatista | Ah, narindergupta mentioned it's ok but didn't approve | 15:19 |
| facubatista | bthomas, thanks | 15:19 |
| narindergupta | facubatista, I have no option to approve may be I am not part of team? | 15:20 |
| narindergupta | facubatista, gotchu you approve now | 15:21 |
| facubatista | thanks! | 15:22 |
| facubatista | Chipaca, we need to wait for Travis, now | 15:22 |
| Chipaca | facubatista: we no longer need to wait for travis | 15:41 |
| facubatista | Chipaca, wonderful, thanks | 15:42 |
| 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:54 |
| Chipaca | i'll look at the following one tomorrow | 16:55 |
| Chipaca | EOD becuase #nobrain | 17:02 |
| === 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 | ||
| 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:10 |
| drewn3ss | \o/ | 18:15 |
| 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:19 |
| 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:20 |
| drewn3ss | technically, upstream is: https://github.com/tasdomas/juju-interface-prometheus | 18:22 |
| drewn3ss | while we could suggest a setup.py PR and then include our personal branch in requirements.txt, this seems unideal. | 18:23 |
| 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:25 |
| drewn3ss | https://git.launchpad.net/~afreiberger/charm-cloudstats/tree/lib/interface_prometheus/operator.py?h=feature/public-charm | 18:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| facubatista | OTOH, charmcraft may grow the ability of downloading from charmhub in the future, but that's yet to discuss | 18:30 |
| 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:32 |
| facubatista | drewn3ss, what do you mean with "the central consumer"? | 18:35 |
| 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:36 |
| facubatista | drewn3ss, you *could*, and people could use yours if let's say Prometheus Inc :p doesn't provide one | 18:37 |
| 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:38 |
| 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:39 |
| drewn3ss | and how do I make ensure namespace is clear and usable by me (ala snapstore registration of names) | 18:40 |
| 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:41 |
| 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:42 |
| facubatista | how was it distributed in the past? | 18:43 |
| drewn3ss | layer.yaml interface-prometheus | 18:43 |
| 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:45 |
| 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:46 |
| drewn3ss | (I also tried a lot of ways to get pip to just download a project w/out a setup.py and failed) | 18:47 |
| 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:48 |
| 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:49 |
| * facubatista -> tennis, bbl | 18:50 | |
| * facubatista is back | 21:30 | |
| * facubatista eods and eows | 22:12 | |
| facubatista | see you all back on Monday | 22:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!