#smooth-operator 2020-05-01 <jam> morning all <jam> mup seems to be having a hard time <niemeyer> Yeah, my network seems to have had many hiccups overnight <facubatista> Muy buenos dÃ­as a todos! <jam> morning facubatista <facubatista> hola jam <facubatista> jam, would you please help me to debug something? <jam> facubatista, certainly, what's up? <facubatista> I'm experimenting with this charm: https://paste.ubuntu.com/p/jvJdZ9mxdd/ <facubatista> jam, see lines 76-80 <facubatista> I have this charm deployed in a unit, apache2 deployed in other one <jam> ok <jam> Often during relation-joined the other side might not have had the chance to set any data yet <jam> you also want on.relation_changed for when they do change the data <facubatista> nice <facubatista> however, if I run <facubatista> juju add-relation bdv:server apache2:website <facubatista> I see <facubatista> unit-bdv-12: 16:48:34 INFO unit.bdv/12.juju-log server:4: ============ relation joined; event=<ops.charm.RelationJoinedEvent object at 0x7fc1d52c2940> <facubatista> unit-bdv-12: 16:48:34 DEBUG unit.bdv/12.server-relation-joined ==== rdata <ops.model.RelationDataContent object at 0x7fc1d52c28d0> <facubatista> so far, so good (even if no really data there), the problem is other <jam> facubatista, btw, we should make sure that the framework itself logs the juju hooks (at least at DEBUG, possibly at INFO), so that people don't have to instrument their own handlers. <jam> facubatista, so the rdata object is a wrapped dict <jam> you can do print(dict(rdata)) if you want to see the items <jam> We could probably improve the __str__ of RelationDataContent * facubatista improves a little the code <facubatista> jam, btw, yes, logging in debug when the operator framework calls *my* code, and then when *my* coded ended (and how, possibly), would be great <jam> facubatista, I definitely think logging at DEBUG for every Juju event and whether or not there is a handler <facubatista> good idea <facubatista> jam, so, *the* problem I get is: <facubatista> jam, in other terminal, I issue: juju debug-code bdv/12 <facubatista> (note that in my code the .breakpoint() call is commented out) <facubatista> then I go and I add the relation again (I had it removed before, of course): juju add-relation bdv:server apache2:website <facubatista> jam, and now in the logs I see this lot of times (every couple of seconds, until I remove the relation so it stops): <facubatista> unit-bdv-12: 08:18:27 INFO juju.worker.uniter.runner executing server-relation-created via debug-hooks; unknown/invalid hook handler <facubatista> unit-bdv-12: 08:18:28 ERROR juju.worker.uniter.operation hook "server-relation-created" (via unknown/invalid hook handler) failed: exit status 1 <jam> facubatista, so unknown/invalid hook handler for relation-created is interesting. can you look at what is in hooks/* there should be a symlink for hooks/server-relation-created according to the above complaint <jam> facubatista, it *sounds* like there is a script there that has an invalid #! line, but we'd want to check. <facubatista> let me ssh into the machine to see what is really there <facubatista> jam, where the charm is located inside the units? <jam> facubatista, /var/log/juju/agents/unit-bdv-12/charm IIRC <jam> sorry <jam> not /var/log <jam> /var/lib <facubatista> yes <facubatista> jam, I don't have a server-relation-created hook <jam> facubatista, are you using 'dispatch' ? <jam> (the error doesn'at seem to say that) <jam> ah, I'm wrong <facubatista> jam, nop, our framework still doesn not support it <jam> executing server-relation-created via debug-hooks <jam> that last line is important <jam> its trying to run relation-created as a debug-hook shell <facubatista> note however that without the `juju debug-code` call in other terminal, it works! <jam> facubatista, indeed. the key there is the "via", even if you don't have a shell script, we still drop you into a debug hook session for all Juju events. <jam> facubatista, I assume this is with juju edge 2.8b1 ? <facubatista> jam, 2.8-rc1-genericlinux-amd64 <jam> right, so ege <jam> edge <facubatista> I'm ok with getting into the "waiting mode" where I called `juju debug-code`, I just expect that nothing happens there as I don't have a breakpoint in my code, but the hook/event to work just fine as before <facubatista> or I'm missing something? <jam> facubatista, it sounds like a bug in juju that it either: <jam> a) doesn't know how to invoke relation-created via debug-code <jam> b) the framework is getting relation created, but then exiting badly <facubatista> I don't think the framework gets to do anything here, as I don't have the hook in the hooks/ dir <jam> facubatista, /snap/bin/juju --debug version <facubatista> jam, I can try *adding* the hook <jam> just to make sure that I'm running the same code as you <facubatista> jam, 2.8-rc1 3596 7507bb48aaf8d93cde47977b895d09d33f616e53 gc go1.14.2 <jam> facubatista, ok, that is latest/edge <mup_> Issue operator#249 opened: Let's instrument all registered methods' calls <Created by facundobatista> <https://github.com/canonical/operator/issues/249> <jam> facubatista, I'm seeing if I can reproduce <jam> also, roadmap in 5 <facubatista> yeap <jam> facubatista, I think I figured out the bug in Juju <jam> the issue is with debug-code <jam> If you are in debug-hooks session, then all hooks get intercepted by debug-hooks <jam> however, under 'debug-code' they get intercepted *and then still run* <jam> but if the file doesn't exist <jam> then you get this weird behavior <jam> I'll file a bug <jam> facubatista, https://bugs.launchpad.net/juju/+bug/1876290 <facubatista> jam, thanks! <Chipaca> facubatista: feliz dÃ­a che <facubatista> Chipaca, gracias, igualmente :) <facubatista> jam, FTR, adding the hook 'server-relation-created' unblocked me <jam> facubatista, sure. the bug is that if you run 'debug-code' then we blindly try to run all hooks, even if they don't exist <facubatista> jam, have 10' to help me understand some basic juju? a short HO would be great <facubatista> thanks * facubatista bb ~10' <jam> facubatista, I'm happy to. let me know when you're around. dinner is coming up soon, but food hasn't arrived yet <jam> facubatista, food just arrived. I'll ping you when dinner is done <facubatista> jam, ack, thanks * Chipaca reads how to run k8s on old laptops and suddenly has a bigger backlog * facubatista brb <jam> facubatista, I'm back <facubatista> jam, me too <facubatista> jam, https://meet.google.com/veq-yfqm-kdk ? <jam> facubatista, joining standup <jam> but I can meet you there <Chipaca> "this will enable you to connect to your cluster using Kubectl from the internet." â sounds like a bad idea to me <jam> Chipaca, Twitch Plays Kubernetes ? <jam> facubatista, question about 'juju debug-code'. What would you want to happen if you don't have a hook implemented. Should juju just ignore the event ? <jam> debug-hooks currently drops you into the debugger. and if you are using 'dispatch' then the operator framework will interrupt it <jam> I think the most sensible thing is to just skip the script if it doesn't exist. Since there is no way to 'drop into a breakpoint' of a hook that doesn't exist. <jam> The other option is that you drop to 'bash' like you do for 'juju debug-hooks'b <jam> maybe I can say that more clearly. <jam> if you run 'juju debug-code unit/0' and it doesn't have 'dispatch' and it doesn't have 'hooks/install'. <jam> when Juju wants to run 'install' <jam> should it <jam> a) just ignore it <jam> b) drop you into a bash prompt <jam> like we do for 'juju debug-hooks' <Chipaca> jam: what does 'ignore it' look like to the user? <Chipaca> if it's "don't even start the shell", or "drop out of the shell as soon as it figures this out with a message explaining things", then that sounds alright <jam> Chipaca, so today, if you run 'juju debug-hooks' and a given hook isn't implemented, you end up in a bash shell, with a prompt that says you are debugging 'install' <Chipaca> if it's "leave the user looking at a shell forever" then no :) <jam> Chipaca, likely it is 'blip a shell that never gets focus because it exits too quickly' <jam> debug-code is trying to hand off to the charm for it to handle the event <jam> but if the charm doesn't implement dispatch or the hook, then it has no way to 'handle the event' <jam> I'm trying to figure out whether dropping into bash is better, because it lets the charmer know that an event did happen that they weren't handling <jam> (which is what debug-hooks currently does) <Chipaca> we could also detect this in the framework and have a 'handle anything' thing that gets called in this scenario, which starts with a message to the user about how they're not seeing their code because it doesn't exist <jam> The *current* debug-code behavior is that we spin throwing errors because we try to exec "" or something to that effect. <jam> Chipaca, 'handle anything' is just dispatch <jam> so we already have that handled <Chipaca> i meant a handler that only gets added for debug-code when there ins't an actual handler <jam> Chipaca, the particular issue is 'relation-created' because Dmitrii's patch hasn't landed, so we don't create hooks/*-relation-created yet. <jam> Chipaca, and neither has *your* patch landed, so we don't handle dispatch either :) <jam> I think dispatch fills the use case nicely. Because we already know that if you set 'juju debug-code --at hook' <jam> we can do whatever we want if you don't have an event handler registered for a Juju event. <facubatista> jam, if I'm not handling the event (no script, or no method registered, etc) I should get the same behaviour than handling the script but not having a .breakpoint() call in there... just nothing should happen, it should leave me there in the "waiting state" <jam> facubatista, if you have no breakpoint(), we 'run the hook in the background and log a WARNING' <jam> I believe is what we discussed. <facubatista> yes, we opened an issue for that <jam> facubatista, so in that case, we don't leave you in the "waiting state"A <jam> I was thinking to drop back to the debug-hooks implementation <jam> so that you are aware that your charm isn't implementing 'relation-created' <jam> otherwise during 'juju debug-code' you don't even see that it happened. <facubatista> from my developer perspective, it should leave me in "waiting" state so I can actually get the breakpoint on relation joined <jam> ah, you're saying not interrupt you but wait for other hooks to fire <facubatista> I mean, without `juju debuc-code` I see my function called, I add a .breakpoint() call there, with `juju debug-code` I should get a pdb <jam> btw, wordpress review in 5 <jam> facubatista, Chipaca coming ? <Chipaca> yes <facubatista> yes <mup_> Issue operator#214 closed: Operator framework should support pod readiness event <Created by tcuthbert> <Closed by chipaca> <https://github.com/canonical/operator/issues/214> <jam> Chipaca, facubatista I'll be back around for the k8s charms meeting. for now I'm off to take the dog out <facubatista> jam, ack <Chipaca> i'm off to take myself out :) <Chipaca> see you all in an ahh <jam> one ahh later <jam> Chipaca, there are several people that I've heard during the pandemic pick up the phrase "I'm off to take myself out"A <jam> Walk the John <ballot> Hello ! <Chipaca> ballot: hi! <jam> according to this: https://blog.questionable.services/article/kubernetes-deployments-configmap-change/ <jam> changing a config map does *not* generate an event <jam> the end up including an env variable which is the hash of the config * facubatista -> mate for the final part of the day <Chipaca> facubatista: https://mobile.twitter.com/JenMsft/status/1256007715425382400 <facubatista> Chipaca, I love Gru <Chipaca> facubatista: :) <mup_> Issue operator#250 opened: Improve __str__ of developer exposed objects <Created by facundobatista> <https://github.com/canonical/operator/issues/250> <Chipaca> jam: have a great weekend, and see you Tuesday! #smooth-operator 2020-05-04 <mup_> PR operator#251 opened: Fix doctrings for add_relation_unit in ops.testing <Created by gnuoy> <https://github.com/canonical/operator/pull/251> <niemeyer> So quiet.. must be an after-sprint Monday <niemeyer> Morning all <Beret> yeah <Beret> quite a few are gone people are out today <Beret> wow <Beret> that sentence <Beret> just hurts <jam> hi Beret <jam> just missing a , or ; "quite a few are gone; people are out today" #smooth-operator 2020-05-05 <jam> morning all <Chipaca> moin moin moin <jam> Chipaca, o/ <Chipaca> jam: how's things? <jam> Chipaca, going pretty well. Have a PR on Juju up, and a couple other code reviews to get through. <Chipaca> jam: what's the juju pr about? <jam> Chipaca, fixing an issue with 'juju debug-code' that facu ran into last week <jam> namely, if Juju fires an event that the charm doesn't implement a hook for, Juju would go into error <Chipaca> ah, that one :) <Chipaca> jam: I didn't realise there was a juju-side fix for that, i thought it was on us <jam> Chipaca, no, the issue was that the handler for 'debug-code' was looking for the script to run, and 'executing it anyway' even though it didn't exist <jam> so the open question was whether we should fall back to a bash debugger. <jam> I think you and achilleas and facu all felt like you'd rather not be interrupted <jam> so I went with that route <Chipaca> :+1: <Chipaca> heh, this hexchat is missing my subs tweaks <jam> Chipaca++ <jam> hm, maybe that's only in canonical IRC <jam> Chipaca, you both hung for me, I'll rejoind <facubatista> Muy buenos dÃ­as a todos! <jam> morning facubatista <facubatista> hola jam :) <facubatista> Chipaca, #221 ... can we settle for changing the 'will' for a 'should <mup_> PR #221: ops/main.py: support dispatch <Created by chipaca> <https://github.com/canonical/operator/pull/221> <facubatista> ' in line 181? <Chipaca> facubatista: sure <Chipaca> i'll do that as soon as i have a working dev environment again :-( <Chipaca> right now not even vi works <Chipaca> how hexchat is still up is a mystery :-) <facubatista> Chipaca, what happened?? wild weekend? <Chipaca> facubatista: my new dev machine had to go back to service (remember the 'sticking at 800MHz' thing?), so i'm on my old one, and it was on 16.0 so i'm slowly moving to 20.04 but it has less memory than it should to do that and be productive <Chipaca> (i moved off the old machine when the motherboard stopped liking having more than 4GB RAM) <facubatista> probably too late now, but shouldn't the move from 16 to 20 be *not* slowly? like, installing from scratch? <Chipaca> and lose all my everything? heck no <Chipaca> also i'd miss out on messages like <Chipaca> assert result == expected, "got: %r expected: %r" (result, expected) <Chipaca> whoops <Chipaca> /usr/lib/python3/dist-packages/urwid/tests/test_canvas.py:232: SyntaxWarning: 'str' object is not callable; perhaps you missed a comma? <Chipaca> assert result == expected, "got: %r expected: %r" (result, expected) <Chipaca> ^ that <Chipaca> facubatista: but more seriously, I _could_ do a fresh install and then a full backup, but that would take more of my time than just upgrading <Chipaca> s/full backup/full backup restore/ <Chipaca> i'll probably do that at some point to drop unity and switch to lubuntu or lumina <Chipaca> huh, that's strange <Chipaca> just got a call from the local hospital thing, they're moving back to pre-covid stuff <facubatista> I got an appointment of May 17 moved to next month, "undetermined when" <Chipaca> facubatista: the week (or 2?) before lockdown started the hospital called me to say they were postponing any non-essential surgery 'indefinitely', and now they're scheduling them back <Chipaca> so it's like they are no longer in a panic <Chipaca> makes sense to me; they're also closing down the big emergency hospital <Chipaca> of course now the knee that's acting up is the other one, so i shouldn't just go in for surgery before a consultant looks at things again... <MarkMaglana> o/ <facubatista> hello MarkMaglana <MarkMaglana> hello facubatista! <MarkMaglana> joining the fun in this channel with my fellow FE-in-rotation vgrevtsev :-) <vgrevtsev> \o <Chipaca> MarkMaglana, vgrevtsev: welcome! <facubatista> Chipaca, looks the curve is controlled, kind of https://aatishb.com/covidtrends/?location=United+Kingdom <facubatista> hello vgrevtsev <MarkMaglana> thanks, Chipaca! excited to help with the charming effort on top of the operator framework. :-) <Chipaca> things you don't want to read during an upgrade: cryptsetup: ERROR: Couldn't resolve device <facubatista> Chipaca, are we doing the "docstrings styles" meeting or you prefer to postpone it for when you stop dancing around missing /dev nodes? <Chipaca> facubatista: trying to get there <Chipaca> firefox just crashed so there's that <Chipaca> give me 5 <Chipaca> jam, facubatista, https://r.chipaca.com/docs/_build/html/123/ops.html#ops.testing.Harness.add_relation <Chipaca> https://sphinxcontrib-napoleon.readthedocs.io/en/latest/ <jam> Chipaca, I think it is infectious <Chipaca> facubatista, jam, "more papist than the pope" <Chipaca> facubatista: WRT the import PR <Chipaca> facubatista: 1 sec phone <Chipaca> back <Chipaca> facubatista: WRT the import PR <jam> Chipaca, facubatista : https://github.com/canonical/operator/pull/252/files <mup_> PR #252: ops/testing.py: document Harness in Google style <Created by jameinel> <https://github.com/canonical/operator/pull/252> <Chipaca> facubatista: we were talking with jam earlier about it <jam> type annotations and google doc style for Harness <mup_> PR operator#252 opened: ops/testing.py: document Harness in Google style <Created by jameinel> <https://github.com/canonical/operator/pull/252> <Chipaca> facubatista: and were thinking it'd be nice to change things so that users of the fmk just needed to do <Chipaca> facubatista: from ops import CharmBase <Chipaca> facubatista: etc <Chipaca> facubatista: but only for the things that we thought were 'mainstream' public <facubatista> Chipaca, yes, we discussed it too <facubatista> Chipaca, we can do that! it's not a 5' branch, we need to discuss what we will be exposing, right? so my PR will be able to unblock people with current import errors <Chipaca> facubatista: right <Chipaca> facubatista: what I didn't want to do was have your branch close off that possibility :) but i don't think it does <facubatista> right <Chipaca> k <Chipaca> facubatista: wrt testing, why pull it in every time? is that needed to fix the issue at hand? <Chipaca> facubatista: i ask because this would be pulling it in even for in-production charms, which seems strangfe <Chipaca> strange also <facubatista> Chipaca, I included it because we may be importing testing to use the Harness even not in pure unittests. <facubatista> But I can totally remove it <facubatista> from the outside it will not change anything <facubatista> bah, less import time <mup_> PR operator#253 opened: Test harness no backend <Created by jameinel> <https://github.com/canonical/operator/pull/253> <jam> facubatista, Chipaca : https://github.com/canonical/operator/pull/253/files fixes for #241 without the backend call tracing <mup_> PR #253: Test harness no backend <Created by jameinel> <https://github.com/canonical/operator/pull/253> <mup_> Issue #241: _TestingModelBackend incorrectly raises KeyError on missing relation <Created by gnuoy> <https://github.com/canonical/operator/issues/241> * jam eod * facubatista -> errands <Chipaca> facubatista: I don't understand: yes people may be importing testing other than in unittests but why does that mean we need to import it from __init__? <Chipaca> afaict the only thing we _need_ to import are the two that confuse python wrt ordering <Chipaca> or even just the one, the one tha tneeds to come first <facubatista> Chipaca, mmm... yes, probably with just importing one, the import cycle will be solved, but wouldn't it "look" weird? <Chipaca> facubatista: it would, but that's solved by a comment explaining it :) <Chipaca> facubatista: and then when we do the work to pull in exactly what we want in 'ops', it goes away <facubatista> Chipaca, ack <facubatista> Chipaca, pushed change * Chipaca brb <mup_> Issue operator#254 opened: Improve docstrings to conform the Google Style <Created by facundobatista> <https://github.com/canonical/operator/issues/254> <mup_> Issue operator#255 opened: Incorporate type hinting in all public methods, and check them <Created by facundobatista> <https://github.com/canonical/operator/issues/255> <facubatista> niemeyer, Chipaca, may I get a review on #246? thanks! <mup_> PR #246: Made breakpoint handling code to use already parsed JUJU_DEBUG_AT, and isolated the message showing logic <Created by facundobatista> <https://github.com/canonical/operator/pull/246> <Chipaca> facubatista: will do * facubatista -> lunch <Chipaca> waaaait <Chipaca> 3.5 didn't have type hints?? * Chipaca checks <Chipaca> yes it did <jam> Chipaca, so the question, is it that it doesn't like ): on a line by itself, or it doesn't like that __init__ doesn't have a -> return hint <jam> It didn't make sense to me to add a return hint to __init__ <Chipaca> jam: __init__'s return is ignored AFAICT Â¯\_(ã)_/Â¯ <jam> Chipaca, so, not wrapping to the next line seems to pass on 3.5 * Chipaca would dance if he were a dancer <jam> eg, don't do ',\n):' but just '):' <jam> <Chipaca> waaaait <jam> https://github.com/canonical/operator/pull/252/commits/7e988b3bdc74b7061d5da213ec6ce54a387f5bfa <mup_> PR #252: ops/testing.py: document Harness in Google style <Created by jameinel> <https://github.com/canonical/operator/pull/252> <jam> of course, cut and paste correctly :) <Chipaca> jam: just one thing to note, that isn't important right now but might be later <Chipaca> jam: None isn't a string, and isn't a typing.TextIO <Chipaca> so what you really mean is Optional[typing.Union[str, typing.TextIO]], or equivalently typing.Union[str, typing.TextIO, None] <jam> Chipaca, type annotations seem like they become unwieldy <Chipaca> yes <jam> Chipaca, what syntax would you prefer? <Chipaca> jam: that's what I tried to say, earlier :-/ <jam> Optional seems to hint to the user <Chipaca> i like what they do, but they're not exactly gratis <Chipaca> OTOH you can do MyThing = typing.Optional[....] <jam> for things that aren't str or file they feel a lot better <Chipaca> Optional communicates intent better, yes. But it does evaluate to the Union one (so if you stringify it you'll see the Union) <facubatista> Chipaca, meeting? <Chipaca> facubatista: can we move our 1:1 to tomorrow? <facubatista> Chipaca, yes we can <Chipaca> facubatista: I still don't have audio and am a bit cross about that <Chipaca> would rather not do it on the phone again <facubatista> Chipaca, just send the invite :) <facubatista> or, better, first fix the audio then send the invite :p <Chipaca> man, tomorrow is solid meetings <facubatista> Thu <Chipaca> even got a conflict; i'm not going to make the standup <jam> Chipaca, OptionalYAML incoming <Chipaca> facubatista: that's two PRs you could be mergin' <facubatista> yay <mup_> PR operator#221 closed: ops/main.py: support dispatch <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/221> <mup_> PR operator#248 closed: Import internal modules in a controlled way. Fixes #247 <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/248> <mup_> Issue operator#247 closed: Circular dependency error after pulling in latest version of framework <Created by gnuoy> <Closed by facundobatista> <https://github.com/canonical/operator/issues/247> <mup_> PR operator#246 closed: Made breakpoint handling code to use already parsed JUJU_DEBUG_AT, and isolated the message showing logic <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/246> <mup_> PR operator#251 closed: Fix doctrings for add_relation_unit in ops.testing <Created by gnuoy> <Merged by chipaca> <https://github.com/canonical/operator/pull/251> <Chipaca> facubatista: can you give #253 a pass? it fixes a bug that people are having to work around right now <mup_> PR #253: Test harness no backend <Created by jameinel> <https://github.com/canonical/operator/pull/253> <facubatista> Chipaca, yes <Chipaca> timidity had sequestered /dev/snd/*! * Chipaca whacks it for its temerity <Chipaca> aaaand, I need to EOD. ttfn at least :-) * facubatista eods * Chipaca EODs #smooth-operator 2020-05-06 <mup_> Issue operator#256 opened: Upgrading charm does not recreate the hook symlinks <Created by xavpaice> <https://github.com/canonical/operator/issues/256> <mup_> Issue operator#257 opened: When install hook fails no other hook symlinks are created <Created by woutervb> <https://github.com/canonical/operator/issues/257> <jam> morning all <MarkMaglana> o/ <MarkMaglana> jam: sent you an email. i should have checked your timezone first before suggesting those times. :) <jam> hi MarkMaglana, I saw you're email, still working out what times are going to work well. I'd like to have more of the team around, but if its just us we can make that work. <MarkMaglana> it'd be good to have more of the team around to get the most feedback. i'll wait for your response then. <mup_> Issue operator#241 closed: _TestingModelBackend incorrectly raises KeyError on missing relation <Created by gnuoy> <Closed by jameinel> <https://github.com/canonical/operator/issues/241> <mup_> PR operator#253 closed: Test harness no backend <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/253> <mup_> PR operator#196 closed: Factor out the Harness changes for test_model.py <Created by jameinel> <Closed by jameinel> <https://github.com/canonical/operator/pull/196> <Chipaca> good moorning all! <jam> morning Chipaca <jam> I think https://github.com/canonical/operator/pull/252 follows the doc guidelines that we wanted, and the test suite is passing. <mup_> PR #252: ops/testing.py: document Harness in Google style <Created by jameinel> <https://github.com/canonical/operator/pull/252> <Chipaca> jam: ah, you kicked travis into submission i see <jam> Chipaca, I merged master and fixed a collision, so it had to try again :) <Chipaca> yeah <Chipaca> sometimes it be dumb <jam> I don't know how to fix it without a push <jam> Logging into TravisCI seemed like it exposed more than I wanted to travis, so I wasn't sure if I wanted to do that <Chipaca> (actually travis tries to ping back with all the authenticated users it knows of, but rate limiting is per org or something on the github side â¦ at least that's what i remember from sitting next to travis guys at a snapcraft summit ages ago ) ) <Chipaca> jam: want me to generate the docs from that so we see what they look like? <jam> Chipaca, sure. It would be good to see if there are any problems <jam> ok. if I log into travis, it gives me a 'trigger build' option. <Chipaca> jam: some of these warnings might be of interest to you: https://pastebin.ubuntu.com/p/xdtSfn4TpR/ <Chipaca> jam: and the built docs: https://r.chipaca.com/docs/_build/html/123/ops.html#module-ops.testing <Chipaca> I'll make a branch with the conf.py and the toplevel rst's so you too can build them <Chipaca> (need to fix a warning about a duff rst first) <jam> Chipaca, so most of those are in 'charm.py' which I wasn't touching. The one about 'unknown enable_hooks' is interesting. Does it need to be 'self.enable_hooks' ? <jam> Chipaca, what are you using to generate the docs, so I can iterate? <Chipaca> jam: wrt how to iterate, i need to push a pr. The minimum you need is a docs/conf.py as the rest can be autogenerated at least until we lay things out better <Chipaca> wrt gnome shell eating up all my ram, i have a background on rotation, and some of the images are large, and gnome shell seems to not check whether the image fits before loading it <Chipaca> nor does it scale it down on input like you could ask imagemagick to <jam> interesting. seems easy to disable to at least get things working until your other machine comes back <Chipaca> (how large? iirc one of the images there i used to expose a bug in the 64 bit libjpeg for an image that wasn't representable in 32 bits...) <Chipaca> yeah, once i realised what was going on i did that :) <Chipaca> hence how i'm back <jam> image that wasn't representable in 32bits... sounds like a nice test <jam> Chipaca, you mentioned you use hexchat. I currently have a concern with it, that I'm not sure the fix. <jam> If someone mentions me in a channel, it highlights that channel in green <Chipaca> as i remember it, i had to compile my own libs to be able to stitch a pair of nasa photojournal images of earth <jam> However, it just marks a channel with a conversation as red <jam> but it does that for private messages as well <jam> any way to get it to use the same Green for private messages as though I was called out in a public channel? <Chipaca> jam: where is this colour? in the notifications themselves, or in hexchat? <jam> Chipaca, the tabs along the left where it lists the channel names <Chipaca> jam: isn't it 'new message' vs 'highlight' in the interface colours? <jam> so the issue is that if there is any new message in any channel, it goes red or blue (I haven't quite figured out when it usess which) <jam> but I want new messages in private chats to be treated like notifications in public chats <jam> Chipaca, eg, I idle in about 15 different rooms in case someone pings me, and I hear a ping when someone private messages me, but finding that tab is hard, because it is a sea of 'someone said something in this channel' <Chipaca> jam: i think my hexchat config is out of whack, because i've been fiddling with it for over 10 years (migrated it from xchat) <jam> :) <jam> Chipaca, testing your colors out <Chipaca> jam: and again please (in 10 seconds, also in PM please) <jam> 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 <jam> Chipaca ! <Chipaca> OK <Chipaca> so, the private message colour is set by settings -> preferences -> colours -> new message <Chipaca> the public highlight is _not_ 'highlight' in that same thing <Chipaca> it might be â¦ spellcheck?? <Chipaca> let me confirm <Chipaca> jam: again please <jam> right, but isn't the "settings -> pref -> color -> new message" the same one that shows up for a channel where anyone speaks to anyone else? <jam> thats the difficulty <jam> private messages are 'targetted at me' though my name isn't mentioned <jam> at least, that's how it works in my head :) <Chipaca> i'd have to wait for somebody to say something in a different channel to answer that <Chipaca> people are quiet right now <jam> see private group chat for non targetted message <Chipaca> jam: that is indeed the same colour :-( <Chipaca> jam: which means <Chipaca> jam: you're probably going to have to go into 'text events' <Chipaca> and change %C28*%C29$3$1%C28*$t%O$2 to something that makes sense to you <jam> yeah, I'll just learn to love the same colors <jam> The other plugin I had in the past was one that would hide join/part messages except if the person was active recently <jam> which is relevant since you occasionally have to restart your machine in the middle of a conversation <jam> I seem to be able to hide them always, but that isn't quite what I want <jam> hm, looks like I can set it per window <jam> so at least large group chats don't have them. that's nice <Chipaca> jam: FWIW I *think* %CNN is a numbred colour in the above string, but in case it wasn't obvious i haven't dug much :) <Chipaca> anyway, now i want my old colours back * Chipaca gets them <jam> afaict, hexchat doesn't treat the events the way my brain does. Which is "if you're going to beep at me, color it green so I can find it" :) * Chipaca takes notes about how jam's brain works <jam> danger, danger, daaannn...geeeer * Chipaca locks sends the notes to SCP for safekeeping <Chipaca> s/locks// <Chipaca> jam: pushed the docs stuff <mup_> PR operator#258 opened: docs: first pass at sphinx-built API docs <Created by chipaca> <https://github.com/canonical/operator/pull/258> <Chipaca> see? :-p <jam> todo_include_todos <jam> I should do that <Chipaca> jam: FWIW that lines up (contrary-wise) to what you and facu said about TODOs *not* being in the docs <Chipaca> as in, sure have a TODO in the docstring but don't show it in the API docs <Chipaca> that's the default, which that setting toggles <Chipaca> and you can then separately use it to generate a todo list <Chipaca> to be clear: todo_include_todos should be _false_ (the default) so that TODOs don't turn up in the API docs <Chipaca> also to be clear: the current index.rst sucks because it's just too big, but it's alright to get started imho <Chipaca> we can then split, sort, tidy, etc <Chipaca> hard to tidy with nothing <Chipaca> (or maybe too easy) <jam> its super lean <Chipaca> jam: ah, yes sorry i meant the doc it generates <Chipaca> it's a single page of everything <jam> I'm just saying nothing is very lean <Chipaca> ah :) yes <Chipaca> agile, also <jam> I haven't had a chance to render it locally yet <jam> trying to finish a quick commit and then i'll review <Chipaca> jam: i can also set up rtd to generate it for you, once this is on master <Chipaca> jam: WRT dispatch not being a symlink to the charm (a feature we want IMHO), I'm afraid we need to drop the "don't look at the env" thing. This is probably fine... as long as we unset JUJU_DISPATCH_PATH <Chipaca> otherwise loopy fun could happen <Chipaca> (we try to detect and stop said fun, but Â¯\_(ã)_/Â¯) <jam> ah, because if dispatch isn't a symlink, then we don't know who the target of the link is? <jam> Chipaca, we'll have to be careful to not invoke every event 2x then <jam> eg, 'install => ../src/charm.py; dispatch: shell that invokes ./src/charm.py' that would default to firing install 2x <Chipaca> jam: hence dropping the env key <jam> Chipaca, I think we need dispatch to not just be a symlink because of the "how do you apt install things so that your python code can cleanly import them" <Chipaca> jam: yep <jam> Chipaca, even dropping the env var, we still trigger it 2x. <jam> we just don't trigger it in an infinite loop :) <jam> (doing it in dispatch also handles the "my pod got rescheduled so I need to do it again" case) <Chipaca> yep <Chipaca> jam: so main would need to check for, and ignore, hooks that get triggered via hooks/ when it's also going to be called a-la-dispatch <Chipaca> this might involve further env tweaks * Chipaca needs a whiteboard <jam> Chipaca, *setting* an env var to indicate we are running might be a better awy <jam> way <jam> we trigger but then in main we see "JUJU_DISPATCH_ALREADY_RUNNING_DONT_DO_ANY_MORE" <jam> and then exit cleanly <Chipaca> OPERATOR_DISPATCH_IN_PROGRESS_PLEASE_STAND_BY <Chipaca> PLEASE_ABSTAIN_FROM_COMING_FROM_DISPATCH * Chipaca forgets how INTERCAL works <jam> Chipaca, the compiler language with no pronounceable acronym, abbreviated INTERCAL <jam> nice <jam> Chipaca, if the word PLEASE does not appear often enough, the program is rejected as impolite, if too often, it is rejected for excessive politeness <Chipaca> jam: having to find the right balance between rude and obsequious was part of the fun <jam> Chipaca, can't you just have an array of PLEASE at the end and then trim/append as necessary ? <Chipaca> what even is an array <mup_> PR operator#259 opened: Relation created event <Created by jameinel> <https://github.com/canonical/operator/pull/259> <jam> https://github.com/canonical/operator/pull/259 expands on Dmitrii-Sh's work to provide Harness support for relation-created. <mup_> PR #259: Relation created event <Created by jameinel> <https://github.com/canonical/operator/pull/259> <jam> Chipaca, we'll just meet in the charm docs hangout * Chipaca afk (lunch) <facubatista> Muy buenos dÃ­as a todos! <jam> morning facubatista <jam> Chipaca, when you're back around, I've been trying to play with your documentation branch, and so far I haven't found a way to link to another function in a docstring <jam> Online I see things like: https://cheat.readthedocs.io/en/latest/rst.html <jam> that say you should use ":py:meth:`ops.testing.Harness.method`_" <jam> and doing so doesn't generate an error, but in the generated HTML it just puts the raw string above (which looks bad) <jam> and the link it generates doesn't seem to go anywhere. <facubatista> hola jam <facubatista> jam, did you try with a real name? (not "method") <facubatista> jam, also note there's no underscore at the end in the docs <jam> facubatista, yeah, it was real names. It was the underscore that was a problem. <jam> Which, I'd rather have `enable_hooks`_ work than :py:meth:`ops.testing.Harness.enable_hooks` <jam> but at least the latter actually creates a link <jam> actually, you likely want: <jam> :py:meth:`~ops.testing.Harness.enable_hooks` <jam> which then at least renders the HTML as 'enable_hooks()' <jam> thanks for the catch <facubatista> np <facubatista> I guess they don't use just `enable_hooks` because that name may be in different places <facubatista> I don't see what the :meth:/etc are for, maybe they are rendered differently? or there is the possibility of rendering them differently? <jam> facubatista, so why you need :py:meth: in the first place? <jam> interesting, :py:meth: also supports :py:meth:`.foo` which is quite a bit better <jam> but yeah, I'm not sure why you would need to say "I'm refering to the function, not the class" when it should be inferred by what the target is <facubatista> jam, the problem is that ops.foo.bar may be ops(pkg).foo(mod).bar(func) or ops(mod).foo(class).bar(meth) <facubatista> jam, note that you may have documentation from previous project versions which doesn't really reflect "current reality", so trying to match "real code" is not an option <facubatista> mmm... I guess old docs will be together will old code in a release branch... <facubatista> I don't know <jam> yeah. I was thinking that theoretically it could be either, but functionally you are explicitly linking to the one that can be imported. <jam> Anyway :py: doesn't do what we want <jam> but :py:meth:`.enable_hooks` does <jam> facubatista, Chipaca : it seems the docstring of __init__ is just completely ignored. So you have to put the doc string for those arguments on the Class itself. <jam> also, sphinx doesn't seem to do anything with the Type annotations (AFAICT) <jam> vs if you use the (charm.CharmBase) <jam> if you use: <jam> Args: <jam> foo (charm.CharmBase): this is a foo <jam> it will give you a link to charm.CharmBase in the docs <jam> and it doesn't do it for <jam> Args: <jam> foo: charm.CharmBase <jam> so it is special syntax around () <jam> hm. oddly it does do Return type: Mapping from type annotations <jam> and for simple types it does inject (int) from type annotations <jam> It is just the complex Optional[blah, blah] that it doesn't seem to know what to do with. <Chipaca> sorry i'm late <Chipaca> bug revue time! :) <facubatista> oh <Chipaca> jam: hm, maybe i'm missing some tweaks or sth <Chipaca> to the config i mean <Chipaca> jam: afterwards, point me at where you see this <facubatista> jam, we moved the bug review to tomorrow <facubatista> Chipaca, jam, and the charmhub x-team for today was cancelled <Chipaca> yep * facubatista brb <Chipaca> facubatista: but not the charmhub dev weekly <facubatista> Chipaca, you refer to "Weekly Operator Framework Sync"? <jam> Chipaca, is that the Kafka one ? <Chipaca> facubatista, jam, no this is charm store (for us, the charmcraft store flow) <jam> ah gotcha <jam> Chipaca, it is also possible that the fancy type annotations stuff is off because it is __init__ <facubatista> Chipaca, sorry, I don't know which one you refer to as "charmhub dev weekly" <jam> it seems that Sphinx ignores the docstring of __init__ and only uses the docstring on the class <Chipaca> jam: i've merged your testing pr in and am poking at it <Chipaca> facubatista: Â¯\_(ã)_/Â¯ dunno why you're asking me so much about my calendar :-D <Chipaca> jam: __init__ is part of it <facubatista> jam, that's a good thing IMO, __init__ shouldn't have docstrings (as any special methods) <Chipaca> jam: it seems ivar also trips it up <jam> interesting. I had an ivar though I've removed it in the latest harness-hinting <jam> and moved things to class docstring <facubatista> Chipaca, the moment you told me that the charmhub dev weekly was not cancelled, I thought I was involved <Chipaca> facubatista: you will be at some point! <Chipaca> facubatista: just not yet <jam> Chipaca, https://youtu.be/tUoBkhTFdWA?t=6 <Chipaca> jam: https://youtu.be/RySHDUU2juM?t=6 <jam> yeah :) <Chipaca> (actually wanted the seagulls one but, eh) <jam> https://youtu.be/U9t-slLl30E <Chipaca> jam: so, dropping the ivar, and setting autoclass_content = 'both' in conf.py, i think DWYW <Chipaca> jam: if you give that a try, i can add the change to conf.py in my pr if it works <Chipaca> jam: wrt documenting the ivar, using #: comments might be the way to go <jam> that particular ivar was irrelevant as it turned into a @property anyway <Chipaca> jam: and properties have a doc of the getter :) <jam> yep <Chipaca> jam: I might look into having a big fat warning message for undocumented things :-D * Chipaca is sure somebody's written that already <jam> Chipaca, doesn't pydocstyle do that? <Chipaca> jam: i think so yes <Chipaca> jam: but that doesn't make it easy to spot unless you go look at its output <Chipaca> whereas having it shout at you in the docs themselves could be the right kinda stick <Chipaca> jam: i'm only half serious fwiw <jam> Chipaca, autoclass_content = 'both' seems to do what I was expecting for the class docstring <jam> it drops the nice name of "OptionalYAML" in favor of Union[str, TextIO, None] which isn't great from a 'communicate to the user' perspective, but at least it renders something > nothing <facubatista> Chipaca, jam, standup? <jam> Chipaca, did we lose you? <karimsye> is there a preferred way of keeping/maintaining the podSpec in a charm. should I use a podSpec YAML file that gets loaded and populated based on charm config or should the charm create a podSpec dictionary from scratch based on config options? <jam> karimsye, most charms that we've seen so far do more of a dict that fills in aspects from config/relation-get etc. <jam> otherwise you are applying a template in order to load it from yaml, to do essentially the same thing. <jam> that said, people have said that they'd prefer to render a yaml template and load it to pass it in. likely because the examples they are cribbing from were yaml to start with <karimsye> jam: thanks, I like the YAML template file as well * Chipaca EODs * facubatista vanishes away #smooth-operator 2020-05-07 <jam> morning all <MarkMaglana> o/ <Chipaca> mo'in <Chipaca> jam: https://r.chipaca.com/land_shallow_topo.jpg (to be fair it might have bitrot at this point, without me noticing :) ) <jam> Chipaca, it doesn't render very well here. <Chipaca> yeah, here either, and imagemagick now has limits in place that block it from touching the image even (without further tweaking) <Chipaca> which was precisely the point the image was trying to make, so i won i guess? <jam> Chipaca, "I Win" :) <Chipaca> quite <Chipaca> jam: an interesting thing came up in the call yesterday, with narinder <Chipaca> jam: he's going to file a bug about it, but i don't think he has yet <Chipaca> jam: but if you look at https://github.com/narindergupta/charm-k8s-kafka/blob/master/src/charm.py <Chipaca> jam: at expose_relation_data <Chipaca> jam: ISTM that having to do that getnameinfo thing is not particularly friendly <jam> Chipaca, indeed. I know that there has been discussions on the Juju side of how to present a hostname when you have one <jam> It certainly is never guaranteed that there *is* a hostname for a unit <jam> And if there is one (in say, MAAS) it may not be accessible because the DNS server is local <jam> I also know of bugs like https://bugs.launchpad.net/juju/+bug/1867168 <Chipaca> jam: yeah, that sounds like exactly the issue <Chipaca> facubatista: this Friday we scheduled a meeting with people writing a postgres charm (i'm assuming for k8s). Neither jam nor I work this Friday :) should we reschedule, or are you happy to carry it alone? <jam> is he in yet? <jam> I would recommend rescheduling, as that is one that I'd like to be at <Chipaca> jam: I'll ask sohini to transfer these to me so we can move them around <jam> Chipaca, given that the bug is about the charm-k8s-mongodb it sounds very much like that bug <Chipaca> jam: btw, are https://github.com/narindergupta/charm-k8s-kafka/ and https://github.com/narindergupta/charm-k8s-zookeeper/ on the list? (i don't see them) <jam> Chipaca, they are now :) <Chipaca> jam: taw <jam> Chipaca, is there a notes doc about Kafka meeting? <Chipaca> jam: i need to transfer my notes onto a doc <Chipaca> jam: and, in future ones, start with a shared doc so we edit it as we go <jam> Chipaca, so I mentioned I was investigating creating symlinks earlier (before instantiating the charm) <jam> it is certainly 'doable' but it changes a bit <jam> namely, Events currently get their name from being assigned as an attribute to a class <jam> (install = EventSource(InstallEvent) is how we know the hook is 'install') <jam> I could change it so that the name of the associated hook is part of the base event, but it felt like a pretty significant departure <jam> so I wanted to check before I proceeded <Chipaca> it does feel a bit nastier <Chipaca> OTOH the know-thy-name magic might prove to be too magic at some point <jam> Chipaca, so in my head I was going to a registry of hook events so that we can easily iterate them. right now that "registry" is CharmEvents and iterating the attrs of it <jam> Chipaca, ObjectEvents.events() uses inspect.getmembers(type(self)) <jam> which seems an odd way to do a registry to *me* <Chipaca> jam: oh so it _doesn't_ use set_name-like magic <Chipaca> my bad :) <jam> Chipaca, oh, it does <jam> it does both :0 <jam> Chipaca, event_kind is used as the name, which is populated during __init__ because of calling getattr() <jam> AFAICT <jam> _create_event_link looks at 'bound_event' which has an 'event_kind' which is the name of the attribute <jam> (it could have just as easily used the 'key' portion of the key:bound_event map, but chose to just call values() and then iterate those) <facubatista> Muy buenos dÃ­as a todos! <Chipaca> facubatista: buen dÃ­a! <Chipaca> facubatista: could you review #258? <facubatista> Chipaca, sure <facubatista> Chipaca, regarding friday meeting, I can take it, but if jam wants to be there, we can reschedule it, yes <jam> morning facubatista <facubatista> hola jam <facubatista> meeting is in standup room? <jam> I added a room, but I'll happily move to standup since I added it late <facubatista> ah, no <facubatista> I'm in the other one <jam> Chipaca, coming? https://meet.google.com/pmg-hccz-tqd <facubatista> niemeyer, hello! any chance you leave a mup with us? <niemeyer> facubatista: Sorry, machine crashed yesterday and I forgot to bring it back up.. still haven't managed to put it in a stable place <facubatista> niemeyer, no worries! thanks! <facubatista> jam, Chipaca, ...? <facubatista> jam, we lost you <jam> brb <jam> https://paste.ubuntu.com/p/GFFXXrwKCW/ <Chipaca> jam, facubatista, wrt ops.lib.use, in practice it'll be lib.use(), no? because 'from ops import <>' is the pattern we're encouraging <Chipaca> or maybe even use() <facubatista> I like lib.use() <Chipaca> from ops.lib import use as frameworkify * Chipaca hides <jam> mysql = frameworkify('mysql') <jam> nice <Chipaca> jam: also, binding.ports[1000:1024].open() <facubatista> binding.ports[1000:1024].open(name='foo') <facubatista> binding.ports.close('foo') <facubatista> binding.ports[1000:1024].close() <Chipaca> facubatista: where are we planning on saving 'foo'? <facubatista> Chipaca, some StoredState? <Chipaca> facubatista: AIUI this means the ports depends on saving state in the controller <facubatista> Chipaca, we can not depend on that? <facubatista> Chipaca, we're saving the events already, right? <Chipaca> facubatista: not in the controller yet <Chipaca> it's saved in a local db <facubatista> Chipaca, why the ports storage would be different? <Chipaca> facubatista: i might be getting this wrong but i think the pod can be replaced at any time at which time we lose? but maybe not, the local db <Chipaca> ah no the db is not in the pod <Chipaca> that's the problem with actions <Chipaca> facubatista: ignore me, brain wongled <Chipaca> facubatista: but don't ignore me _too_ much :-p * facubatista ignores odd chars in Chipaca sentences <Chipaca> facubatista: any char < 2019 is rubbish anyway <Chipaca> facubatista: ð§ð§ð§ <facubatista> ja <Chipaca> facubatista: plz don't forget to review the docs one <facubatista> extensions = [ <facubatista> 'sphinx.ext.autodoc', <facubatista> ops.lib.use('autodoc') <facubatista> Chipaca, some questions inline <facubatista> also, I don't remember why we still don't have a proper requirements-dev.txt file with flake8, autopep8, etc <Chipaca> facubatista: I don't remember what happened to your PR with that <facubatista> Chipaca, it's a good moment to add it <Chipaca> facubatista: what happened to that PR? <facubatista> Chipaca, we end up not automatizing the virtualenv creation, so the dependencies ended up in the README <facubatista> (I landed that improvement over "you find out by trial and mistake what you need" as a middle ground) <Chipaca> facubatista: you _don't_ need sphinx for dev though, rtd will build them for us <facubatista> Chipaca, unless you want something to be fixed, for when you want to check how it looked before and after <facubatista> but yes, that will not happen always <facubatista> Chipaca, maybe a docs/requirements.txt ? <facubatista> docs/requirements-build.txt ? * Chipaca adds a facubatista/requirements.txt * facubatista is very requiremented * Chipaca also adds a .snapcraft/you-might-be-lost.md #smooth-operator 2020-05-08 <MarkMaglana> hi all o/ <facubatista> Muy buenos dÃ­as a todos! <mup_> Issue operator#261 opened: Harness should support pod-spec-set <Created by jameinel> <https://github.com/canonical/operator/issues/261> <mup_> Issue operator#262 opened: Harness should support resource-get <Created by jameinel> <https://github.com/canonical/operator/issues/262> <mup_> Issue operator#263 opened: Harness should support storage-get and storage-add <Created by jameinel> <https://github.com/canonical/operator/issues/263> <mup_> PR operator#264 opened: Test harness backend calls <Created by jameinel> <https://github.com/canonical/operator/pull/264> * facubatista -> lunch <mup_> Issue operator#265 opened: Auto determining handlers is actually not recommended <Created by jameinel> <https://github.com/canonical/operator/issues/265> <cmars> hi, what's the best way to ask for a review of an operator charm? is here the right place to ask, or should i start a discourse thread (and if so, how/where/what category)? <cmars> this is my charm: https://github.com/cloud-green/timescaledb-charm/tree/master/charm/timescaledb. really simple timescaledb subordinate that adds the extension to postgresql <cmars> want to rid myself of any bad habits before they get too ingrained :) esp as i'm considering some non-trivial ones next... <mup_> Issue operator#266 opened: 'smooth' pypi project name <Created by phinate> <https://github.com/canonical/operator/issues/266> <facubatista> cmars, hello! <facubatista> cmars, this is the correct place to ask, yes! we don't have a structure to annotate these, I will open an issue in the project so this is not forgotten <mup_> Issue operator#267 opened: Review timescaledb-charm <Created by facundobatista> <https://github.com/canonical/operator/issues/267> <facubatista> cmars, ^ <cmars> facubatista: thanks! <mup_> PR operator#258 closed: docs: first pass at sphinx-built API docs <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/258> <mup_> PR operator#268 opened: docs: rtd uses 'sphinx<2', which is slightly different <Created by chipaca> <https://github.com/canonical/operator/pull/268> <Chipaca> facubatista: if you could once-over this to make sure it's not entirely wrong i'd appreciate it <facubatista> Chipaca, 268, you say? <Chipaca> yeh <Chipaca> facubatista: i thought i'd land the docs one and build rtd, and it failed because they're using 'sphinx<2' <Chipaca> (in their defense, that's what sphinx calls stable) <facubatista> Chipaca, you landed already the other branch? <Chipaca> facubatista: yes <facubatista> Chipaca, any reason you didn't create the reqs file? what dependency shall I install for this? <Chipaca> facubatista: eh, i'll add a docs/req <Chipaca> facubatista: pushed <Chipaca> facubatista: suspecting we're going to also need to add a requirements.txt with PyYAML in it <Chipaca> but we'll see <facubatista> Chipaca, I think we should have a requirements.txt and requirements-dev.txt as most Python projects, and
{'channel': 'smooth-operator', 'month': 5}