#smooth-operator 2020-05-11
<jam> morning all
<mup_> Issue operator#269 opened: Warn that model.unit.is_leader() can raise an exception <Created by timClicks> <https://github.com/canonical/operator/issues/269>
<Chipaca> morning!
<mup_> PR operator#218 closed: Add relation-created events <Created by dshcherb> <Closed by jameinel> <https://github.com/canonical/operator/pull/218>
<mup_> PR operator#259 closed: Relation created event <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/259>
<Chipaca> jam: I'm going to create a separate 'docs' branch on github to debug the rtd, then propose a pr from that
<jam> Chipaca, sounds good to me. The RTD docs that I saw linked over the weekend seemed to be missing all the actual *content* :)
<Chipaca> jam: yeah, not sure what i broke :-(
<jam> Chipaca, for user facing docs, I'm looking to remove __init__ comments and move them into class docstrings
<jam> Chipaca, do you have a preference on type annotations between typing.Mapping and 'dict' ?
<jam> Chipaca, the HTML title for https://www.sphinx-doc.org/en/master/ seems to say 4.0.0+ but pypi is 3.0.3 and you're saying that stable is <2 ?
<Chipaca> jam: wrt typing.Mapping and dict, I'd go with dict for now for brevity
<jam> Chipaca, for the class docstring, it feels a little weird because you want to document how to use the class as well as how to construct it, and the former is 'variables' while the latter is 'args'.
<Chipaca> jam: sphinx-doc.org/en/stable is 1.8 yes
<jam> Chipaca, that specific link takes me to en/master
<Chipaca> er
<Chipaca> jam: https://www.sphinx-doc.org/en/stable/usage/configuration.html
<jam> ah, www matters
<Chipaca> or maybe the deep link vs directory? dunno
<Chipaca> jam: tbh my first reaction was 'why on earth are you getting sphinx<2', noticing it's what's tagged stable came later
<jam> :)
<jam> Chipaca, type annotations seem to poke at the 'recursive import' problem.
<Chipaca> i haven't asked my friend on the inside as to whether there's a way to change that (it doesn't seem to be documented that you can)
<jam> sorry, circular import problem
<Chipaca> jam: using strings instead of obects doesn't help in that case?
<jam> Chipaca, I didn't know you could
<Chipaca> jam: i'm not sure it helps, i'm asking :) it's there for things like class C taking a D and class D taking a C
<jam> Chipaca, https://www.python.org/dev/peps/pep-0563/
<Chipaca> but not sure it copes with imports
<jam> and reading through https://stackoverflow.com/questions/39740632/python-type-hinting-without-cyclic-imports
<jam> which seems to say you can use 'if TYPE_CHECKING' to pre-import stuff
<jam> Chipaca, from __future__ import annotations changes all type annotations to strings
<jam> but only works for py 3.7??
<Chipaca> jam: note that PEP is 3.7+
<Chipaca> yeh
<jam> I also don't know if I strictly cannot do what I want, I just noted that as I was trying to add a type annotation I was going to have to add an import just to satisfy that which felt like I was going to quickly run into circular imports
<jam> Chipaca, I'm not a big fan that Optional gets remapped to Union[...,None]
<Chipaca> jam: yeah i get why but i wish it had its own stringify
<jam> because a default value might not be None, and loses the human message of what Optional is for
<Chipaca> yep
<Chipaca> aha! found the issue :)
<Chipaca> jam: https://operator-framework.readthedocs.io/en/docs-tri/
<jam> Chipaca, is that your recommended theme ?
<jam> it generally looks like the content is there
<Chipaca> jam: that's the default rtd theme
<Chipaca> jam: which has a few nice features (like the 'edit on github' button)
<Chipaca> jam: I don't know if it's enough to make type annotations work. They _should_ but i haven't tested.
<Chipaca> i'll propose these changes into master now
<mup_> PR operator#270 opened: docs: more tweaks so everything works on RTD <Created by chipaca> <https://github.com/canonical/operator/pull/270>
<Chipaca> eeee, my laptop got back
 * Chipaca gets coffee
<mup_> Issue operator#271 opened: Relation.role should be 'peer' not 'peers' <Created by jameinel> <https://github.com/canonical/operator/issues/271>
<Chipaca> jam: "raises" is also interesting in that list
<Chipaca> 'that list' being the one in napoleon/docstring.py:142
<jam> Chipaca, yeah. raises I think I used in one place for Harness
<Chipaca> :+1:
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: o/!
<Chipaca> facubatista: just in time :-D
<Chipaca> not sure why i thought you weren't coming to this one
<vgrevtsev> hi team, a question: is there any example of using a new `dispatch` hook within the charms? the only reference I found was in the juju source code itself, which is better than nothing, but maybe someone have an example handy?
<Chipaca> vgrevtsev: right now, all you do is symlink 'dispatch' to the main charm python file and that's it
<Chipaca> vgrevtsev: and if you don't care about pre-dispatch jujus, you don't need hooks/ at all
<vgrevtsev> hm, so it won't make any difference in the charm behaviour atm then?
<vgrevtsev> do you know where can I get more information about the dispatch hook, is it somewhere available or it's kind of hidden knowledge? :) https://discourse.juju.is/t/charm-hooks/1040 there's no info yet...
<jam> Chipaca, for now I added it as a URL in the description, I didn't see a way to have it as a more concrete object
<Chipaca> vgrevtsev: you calling it a 'dispatch hook' makes me think you're misuinderstanding it
<Chipaca> vgrevtsev: it's not a hook
<Chipaca> vgrevtsev: it's a way of dispatching hooks
<Chipaca> vgrevtsev: mostly it should be invisible to charm developers
<vgrevtsev> Chipaca: probably, will be happyto learn what's it is in reality! I'm kinda new to the things so I'm sorry for a stupid questions :)
<Chipaca> vgrevtsev: that is, today in juju the way it handles say an 'install' hook is by looking for hooks/install
<Chipaca> vgrevtsev: once 2.8 is out it'll look for 'dispatch', and if that exists it'll run it instead of hooks/install, telling it 'yeah please run the install hook'
<Chipaca> vgrevtsev: that's all it is
<vgrevtsev> ok, got it
<vgrevtsev> so, the new framework already supports this way of dispatching the hooks?
<Chipaca> vgrevtsev: there is an initial implementation of support for it, and we'll be improving it with time, but yes
<Chipaca> vgrevtsev: right now it supports a dispatch that's a symlink to the charm code
<Chipaca> later we'll support some other scenarios :)
<mup_> PR operator#272 opened: ops/charm.py: Update the Docstrings to Google style <Created by jameinel> <https://github.com/canonical/operator/pull/272>
<Chipaca> facubatista: plz can i have review of #270? (or i could just land it if you're busy(
<mup_> PR #270: docs: more tweaks so everything works on RTD <Created by chipaca> <https://github.com/canonical/operator/pull/270>
<Chipaca> ))
 * Chipaca ~> lunch
<facubatista> Chipaca, meeting?
<Chipaca> yes
<karimsye> missing a link to the google meeting
<facubatista> indeed, I was about to say that
<Chipaca> karimsye, jam, facubatista, added meet link
 * facubatista brb
<Chipaca> laptop is indeed back, but i can't get the hardrive back into it because they've tightened the t5 screws harder than my screwdriver can handle :-(
<Chipaca> so i've got a nice paperweight until i get a new screwdriver
<mup_> PR operator#270 closed: docs: more tweaks so everything works on RTD <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/270>
<mthaddon> jam: is it worth t0mb0 investigating the "defer events stacking up" issue given our discussions earlier today, or is it no longer worth him doing that at this point? (I think he was planning to do this on Wednesday)
<Chipaca> mthaddon: I'd like to know what it was you were seeing, fwiw
<mthaddon> Chipaca: ack, thx
<jam> mthaddon, at the very least it would be good to confirm that my prediction is accurate
 * mthaddon nods
<jam> Chipaca, my working guess is that it is the 'same hook' that happens multiple times, and all of those instances of 'config-changed' end up as events in a queue
<Chipaca> jam: but why would that have trouble in a low memory deploy
<Chipaca> that's what i'd like to figure out (and potentially fix)
<jam> Chipaca, I don't see how it has memory consequences as much as having "I've defered config-changed 10 times and now I get them all one-after-another"
<jam> (defering config-changed never sounds like the right thing to do, because if the config is wrong, you have to wait until you get a new config-changed telling you that it might be correct now)
<Chipaca> jam: right, but IIUC there were memory issues
<jam> Chipaca, right, if that's true, then we definitely want to understand why
<facubatista> Chipaca, do you have some WD40?
<facubatista> jam, if I set manually the state to "maintenance" while installing some stuff, shall I manually set it out of that when finish? or that should happen automatically as the install hook ended fine?
<jam> facubatista, Juju won't change states for you, as the state might span multiple hooks
<jam> Chipaca, #252  would appreciate your approval
<mup_> PR #252: ops/testing.py: document Harness in Google style <Created by jameinel> <https://github.com/canonical/operator/pull/252>
<facubatista> jam, ack, thanks
<Chipaca> jam: #252 GTG
<mup_> PR #252: ops/testing.py: document Harness in Google style <Created by jameinel> <https://github.com/canonical/operator/pull/252>
<Chipaca> jam: https://pastebin.ubuntu.com/p/mRZKVKV4Gc/ :-(
 * facubatista -> lunch
 * facubatista is back
<Chipaca> https://github.com/sphinx-doc/sphinx/pull/7655 (fingers crossed)
<mup_> PR sphinx-doc/sphinx#7655: Make sphinx.util.typing.stringify render optional unions better <Created by chipaca> <https://github.com/sphinx-doc/sphinx/pull/7655>
 * Chipaca steps away for dinner & etc
 * facubatista brb
<Chipaca> facubatista: can you s/charm/charmcraft/ in charmcraft#1?
<facubatista> Chipaca, ah, the name of the tool in argparse?
<Chipaca> facubatista: and the files and the readme
<facubatista> ah
<facubatista> Chipaca, pushed
<Chipaca> facubatista: +1 with some non-blocking nits
<facubatista> Chipaca, thanks
<Chipaca> facubatista: next time you push a commit to that pr it should trigger travis
<facubatista> Chipaca, awesome
<mup_> PR operator#273 opened: Moved create_model and create_framework from framework tests to a factory helper <Created by facundobatista> <https://github.com/canonical/operator/pull/273>
#smooth-operator 2020-05-12
<MarkMaglana> Hi. Sharing my early attempts at using the test harness for feedback. I <3 how it simplifies my unit test drastically! https://github.com/relaxdiego/charm-k8s-grafana/commit/38fa63ad8918d0a178986ccc2032d89994029392
<MarkMaglana> (Ignore the FrameworkAdapter for now. I'm seeing the light and may soon have no need for it)
<MarkMaglana> Question: What is the recommended way to get the model name? I've been using `os.environ["JUJU_MODEL_NAME"]` in my code but I suspect that's not the smartest way.
<jam> morning all
<jam> MarkMaglana, good to hear you're finding Harness good to use.
<jam> MarkMaglana, I don't think we currently expose JUJU_MODEL_NAME from the framework. something like self.model.name sounds like the place to put it
<jam> can you file a github issue?
<jam> MarkMaglana, along with your use case as to what you need the model name for
<jam> (generally charms shouldn't care, but I think for K8s you need it to configure pod names)
<MarkMaglana> @jam thanks for the reply! yes you got it right, it's for getting the underlying k8s pod's status so i can report its liveness/readiness back to Juju via OF.
<MarkMaglana> i'll go ahead and file that github issue
<MarkMaglana> 13:41:26 <jam> MarkMaglana, good to hear you're finding Harness good to use. <--- As a friend used to say "the best code is the one I don't have to write!" and I adhere to that where feasible. :-)
<jam> morning Chipaca
 * Chipaca is being phone support rn
<Chipaca> now yes
<Chipaca> jam: morning! :-)
<jam> Chipaca, how's the new/old laptop treating you? did they fix the issue?
<Chipaca> jam: I haven't been able to get the hard drive back into it yet, they tightened the screws past what my screwdriver could do (have ordered a new one)
<Chipaca> my T5 head died to bring me this information
<jam> Chipaca, wow, a whole new laptop just for a couple screws :)
<jam> (ah the joy of english ambiguity)
<Chipaca> :)
<Chipaca> i probably could've phrased it better (but why would i)
<jam> you were perfectly understandable, I just enjoy puns
<Chipaca> also, that laptop is coming up for its 3rd anniversary, so shold i really call it 'new'
<jam> my laptop is now 'bowed' so I'll need to get something new before the next sprint. Whenever we actually meet in person again :)
<jam> its also fairly old, so I've been wanting to update it anyway
<mup_> Issue operator#274 opened: Currently no way to get the model name <Created by relaxdiego> <https://github.com/canonical/operator/issues/274>
<mup_> PR operator#252 closed: ops/testing.py: document Harness in Google style <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/252>
<Chipaca> jam: bowed?
<Chipaca> makes me think the battery's bulging, but that's probably the wrong meaning
<jam> Chipaca, nope, that's exactly what I mean
<Chipaca> youch
<Chipaca> you removed the battery, yes?
<jam> Chipaca, I drained the battery so it isn't powered, but it is a Mac and I don't have the little torx. I need to take it to the shop
<Chipaca> ah. little torxes and the little prying pluck needed, right?
<Chipaca> jam: my old canonical-bought mac laptop developed that, and the shop here swapped the battery for a new one for 50Â£ IIRC (pre-corona obvs)
<Chipaca> that first my is about possession, not ownership fwiw
<jam> yeah, it only really started bowing about 2 weeks ago, and I only use it when traveling so it hasn't been high priority
<Chipaca> jam: i'd be freaking out about it catching fire, but that's probably because everything around me is flammable
<Chipaca> also inflammable
<jam> Chipaca, I've been looking at some of the network-get support. It is straightforward to let people do 'pre-canned' responses, but I'd like to actually design something that is better for testing your stuff
<Chipaca> it was the only time i've noticed these houses are basically chimneys filled with kindling
<jam> should I start with  the former as I design the latter? or skip it because we don't really want people to have to know the details
<jam> and/or we should probably talk through what we think are ideals for how people would interact with networking and charm testing.
<Chipaca> jam: the latter sounds more powerful, but the devil is in the details (and schedules)
<jam> Chipaca, indeed.
<Chipaca> jam: want to timebox some design and see where we get?
<jam> sounds reasonable
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> whaaat
<Chipaca> facubatista: cucha nene
<jam> morning facubatista
<facubatista> hola Chipaca, jam :)
<Chipaca> jam: on an unrelated note, did you see my bug+patch to sphinx?
<jam> Chipaca, link?
<jam> btw, https://github.com/canonical/operator/pull/272 needs your eyeballs
<mup_> PR #272: ops/charm.py: Update the Docstrings to Google style <Created by jameinel> <https://github.com/canonical/operator/pull/272>
<Chipaca> jam: https://github.com/sphinx-doc/sphinx/pull/7655
<mup_> PR sphinx-doc/sphinx#7655: Make sphinx.util.typing.stringify render optional unions better <Created by chipaca> <https://github.com/sphinx-doc/sphinx/pull/7655>
<jam> Chipaca, ah, so that was doing Optional if you had exactly 1 type and None as the other option?
<Chipaca> jam: it was doing Optional[foo], but not Optional[Union[foo, bar]]
<Chipaca> ie it was doing Union[foo, None] but not Union[foo, bar, None]
<jam> Chipaca, presumably if you did Union[foo, None] it would also translate that to Optional[foo] as well ?
<Chipaca> yep
<Chipaca> jam: btw, compare https://operator-framework.readthedocs.io/en/latest/#ops.testing.Harness and https://operator-framework.readthedocs.io/en/docs-tri/#ops.testing.Harness
<facubatista> Chipaca, #!/bin/bash -> #!/bin/sh ... I always don't know if (why) it's better to use `sh` there
<jam> Chipaca, i'm a bit surprised to see all Unions end up with Optional
<jam> but if that is all they track, then I guess
<Chipaca> facubatista: smaller and faster
<Chipaca> jam: yeah i was surprised as well (but the current Optional becomes Union isn't very good either)
<jam> 'dash' is the current /bin/sh which is Posix compliant, but not Bash compliant
<facubatista> Chipaca, and for anything not "real command line usage", the same than bash?
<facubatista> oh:
<facubatista> $ ll /bin/sh
<facubatista> lrwxrwxrwx 1 root root 4 ago 11  2018 /bin/sh -> dash
<facubatista> nice
<Chipaca> facubatista: unless you need bash features in your script, then yes
<jam> https://wiki.archlinux.org/index.php/Dash claims it is 4x faster than bash and smaller footprint
<Chipaca> some things in bash are nice / very convenient
<jam> it doesn't have support for things like arithmetic in shell IIRC
<jam> I remember when Ubuntu switched and it broke a lot of scripts that assumed /bin/sh was bash
<Chipaca> arithmetic yes, that's posix afaik
<Chipaca> $ sh -c 'echo $((1+1))'
<Chipaca> 2
<Chipaca> no $RANDOM though
<facubatista> $ python3 -c "print(1+1)"
<facubatista> 2
<facubatista> :p
<Chipaca> no brace expansion
<Chipaca> no a..b expansion
<facubatista> Chipaca, for the docstring, what about "Must override in each command with its respectively core working code."?
<Chipaca> facubatista: what is 'core working code'?
<facubatista> Chipaca, *the code* of the command that makes the command do what the command does
<facubatista> the rest is just boilerplate to make that code run
<jam> apt install devtools comes with 'checkbashisms'
<jam> though it is written in perl...
<Chipaca> jam: shellcheck will look at the #! line and tell you about them in excruciating detail
<jam> https://mywiki.wooledge.org/Bashism
<Chipaca> facubatista: how about something more like "this is called to have the command do its work, and should be overridden by the command implementation" or something?
<jam> keyword 'function', for loops, extended globs
<facubatista> Chipaca, I never know the "tone" of the docstrings when "imperative" doesn't fit
<Chipaca> jam: command substitutions also
<jam> Chipaca, https://operator-framework.readthedocs.io/en/latest/#ops.testing.Harness doesn't seem to have a link for the types
<Chipaca> facubatista: threading.Thread's run method says "Method representing the threadâs activity.\n\nYou may override this method in a subclass. [...]"
<jam> with: https://operator-framework.readthedocs.io/en/docs-tri/#ops.testing.Harness I can click to jump to CharmBase
<Chipaca> jam: yep, and latest has the types in the signature which gets messy
<jam> (and I personally prefer Parameters as a section that doesn't cause the params to indent as far)
<facubatista> Chipaca, improving also the docstrings of that whole class
<Chipaca> jam: is there anything in docs-tri that's off?
<Chipaca> or, is there anything in latest that's better than the one in docs-tri
<Chipaca> turns out it was easy to get rtd to use latest sphinx :-)
<jam> Chipaca, I do find latest harder to read for advanced type signatures, I find it kind of snazzy for simple ones, eg: https://operator-framework.readthedocs.io/en/latest/#ops.testing.Harness.set_leader
<jam> latest looks 'more like the source' but definitely Harness.__init__ gets ugly
<Chipaca> yeah, on both points
<Chipaca> i can probably put the types back in the signature, and they might be a bit better than latest
 * Chipaca tries
<jam> Chipaca, I'm used to typed languages, so seeing types in my signatures is expected and comforting. I don't know that others feel that way :)
<jam> I think there are pros and cons of either path. I really like being able to go to the link of "what is this type" so you can figure out how you might want to interact with it.
<Chipaca> jam: setting the type hints back in the signature does not look any better than on 'latest' with the newer sphinx, meaning add_leader looks good but e.g. update_config already looks scary
<jam> does key_values: dict = None give a better result?
<jam> and List[str] vs Iterable[str]
<Chipaca> jam: also it's not a link in the signature :-/
 * Chipaca checks
<jam> The goal was to not say "this has to exactly be a list object" but Iterable feels overly abstractd
<jam> saying list felt bad when I set it to the empty tuple as the default value :)
<jam> (cause if you set it to [] then linters complain that you're setting a default to a mutable value)
<facubatista> right, don't use [] as default, ever
<Chipaca> saying list and setting it to default to a tuple would also cheese off mypy
<facubatista> well, 99.999% ever :p
 * Chipaca was already thinking of counter-arguments to "ever"
<facubatista> jam, "iterable" is a totally firm thing in Python, sounds good
<Chipaca> jam: no it doesn't look particularly better with List/Dict instead of Iterable/Mapping
<jam> facubatista, yeah, I do remember doing it in the past, and using it to populate a dict or something, and then suddenly adding a value here was adding it there too
<Chipaca> still wraps
<facubatista> Chipaca, I used {} once in real code :D
<Chipaca> shocking
<facubatista> but not as a "default parameter", just a "dict I wanted to have inside the function definition between calls for caching"
<Chipaca> so, ok, i'll push the change from docs-tri to a pr once again :)
<mup_> PR operator#275 opened: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/275>
<jam> Chipaca, you asked for it to be merged into docs-tri
<jam> so it doesn't show any diff and says already merged
<Chipaca> hah
<mup_> PR operator#275 closed: explicitly ask for a newer sphinx on rtd <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/275>
 * Chipaca <~ dumb banana
<jam> Chipaca, you can change the target branch after proposing it
<facubatista> Chipaca, just pushed the charmcraft branch
<facubatista> let's see how travis goes
<Chipaca> jam: docs-tri on rtd now has the charm changes
<Chipaca> if you're wanting to look at that
<Chipaca> need to fix that pr now :)
<mup_> PR operator#276 opened: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/276>
<Chipaca> my new T5 arrived! brb
<facubatista> wee, "a man and a screwdriver", the movie
<jam> Chipaca, that seems very fast
<Chipaca> jam: i'm spoiled, geographically
<facubatista> Chipaca, more important: were you able to open the laptop?
<Chipaca> facubatista: yes! uefi's all messed up and my bios has more enterprisey features than when it went off but everything seems ok
<facubatista> good
<facubatista> jam, re #269 ... I understand why calling other_unit.is_leader() is a bad thing, and I think it's better to raise an exception than answering False or None... but if "you should not call is_leader on a different unit", maybe we shouldn't expose it?
<mup_> Issue #269: Warn that model.unit.is_leader() can raise an exception <Created by timClicks> <https://github.com/canonical/operator/issues/269>
<jam> facubatista, that was my point as well, trying to not have the method vs having it but being a runtime error
<jam> but it means having multiple Unit types one representing *you* and one representing all the other units
<facubatista> otoh, it looks weird if Unit (as the object) exposes the method *sometimes*
<facubatista> jam, thinking out loud, what if we deprecate Unit.is_leader, and we add something `self.is_unit_leader()`?
<jam> I don't think this is going to be the only thing that you can do on yourself that you couldn't do on another.
<jam> so I'm not opposed to having a different type for the Unit representing you
<facubatista> OTOH, I feel better to do `wrong_unit.is_leader()` and getting SomeError("You're calling is_leader on a different Unit that yours, which doesn't make sense") than a silly AttributeError
<facubatista> So, current solution is the best (TM)
<facubatista> (maybe we could improve the exception message)
<facubatista> jam, this is all yours: https://github.com/canonical/charmcraft/pull/1
<mup_> PR charmcraft#1: Draft to show several characteristics <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/1>
<jam> facubatista, yeah, I think it is a fair trade for where we are at. AttributeError hints at a programmer error as well to me (and your editor won't try to fill it in for you)
<facubatista> jam, but AttributeError is obscure, when you have that method in "other" units... like, using it, getting the error, reading it and thinking "mmm... the Unit has not is_leader method???", going to the code, *seeing it*, seeing other code that uses it just fine, etc
<facubatista> getting SomeError(VERY_GOOD_EXPLANATION) would totally help
<jam> yeah, that is what we've been using RuntimeError for, figuring out language that people understand for that is probably the point
<facubatista> jam, I'd improve the message... "cannot determine leadership status for remote applications" looks like "the process wasn't able to do that at that time"
<jam> invalid request: leadership status of remote units is not available
<jam> invalid request: you can't do that dave
<jam> is_leader is only valid for yourself
<facubatista> "is not available" <-- again, looks like messaging failed or network glitch
<facubatista> I'd totally go with "you can't do that dave"
<facubatista> and we can have a counter, if you call that more than three times, the exception message turns into Daisy Bell lyrics
<jam> leadership status of remote units is not visible to other applications
<jam> leadership status is only visible for your own application
<__chip__> eeee
<__chip__> eeeâââ
<__chip__> âââÉÉÉ
<__chip__> convincing my laptop that I _didn't_ have windows, nor did i want to 'repair' it for the lack, was harder than i expected
<__chip__> now i need to sync my work back and I'll be set :-D
<Chipaca> anyway, time for a break
<Chipaca> __chip__: can i get you a coffee?
<__chip__> Chipaca: please
<jam> Chipaca, I'll go make one now, come by anytime to pick it up
<__chip__> jam: ð
<facubatista> Chipaca, jam, is the "charm docs daily" currently a thing?
<jam> facubatista, it has not been happening but we've been stopping by to check each day
<facubatista> jam, "polling"
<__chip__> facubatista: "it's complicated"
 * facubatista is complicated
<MarkMaglana> jam and and __chip__ aren't really in the same house/neighborhood are they?
<jam> MarkMaglana, __chip__ is Chipaca's other machine
<jam> and no, we're continents apart
<jam> hence why I can offer to make as many coffees as I want
<jam> :)
<MarkMaglana> lol OK. then can I have a cup as well, pretty please?
<__chip__> jam: just one
<__chip__> continent i mean
<jam> MarkMaglana, happy to
<jam> I'm going to have a hard time sleeping with all these extra coffees lying around
<jam> Can't let them go to waste
<MarkMaglana> might as well add some cold brew in that mix topped by whole milk foam and some simple syrup.
<__chip__> dalgona also
<jam> I have not had dalgona before
<jam> seems interesting
<__chip__> what's up with the failures in travis wrt the test main charm?
<__chip__> jam: we'd have it frequently in high school, before it was called that
<__chip__> we just called it 'batido'
<facubatista> MarkMaglana, each team member is from a different continent :p
<jam> facubatista, clearly the next hire should be NZ/Australia so we can maximize our worldwide coverage
<facubatista> Antarctica FTW
<MarkMaglana> facubatista i'm in one of those southeast asian archipelagoes.
<MarkMaglana> archipelagos? archipelagoes? anyway, group of islands.
<facubatista> :)
<jam> facubatista, but if Antarctica then couldn't they be in *any* TZ ?
<jam> facubatista, Chipaca coming along to meet with gnuoy ?
<facubatista> yes
<MarkMaglana> jam: When you get the chance, can you shed some light on this thing I'm getting blocked at? I was attempting to remove one of the Grafana charm's delegators as well as the FrameworkAdapter and came across an issue. See commit https://github.com/relaxdiego/charm-k8s-grafana/commit/b689a77cb2714075b2c88e5fe6442e26f1ca033e
<facubatista> jam, Chipaca, for later: did we consider that saving state in the controller may be expensive? e.g. if the controller is in another DC/cloud
<mup_> Issue operator#277 opened: Helper library of common operations <Created by stub42> <https://github.com/canonical/operator/issues/277>
<__chip__> jam, facubatista: i'm going to be 5 minutes
<facubatista> __chip__, ack, will heat water for the mate, then
<jam> Chipaca, __chip__ still need your eyeballs on https://github.com/canonical/operator/pull/272
<mup_> PR #272: ops/charm.py: Update the Docstrings to Google style <Created by jameinel> <https://github.com/canonical/operator/pull/272>
<mup_> Issue operator#278 opened: Unit.status not unit tested <Created by jameinel> <https://github.com/canonical/operator/issues/278>
<facubatista> jam, I'm failing to relate my blog to apache :/ ... I see that one of the items apache2 provides is:
<facubatista>   apache-website:
<facubatista>     interface: apache-website
<facubatista>     scope: container
<facubatista> then, my blog requires:
<facubatista>   apache:
<facubatista>     interface: apache-website
<facubatista>     scope: container
<facubatista> but then I get
<facubatista> $ juju add-relation bdv:apache apache2:apache-website
<facubatista> ERROR no relations found
<jam> facubatista, do you have "subordinate: true" in your metadata.yaml ?
<facubatista> maybe I needed to do something different when deploying?
<facubatista> oh
<jam> (I hadn't told you about it because I had forgotten it, but as I'm writing docs I came across it again)
<facubatista> jam, no problem that you didn't tell me, I'm a little frustrated about not finding this myself in the docs
<facubatista> ok, upgrade no longer works because I changed the application's subordinacy, let's remove and redeploy
<facubatista> ah, and then the `juju deploy` sits there in 'waiting' until I relate it to the other app
<facubatista> it could totally say that in the message
<__chip__> jam: 272 gtg
<jam> \o/
<mup__> PR operator#272 closed: ops/charm.py: Update the Docstrings to Google style <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/272>
<jam> facubatista, Chipaca does typing have a type like Optional but meaning "you *can* set this, but you really shouldn't"? :)
<facubatista> jam, I've been checking its docs, after you used it... it looks is an explicit way that you can use that, or the default... IOW:
<facubatista> if you do    def foobar(foo: Optional(int) = None):
<facubatista> foo is optional, yes, as it has a default
<facubatista> but the Optional would mean that you can actually pass an int, and you can even pass None!
<facubatista> without the optional, at typing level, you could pass an int or nothing
<facubatista> that is what I understood from reading a little the docs, never really tried it
<jam> facubatista, standup?
<mup_> PR operator#279 opened: ops/model.py: Document public methods and types <Created by jameinel> <https://github.com/canonical/operator/pull/279>
<jam> Chipaca, pip3 install --upgrade --user flake8 made it fail for me, but because there is a new pycodestyle which "has no attribute 'break_around_binary_operator'"
<jam> pip3 freeze our deps :)
<jam> ugh, it seems flake8 had a long standing pycodestyle <2.4.0 but tip of flake8 says 2.6.0 but doesn't actually work with it?
<jam> so test suite passes if I do: pip3 install --upgrade --user flake8==3.7.* autopep8 pycodestyle==2.5.* mccabe pyflakes==2.1.*
<jam> it fails to run with flake8==3.8.* which needs pycodestyle 2.6.0 but doesn't actually work with it AFAICT
<jam> (in neither case does it cause E402 errors, which is what we see on Travis)
<__chip__> newsflash: ops doesn't work with python 2
 * __chip__ glares at his new venv
<__chip__> jam: was the problem with the doc of RelationData that things like :class:Application weren't getting rendered correctly?
<__chip__> jam: what category in the discourse shold the readme point to?
<__chip__> /c/charming?
<__chip__> i'm also going to point at /c/docs/operator-framework
<jam> __chip__, the issue is that RelationData's docstring was completely absent
<jam> I was trying to figure out if :class:Application worked or if you need :class:`ApplicationData`
<__chip__> jam: i'm not seeing that, fwiw, with either version of sphinx here
<jam> but it didn't render anything or complain
<__chip__> jam: without the `s it doesn't render it as a link (so it outputs the string verbatim)
<__chip__> including the :class:
<__chip__> jam: but again, that's here where it is rendering :)
<__chip__> strange that there it isn't
<__chip__> i built a new env to see if i had anything left over that would be doing it, and no
<__chip__> and i tried with both sphines in a new env each time, also no
<jam> __chip__, https://imgur.com/U4WQcvp
<__chip__> no == it did render, i mean
<__chip__> jam: that looks like you're not picking up the :members:
<__chip__> jam: ie the defaults from docs/conf.py
<jam> __chip__, so it is because I was looking at context.html which was renamed to index.html, but index.html isn't getting the right theme (from what I can tell), so I thought it was the wrong dok
<jam> doc
<jam> __chip__, wiping out the dir and recreating it revealed the wrong html file
<__chip__> jam: the default theme will be different in the local build, it'll be a very spartan thing now rather than the green friendly one
<jam> right, that's what I'm seeing, but at least I'm seeing the fields I added :)
<__chip__> I could explicitly say 'use the tbd theme' but that's an extra requirement
<__chip__> rtd*
<__chip__> the rtd theme is bigger than sphinx :-D
<__chip__> jam: did you see my question about the discourse?
<__chip__> (while i have you here :)
<jam> __chip__, So your request for ``{name: stuff}`` means that links don't work. eg: {relation_name: [ :class:`Relation` ]}
<jam> for discourse...
<__chip__> jam: ah. ufa.
<jam> I think timclicks wants us to use https://discourse.juju.is/c/charming
<jam> __chip__, ufa ?
<__chip__> jam: "rats"
<__chip__> as an interjection i mean
<jam> __chip__, I'm happy for whatever rendering we like for it. I don't have to have links, but I do kind of like the cross reference
<__chip__> me too
<__chip__> indeed i like it a little more than i want code to look like code, in small snippets at least
<jam> It seems to help the "what is this thing, oh that's what it is, what can I do with it" in a nice way
 * __chip__ nods
<jam> I can say "map of foo => :class:`Bar`" if you don't want it to look so much like code
<jam> It is a pattern I use a lot because we have a lot of maps in our structs
<jam> classes even
<__chip__> maybe working into a sentence is better
<__chip__> as in "a map of foo to :class:`Bar`" or sth
<__chip__> dunno
<__chip__> jam: i can confirm that setting html_theme to 'sphinx_rtd_theme' renders things almost exactly like on rtd
<jam> __chip__, I'll try out the sentence structure.
<jam> I think the big thing was realizing that index was, indeed, the correct rendering, and not a mistake
<jam> I can live with it
<__chip__> ok
<__chip__> i can add it to docs/requirements and make it explicit, should help us when we start tweaking the theme
<__chip__> pushed that
<__chip__> facubatista: dev-requirements.txt, or requirements-dev.txt? i know we had this discussion before but don't remember the outcome
<facubatista> __chip__, I prefer requirements-dev.txt, as you locate it more easily when listing the directory
<jam> __chip__, do you know why https://github.com/canonical/operator/pull/276/files looks like it is r
<mup_> PR #276: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/276>
<jam> bringing in my charm.py changes?
<facubatista> __chip__, btw, are you working on that? I am
<__chip__> jam: i don't, i probably need to rebase or something
<__chip__> jam: i'll clean it up before my eod
<jam> __chip__, I also prefer requirements-dev because of sorting
<__chip__> facubatista: i am not, but i'm updating the README that assumes it's done :-D
<__chip__> jam: facubatista: fffantastic
<facubatista> __chip__, ack
<__chip__> jam: it seems happier now (all i did was rebase to master)
<mup_> PR operator#280 opened: Included the dependencies in requirements files, updated README and .travis <Created by facundobatista> <https://github.com/canonical/operator/pull/280>
<facubatista> __chip__, ^
<jam> __chip__, my guess is that the land-with-squashing is causing one of your patches to look like an additional change
<__chip__> facubatista: wouldn't it be enough to say ==5.3.*?
<facubatista> __chip__, I don't know, are you sure they use 100% semver?
<__chip__> facubatista: I am 3.75% sure about absolutely everything
<__chip__> but it adds up in weird ways
<facubatista> __chip__, +/- ?
<__chip__> 5
<facubatista> :)
<karimsye> did you guys read this - https://discourse.juju.is/t/experimental-new-feature-k8s-charms-as-operators/2849
<karimsye> does it support/conflict with anything you guys have planned?
<karimsye> I am guessing I can still use the operator framework to do things like read models,units,applications states and their config
<facubatista> karimsye, thanks, will read
<__chip__> karimsye: it neither supports nor conflicts with what we have planned so far, and we don't currently have concrete plans to really support that feature
<karimsye> facubatista: thanks
<__chip__> karimsye: but we do have a blanket 'make things better' for juju on k8s, which might include this (or other work) as juju changes
<__chip__> facubatista: i think i saw you say something about having a signature like foo(n: Optional[int] = None)
<__chip__> facubatista: if i understood you correctly, you were further saying that   foo(n: int = None)  was OK as well?
<facubatista> __chip__, today, 10:29.ar
<__chip__> facubatista: yeah, i'm asking if that second part was what you meant to say
<facubatista> IIUC, foo(n: int = None) means that if you pass a parameter, it must be an int (you may not pass it)
<__chip__> foo(n: int = None)  is wrong
<__chip__> because n = None can't be done if n is int
<facubatista> according to whom?
<__chip__> hmm
<__chip__> hold on maybe i misunderstood
<__chip__> i was sure i had run this past mypy and it had complained
<__chip__> gasp
<__chip__> mypy is now saying that Optional happens automatically
<__chip__> look:
<__chip__> given def foo(n: int = None) -> int:
<facubatista> __chip__, https://paste.ubuntu.com/p/pJHQGvttyy/ ?
<__chip__>     return 2*n
 * __chip__ looks
<__chip__> tal cual
<__chip__> but now change it to â int and return 2*n
<__chip__> it looks like this only works with None, you can't do shenanigans like foo(n: int = 'hello')
<__chip__> but for =None, it automatically makes it Optional
<__chip__> that's Neat
<__chip__> this is new, or when i tested i bungled the test :)
<facubatista> __chip__, the problem is the value in multiplication, not the signature
<__chip__> facubatista: yes but that's where you see that it's promoted the n to Optional
<__chip__> it says the operand is of type "Optional[int]"
<facubatista> __chip__, this is fine: https://paste.ubuntu.com/p/vtcgXWNhG7/
<__chip__> yep
<__chip__> so maybe we can do without those Optionals in our annotations
<__chip__> i'll give it a pass over later
<__chip__> right now i need to soft-eod and go for a short run and make dinner
<facubatista> __chip__, it looks Optional is now optional :p
<facubatista> __chip__, see https://paste.ubuntu.com/p/8bmYJSxY79/
<__chip__> facubatista: or is it that optional is Optional
<facubatista> as it's "optional at Python level", it just does the right thing (tm)
<__chip__> facubatista: but, again, only if None afaict
<facubatista> __chip__, see `bar` in my last pastebin
<__chip__> facubatista: and def foo(n: typing.Union[str, int] = None) -> int: return 2*n    and you see that it's promoting the Union to Optional, and then the stringify of that optional union has the same issue as it does in sphinx
<__chip__> facubatista: there's no promotion there
<__chip__> typing.Optional just means "it can also be None"
<__chip__> because typing.Optional[SomeType] is just typing.Union[SomeType, NoneType]
<facubatista> __chip__, I don't care about that special case, as everything else seems to work just fine without using Optional
<__chip__> k
<facubatista> __chip__, I mean
<__chip__> anyway, soft-eod for me
<facubatista> __chip__, it looks everything "is just fine" without using Optional at all
<__chip__> afaict yes
<__chip__> i'm going to try (later) and see what breaks if anything :)
<__chip__> oh rats, https://github.com/sphinx-doc/sphinx/pull/7298
<mup_> PR sphinx-doc/sphinx#7298: py domain: Add py:property directive to describe a property (refs: #7068) <domains:py> <enhancement> <refactoring> <Created by tk0miya> <https://github.com/sphinx-doc/sphinx/pull/7298>
<__chip__> we're going to get into trouble with descriptors
<__chip__> with both mypy and sphinx
<__chip__> afaict
<__chip__> booo
<__chip__> ANYWAY I WAS SUPPOSED TO BE GONE
 * facubatista bb~1h
 * facubatista didn't go :p
 * facubatista bb~1h for real now
 * facubatista is back
<__chip__> ok, i'm out
<__chip__> facubatista: amaÃ±Ã¡!
<facubatista> __chip__, chaus
<__chip__> facubatista: i lied!
<__chip__> muahahaha
<facubatista> jajaja
<__chip__> facubatista: could you review #281?
<mup_> PR #281: make flake8 happy again <Created by chipaca> <https://github.com/canonical/operator/pull/281>
<mup_> PR operator#281 opened: make flake8 happy again <Created by chipaca> <https://github.com/canonical/operator/pull/281>
<__chip__> facubatista: both you and jÐ°m have (i think?) written the same thing but mixed up with other stuff
<facubatista> __chip__, indeed; there +1'ed it
<__chip__> facubatista: thank you for buying the conflict :-)
 * __chip__ pokes travis
<facubatista> :)
<mup_> PR operator#281 closed: make flake8 happy again <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/281>
<__chip__> facubatista: anything i can review for you?
<facubatista> __chip__, I lost track, tomorrow need to do a pass on everything
<facubatista> I think I have feedback on everything, though
<__chip__> facubatista: ok
<__chip__> facubatista: you've also been here since forever
<__chip__> almost as long as me (but i went off and had dinner and watched some netflix)
<facubatista> __chip__, I took a nap :)
<__chip__> facubatista: ah, good :)
 * facubatista is not 25 since a long time ago
<__chip__> facubatista: i can resolve that conflict for you if you want
<__chip__> s/if you want/if you don't mind/
<facubatista> __chip__, no worries, I will work it out tomorrow
<__chip__> grrr, squash merge i hate you so much
<__chip__> "i've seen this change before, let me just search for the commit hash"
<__chip__> hahaha nope
<facubatista> __chip__, we can stop squashing
 * facubatista hates squashing, it's human solution to a technical problem
 * __chip__ likes butternut squash
 * __chip__ zzzs
#smooth-operator 2020-05-13
 * MarkMaglana likes butternut squash soup with coconut milk
<MarkMaglana> but first, coffee
<__chip__> MarkMaglana: calabacÃ­n relleno ftw
<__chip__> good morning all
 * __chip__ still in alter-ego mode for today
<MarkMaglana> __chip__: damn that relleno looks yummy! now i gotta find me one of those.
<__chip__> jam: dunno if you saw we landed a fix to master for the flake8 woes, just chaning the charm.py for now
<__chip__> changing*
<jam> __chip__, I didn't see that, thank you
<__chip__> we can look at pinning versions at some point but for now this was alright
<__chip__> jam: i was tempted to merge it into everything red but didnt' want to trip you up :)
<__chip__> (just 279 bah)
<__chip__> (i merged it into mine, and i expect facu merged it into his)
<jam> __chip__, do we have any idea why it fails on travis but not locally?
<jam> I struggled to get a working 'different' version of flake8
<jam> tip seems broken against the pycodestyle it requires
<__chip__> jam: it fails locally if you install flake8 and autopep8 from pip
<__chip__> jam: last night the rules seemed more subtle than what you'd reported so maybe the issue you saw was fied
<__chip__> jam: flake8 now asks for  pycodestyle<2.7.0,>=2.6.0a1
<__chip__> jam: and autopep8, pycodestyle>=2.5.0
<__chip__> so I get pycodestyle 2.6.0 and everything's happy (except our tests until we fixed master)
<jam> Chipaca, https://paste.ubuntu.com/p/zVsD7qkmG9/
<jam> flake 3.8.1, pycodestyle 2.6.0 pyflakes 2.2.0 and flake8 fails AFAICT
<__chip__> jam: maybe pip install -U ?
<__chip__> jam: I get flake8-3.8.1, pycodestyle 2.6.0, and pyflakes 2.2.0, and it's happy
<jam> The original install was pip3 install --upgrade --user flake8 pydocstyle autopep8
<__chip__> jam: maybe it's python 3.6 that's the issue?
<__chip__> i'm on 3.8 here
<__chip__> let me try with 3.6
<jam> the traceback implicates importlib-metadata, but that has "skipping upgrade importlib-metadata; python_version < "3.8"
<__chip__> er, can't do 3.6, doing 3.5
<__chip__> jam: that's happy too
<jam> __chip__, is there a clear 'uninstall everything and try again' ? Or I can just go back to whatever flake8 was working and stop fighting it :)
<__chip__> jam: https://gitlab.com/pycqa/flake8/-/issues/406
<__chip__> which points to â¦
<jam> __chip__, opened 2 years ago, and fixed by depending on a specific version of pycodestyle
<__chip__> yeah
<__chip__> jam: wrt 'uninstall everything and try again', i just blow away the venv
<jam> which now we're 2 versions beyond that
<__chip__> jam: let's compare 'pip list' output
<__chip__> jam: https://paste.ubuntu.com/p/nRgxRx4NSn/
<jam> https://paste.ubuntu.com/p/FDyjwXB8x3/
<jam> (that is the one that works, let me upgrade and try again)
<jam> this flake8 fails to load: https://paste.ubuntu.com/p/QxcZMwwfrT/
<__chip__> jam: what happens if you grep for break_around_binary_operator in the lib?
<__chip__> I only see a _break_around_binary_operator method in pycodestyle
<__chip__> nothing calling into it
<mup_> Issue operator#282 opened: Harness: Unable to assert if framework was called correctly by charm <Created by relaxdiego> <https://github.com/canonical/operator/issues/282>
<jam> lib/python3.6/site-packages/pycodestyle.py:1279:def _break_around_binary_operators(tokens):
<jam> it is an '_break'
<__chip__> jam: right, but what tries to call break_around_binary_operator ?
<jam> __chip__, so it is something about magically loading plugins, but my system doesn't seem to have that string, digging
<__chip__> that exception should really print what file it's trying to load, huh
<__chip__> MarkMaglana: thanks for the bug report!
<jam>  /usr/lib/python3/dist-packages/pycodestyle.py
<jam> who installed that...
<MarkMaglana> __chip__: no worries! :)
<__chip__> jam: gremlins
<jam> __chip__, 'apt install flake8' depends on pycodestyle
<jam> apparently the plugin loading finds the dist package but imports from the non-dist ?
<jam> so to have a 'pip3 install --user flake8' I can't have an 'apt install flake8'
<jam> __chip__, so with apt remove flake8 and a bunch of dependencies, ./run_tests fails for the "right" reason
<__chip__> jam: huzzah, maybe
<jam> ok, so I at least can reproduce and merged the fix and pushed it
<__chip__> MarkMaglana: question for you
<__chip__> MarkMaglana: what does 'build_juju_unit_status' do?
<__chip__> MarkMaglana: ah, found it
<MarkMaglana> __chip__: it just returns a *Status object based on arguments: https://github.com/relaxdiego/charm-k8s-grafana/blob/b689a77cb2714075b2c88e5fe6442e26f1ca033e/src/domain.py#L72-82
<MarkMaglana> :)
<__chip__> MarkMaglana: what is pod_status?
 * __chip__ digs more
<__chip__> ah, something from k8s?
<MarkMaglana> __chip__: you got it
<jam> __chip__, so if I understand correctly, what Mark wants is to see that his code is setting the unit status to A, and then to B, and then finally to C as part of responding to the config_changed event.
<jam> __chip__, however, we don't assert at each step, so you can only see the final "after all is done the status is correct"
<__chip__> MarkMaglana: why wouldn't k8s.get_pod_status return a framework status directly?
<jam> __chip__, the config-changed handler is looping on the result of a mocked get_pod_status and should notice the transition of the pod to being active
<MarkMaglana> __chip__: that one is to actually check if the k8s pod's livenessProbe and readinessProbe both return true.
<jam> MarkMaglana, does the above sound correct for what you are trying to do?
<jam> There are 2 possibilities as I see it. 1) I do have code for a _get_backend_calls() that would give details of how you interact step by step, I don't knw that I recommend that route, but the PR is https://github.com/canonical/operator/pull/264
<mup_> PR #264: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <https://github.com/canonical/operator/pull/264>
<jam> b) You could change your mock so that you check the unit status just before you return a new pod status
<MarkMaglana> i think i found that calling the framework status directly doesn't give me the fine-grained result that i needed. at the time I wrote that, the framework reported the pod as ready but in the k8s layer it was just live but not yet ready to receive requests. I wanted to make sure I reported that correctly to `juju status` so that the user doesn't panic or wonder what's going on.
<jam> so you can see "the unit status started as X, then I returned pod status Y, then the unit status updated to Y, then I returned Z, and the unit status updated to Z"
<__chip__> "the framework reported the pod as ready but in the k8s layer it was just live but not yet ready to receive requests" â isn't that a bug in the framework?
<jam> __chip__, it is a practical reality that saying "start this" takes a while for it to actually start
<jam> __chip__, there is the k8s layer that says the container has started
<jam> __chip__, and there is the "can I actually connect to the socket of the app"
<__chip__> ahhh
 * __chip__ ahhhs
<MarkMaglana> that's what i report with PodStatus: https://github.com/relaxdiego/charm-k8s-grafana/blob/b689a77cb2714075b2c88e5fe6442e26f1ca033e/src/adapters/k8s.py#L75-L99
<MarkMaglana> is_running looks at the livenessProbe and is_ready looks at the readinessProbe
<MarkMaglana> jam: sorry i didn't notice that you were chatting me up with a different topic :)
<jam> MarkMaglana, all of that should be prefaced with, I believe in Juju 2.8 pod-spec-set was made "transactional" which means Juju won't ask k8s to start the pod until your hook exits. So setting the pod spec and spinning isn't going to get you anywhere because Juju hasn't actually started the pod yet.
<MarkMaglana> jam: that "transactional" tip is good information. in that case what would be the best way to report back to the user about the actual status of the underlying workload?
<jam> MarkMaglana, I'm raising the question internally if it should be transactional. one option is to hook into the 'update-status' hook that Juju fires periodically (approx every 5 min). It isn't a great update rate
<jam> MarkMaglana, the other option is to use something like cron / a forked subprocess
<jam> and use "juju-run" to get back into the hook context and report back
<jam> I don't think we have much to make that easy in the framework, unfortunately
<MarkMaglana> jam: yeah 5 mins is not ideal. :)
<jam> There have also been conversations that Juju should be triggering events on pod state changes
<jam> But all that is hypothetical
<MarkMaglana> gotcha. hmmmm.
<MarkMaglana> jam: interesting challenge to tackle but for now, what do you suggest i do with the assertion? should i forego checking if the status was set 3x in my unit test and just check if the final status is correct?
<MarkMaglana> brb my washer/dryer is singing lol
<jam> so there is (1) which is use my patch that adds direct checking of every backend call, (2) check in the individual steps, (3) break apart the two so the one side emits events, and then you can have a second handler that monitors what events are sent. (4) just assert the final state
<MarkMaglana> jam: thanks! i'll check out all options. :)
<__chip__> yuss, got a dispatch shim main working
<__chip__> main.py is now a mess
<__chip__> refactoring :)
<MarkMaglana> in case this helps anyone else, this has been a godsend for me when reviewing code on github: https://chrome.google.com/webstore/detail/sourcegraph/dgjhfomjieaadpoljlnidmbgkdffpack
<mup_> PR operator#283 opened: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
<__chip__> jam: ^ wdyt?
<jam> __chip__, about SourceGraph or about dispatch? :)
<__chip__> jam: the latter
<__chip__> haven't looked at the former yet
 * __chip__ looks
<__chip__> MarkMaglana: doesn't github already do that?
<MarkMaglana> __chip__: well sh**. you're right! lol.
<__chip__> MarkMaglana: doesn't quite work in firefox yet :( but they'll get it there
<MarkMaglana> __chip__: I'm more of a Brave browser hipster guy.
<facubatista> Muy buenos dÃ­as a todos!
<__chip__> MarkMaglana: ah! it does work, i was just impatient
<__chip__> facubatista: heyy
<facubatista> hola __chip__
<__chip__> facubatista: could you start your day with a nice fresh cup of #276?
<mup_> PR #276: explicitly ask for a newer sphinx on rtd <Created by chipaca> <https://github.com/canonical/operator/pull/276>
<facubatista> __chip__, gladly
 * facubatista pours himself a cup of that
 * __chip__ passes facubatista a smaller cup
 * facubatista clumsyly spoils all the bytes all over desk and keyboard
 * __chip__ hands facubatista the kitchen towels
 * __chip__ watches facubatista dress up as a mummy
 * __chip__ /o\
<facubatista> jajaja
<jam> __chip__, did you even send an email/meeting for Ajduk to reschedule?
<__chip__> i did not even
<__chip__> i did send one to jay
<mup_> PR operator#276 closed: explicitly ask for a newer sphinx on rtd <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/276>
<__chip__> jam: to schedule meetings with people in utc-6, should i make you optional, or is there any time that might work for you?
<jam> __chip__, depends how much you want me to be there. :) I can make exceptions and work an evening here and there,and I'm willing to do a regular "monday nights I work evenings" but I wouldn't want it to be at arbitrary times
<__chip__> jam: you kick ass at these meetings, not having you there makes them so much worse :) maybe one day a week you work evenings and we schedule these meetings for then? (i think it's just 2 (so far!) that are that far west)
<jam> __chip__, one day a week is manageable
<__chip__> jam: as it's just two, bi-weekly, tell me what day and at what hour :)
<facubatista> jam, so, I deployed my blog as subordinate, which implied adding the relation to apache; at that moment "relation_joined" triggered on my charm, and I did some prints at that time...
<jam> __chip__, so your thought is 2 every other week, or one every week?
<facubatista> jam, as a next step, I wrote the proper code for that hook (configuring apache, if I'm right)... and then upgraded my charm... but "relation_joined" didn't trigger again... only "configuration changed"
<facubatista> jam, what is the appropiate thing to do here? shall I hook that method to some other specific event and make it trigger? use config_changed for that? I'm failing to do a step properly?
<jam> facubatista, so relation-joined only happens 1 time, when the new unit is seen. relation-changed would happen multiple times if Apache is giving you feedback.
<jam> facubatista, I would think that telling Apache "here use this directory" only really needs to be told to it one time.
<jam> Now, if some of your config causes a change in what content you are telling Apache about
<jam> then in *config-changed* you would call self.model.get_relation('apache').data[self.unit] =new stuff
<facubatista> jam, I don't really have a config that is related to Apache, in that sense
<facubatista> jam, so, this is useful except when "bulding" my code :(
<facubatista> yes, when all is done it should work ok
<facubatista> jam, can I trigger that "relation_joined" manually somehow?
<facubatista> or I could use an "action"
<jam> __chip__, so 8am UTC-6 is 6pm UAE time. If that works, then doing those on Mondays at 6pm (just after our standup) would be a good time.
<jam> If we need to go later because people don't start at 8am, then I'd still probably want to do them on Monday.
<jam> facubatista, if you just want to test your code, I think you can do "juju run --unit some/1 'hooks/relation-joined'"
<jam> the other option is to remove the relation and add it again, but that will kill the unit and create it again
<facubatista> jam, if I do "juju run --unit some/1 'hooks/relation-joined'", the event I got still have a .relation pointed to apache?
<facubatista> *will still have
<jam> __chip__, so that would be Monday, UTC 14:00. But I could go until UTC 18:00 if necessary
<jam> facubatista, I don't think Juju sets the JUJU_RELATION_ID, etc if you manually trigger a hook
<jam> facubatista, 'get_relation' should still work, because the relation is still defined, but event.relation probably won't be set
<facubatista> another reason to stop using `event.relation.data` and go to `self.model.get_relation('apache').data`, which looks less "backwards thinking" than the former
<facubatista> jam, mmm... in `self.model.get_relation('apache').data` I'm expressing "the data from an application", not "the data from an unit"
<jam> facubatista, you're looking at all the relation data there
<jam> so you still need
<jam> self.model.get_relation('apache').data[unit/or/app]
<__chip__> jam: ack. I'll look at the calendar later and let you know what it looks like.
<jam> __chip__, #283 reviewed. I think we're still missing a case
<__chip__> I've jused realised the time, the bug revue, and the lack of lunch
<mup_> PR #283: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
 * __chip__ takes the laptop to the kitchen
<facubatista> jam, meeting?
<facubatista> jam, __chip__, standup?
<__chip__> https://github.com/sphinx-doc/sphinx/pull/7655  :-D
<mup_> PR sphinx-doc/sphinx#7655: Make sphinx.util.typing.stringify render optional unions better <autodoc> <enhancement> <Created by chipaca> <Merged by tk0miya> <https://github.com/sphinx-doc/sphinx/pull/7655>
<__chip__> facubatista: #280 GTG
<mup_> PR #280: Included the dependencies in requirements files, updated README and .travis <Created by facundobatista> <https://github.com/canonical/operator/pull/280>
<facubatista> __chip__, thanks
<mup_> PR operator#280 closed: Included the dependencies in requirements files, updated README and .travis <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/280>
<facubatista> jam, boo https://paste.ubuntu.com/p/jSgxJZjzbT/
 * facubatista will write an action for this
<mup_> Issue operator#282 closed: Harness: Unable to assert if framework was called correctly by charm <Created by relaxdiego> <Closed by relaxdiego> <https://github.com/canonical/operator/issues/282>
<DominikF> Hey all! I tested the `charm create -t operator-python` command today and wanted to provide some feedback. I didn't find the changes here https://github.com/juju/charm-tools , has the repository changed?
<__chip__> DominikF: which changes?
<DominikF> __chip__: The changes that enabled this new template
<__chip__> DominikF: charm-tools is that repository, but we're not charm-tools (i don't really know what that command does... so maybe it's unmaintained?)
<DominikF> __chip__: sorry maybe I misunderstood. Last week we had a conversation about having skeleton charms for the operator framework and I was told that this was added to the charm-tools. The command that I listed above does exactly that and works great, I thought it was the work that your team was talking about.
<__chip__> DominikF: i'm glad it works :-D but if it was done by my team, it was done before i was on it
<__chip__> DominikF: maybe cory_fu_?
<DominikF> __chip__: sorry! I thought it was recent work and found it strange that there was no new commit for it.
<__chip__> DominikF: sadly, no
<__chip__> at _some_ point charmcraft will grow that ability, but not just yet (it didn't make the roadmap)
<mthaddon> __chip__, DominikF: charm tools is maintained by cory_fu https://github.com/juju/charm-tools/tree/master/charmtools/templates and the operator-python template pulls from https://github.com/devec0/template-python-operator currently
<__chip__> mthaddon: ack
<mthaddon> __chip__: maybe that should at some point be owned by the charmcraft team (the python-operator template)?
<__chip__> mthaddon: at some point there'll be a 'charmcraft init'
 * __chip__ will also add a 'charmcraft innit' which will be like 'bruv'
<mthaddon> hahaha, ah cool - would that have different options for "give me an IaaS charm" and "give me a k8s charm"?
<DominikF> mthaddon: that's exactly what I wanted to ask
<__chip__> mthaddon: it got kicked to the next cycle so i don't have details :) or i could say "probably"
<DominikF> If there could be a template for k8s charms
<__chip__> i mean
<__chip__> ideally there'd be no difference :)
<__chip__> we're almost there with dispatch
<mthaddon> DominikF: there's some discussion about this on https://discourse.juju.is/t/first-steps-with-the-operator-framework/3006/4 fwiw
<DominikF> mthaddon: thanks!
 * __chip__ breaths a sigh of releif
<__chip__> relief also
<cory_fu> mthaddon, __chip__: Sorry for the long delay in replying; had some particularly long meetings today.  Getting caught up on the discussion
<cory_fu> DominikF: ^
<cory_fu> I'm the defacto maintainer of charm-tools but it's basically just been in maintenance mode rather than active development since we expect it to be phased out by charmcraft.  The template PR was contributed and comes from that external repo, as noted, so changes to the template should be proposed there.
<cory_fu> My understanding, though, is that the intention with the new framework is to try to keep boilerplate small enough that ideally a template wouldn't be needed.  Ideally, creating a K8s charm vs a machine charm shouldn't be significantly different but might involve importing some different helpers to use with your charm class.
<cory_fu> I think the template is a stop-gap and there is the issue that it is likely to get out of date as the design patterns evolve.
<__chip__> cory_fu: thanks!
<cory_fu> I'm also looking forward to charmcraft being a much more focused tool.  A lot of things, like the template system, have grown organically into charm-tools over the years that I think really make things more confusing for the end user.
<mup_> Issue operator#269 closed: Warn that model.unit.is_leader() can raise an exception <Created by timClicks> <Closed by timClicks> <https://github.com/canonical/operator/issues/269>
 * facubatista is out
<Chipaca> ð
#smooth-operator 2020-05-14
<jam> morning all
<DominikF> Morning everyone! So I'm working on a Kubernetes Charm with the new framework, and the docker image I'm using doesn't have python3 installed.  How should I proceed if I want actions? What is the best practice of using actions with bash? Preferably i would install python on the pod each time I instantiate one, but don't know if thats possible.
<Chipaca> mo'in!
<jam> Hi DominikF. You can do actions in bash, though the python framework obviously can't help you.
<jam> You could have a bash script that then installs python, but I'm not sure that fits with how people expect K8s pods to work
<jam> You could use the docker image as a base and build another image on top of it that *does* include python
<DominikF> jam: yes, I was thinking about something like that, what is your guys plan for this in the future?
<DominikF> jam: If I would do it in bash I would I just add an actions folder like in the previous charms?
<jam> DominikF, correct. even when using the framework, if you have an actions directory with scripts in there, the framework will call them.
<jam> DominikF, "plan for this". How to get python where you need it?
<DominikF> jam: yep
<jam> morning Chipaca
<jam> DominikF, so my recommendation would be to build a container based on the one you want that also includes python, as it seems the most k8s/docker consistent
<DominikF> jam: thanks, that clears up my doubts! Just wanted to make sure I'm doing it the right way as we are going to show this Charm in the next OSM Hackfest.
<Chipaca> MarkMaglana: I'll reach out to you to get that k8s.py usable via the library/plugin mechanism, early next week
<MarkMaglana> Chipaca: rock on!
<Chipaca> MarkMaglana: great that you said it was yours, because that was my next task :) figuring out its origin
<Chipaca> jam: wrt breaking changes, i'd like to at least talk about moving away from action-as-a-property
<Chipaca> but that's a big one, we change that we break everybody :)
 * Chipaca breaks the world
<Chipaca> good movie, that
<Chipaca> er
<Chipaca> jam: i said action i meant status
<jam> Chipaca, ah, I was a bit confused and started looking at where action was a property. :)
<jam> Chipaca, the medium term discussion was that we could do both (have it as a property and as something you can set via method)
<Chipaca> jam: and exceptions?
<jam> Chipaca, so in my head having exceptions have a status that will be set if they bubble up doesn't have to change *how* we set the status otherwies
<Chipaca> jam: I meant: (drop charm.status and instead) have charm.set_maintenance(...) and charm.set_active(...) but raise Waiting() and raise Blocked()
<Chipaca> (set_active is a bad name, but you get the idea)
<Chipaca> this accomplishes, transparently, the "let me set these while running but only set these at the end", imho
<Chipaca> and those same semantics via charm.status = â¦  are super weird (again imho)
<jam> Chipaca, I think you should raise an exception to set Active status... clearly. :)
<jam> Chipaca, I like where you're thinking is going, I don't know that we "have to break everyone" to have that behavior, but we could certainly deprecate it, or just break it with a .X release.
<Chipaca> jam: in any case we need to fix #278 :)
<mup_> Issue #278: Unit.status not unit tested <bug> <Created by jameinel> <https://github.com/canonical/operator/issues/278>
 * Chipaca gets on it
<Chipaca> jam: dunno if you saw I moved #190 out of draft
<mup_> PR #190: README: a significant rework <Created by chipaca> <https://github.com/canonical/operator/pull/190>
<jam> Chipaca, commented on 190
<Chipaca> jam: right back atcha
<Chipaca> jam: should there be an 'invalidate' for _status?
<Chipaca> or rather, should Application and Unit have _invalidate i guess
<jam> Chipaca, you're trying to invalidate what the status is?
<Chipaca> jam: yup
<Chipaca> it's cached very aggressively which means the call to status-get is hard to test for reliably :)
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð
<facubatista> hola Chipaca
<jam> morning facubatista
<facubatista> hola jam
<jam> Chipaca, so status-get has always been a bit weird, because you're the one responsible for telling *us* what the status is
<facubatista> jam, let me know when you have a minute to continue (here) my eternal blog-apache talk, thanks
<jam> facubatista, just making coffee and then we can chat
<facubatista> great, thanks
<jam> Chipaca, i'm fine with an invalidate, I would just caution that I don't really want to ever change status 'behind the back' of the charm.
<Chipaca> jam: i fear there's a bug
<Chipaca> shocking i know
<Chipaca> getting details now
<jam> Chipaca, no bugs, only opportunities for enlightenment
<Chipaca> jam: the harnes's status_get returns the (status, message), or None
<Chipaca> jam: and that's then used for StatusBase.from_name(s['status'], s['message'])
<Chipaca> jam: neither tuples, nor None, are dicts :-)
<jam> Chipaca, indeed, status_set / status_get were certainly something I didn't test via Model
<Chipaca> status_set is tested, in     def test_local_set_valid_app_status(self):
<jam> Chipaca, I think it was something I threw together as a prototype, and then added tests, but of course, my tests conformed to my implementation, but not to the *contract* of status_get :)
<Chipaca> status_get isn't because _status gloms the value
<Chipaca> :)
<Chipaca> jam: i'll fix
<jam> Chipaca, thanks for the catch
<facubatista> jam, so, what I did after my talk is to also register my `on_apache_relation_joined` method to the upgrade-charm hook, so I could work on it until I have it in good shape
<facubatista> of course, I don't have the relation from the event, so I just grabbed it from elsewhere
<jam> facubatista, sorry, I am back if you want to chat
<facubatista> so, I first tried this:  relation_data = self.model.get_relation('apache').data['apache2']
<facubatista> but I got a  *** KeyError: 'apache2'
<facubatista> so I explored a little, and end up doing this:
<facubatista>         relation_data = [v for k, v in self.model.get_relation('apache').data.items() if k.name == 'apache2'][0]
 * facubatista waits for jam's horror scream
<jam> facubatista, it is an Application, not a string
<jam> facubatista, relation = self.model.get_relation('apache'); relation_data = relation[relation.app] would work
<jam> It isn't how I'd like to see in production code, but for testing things it seems ok
<facubatista> jam, it will give me the same thing I grabbed juggling with the code above, right?
<jam> facubatista, indeed, but means you can relate to something that isn't exactly named 'apache2' and have it continue to work
<facubatista> jam, why you wouldn't want it in prod?
<jam> facubatista, for x in y: if x.name == "apache2"
<jam> means you can only relate your charm to exactly an application named "apache2"A
<jam> if I do "juju deploy apache2 custom-apache" it will break
<jam> juju relate custom-apache facus-blog
<jam> will look for an object named "apache2"A but only find an object named "custom-apache"
<facubatista> jam, ah, I thought that you wouldn't want *your* code snippet in prod
<facubatista> of course, I wouldn't want that horrible listcomp from mine in prod either
<facubatista> so, let's move to your code
<jam> (fwiw, it would be easier to hook into relation-changed, and then use 'juju run --unit apache2/0 relation-set blah=1' to trigger relation-changed again)
<facubatista> jam, relation_data = relation[relation.app] --> TypeError: 'Relation' object is not subscriptable
<jam> facubatista, relation_data = relation.data[relation.app]
<jam> sorry, I left out an attr
<facubatista> jam, great, so I reached the same point that yesterday, which originated my question
<jam> facubatista, so you're able to trigger the code as you want?
<facubatista> jam, yes! and I set data in the relation, data, but then I get a:   ops.model.RelationDataError: cannot set relation data for apache2
<facubatista> jam, this is the method code and log relevant part, fwiw: https://paste.ubuntu.com/p/C82HRtdDtY/
<jam> facubatista, relation.data[relation.app] is the data being sent by apache2
<jam> to set data you need to
<jam> relation.data[self.app]
<jam> eg, set the data in *your* bucket, so that the other units can read the data you are sending.
<facubatista> so frustrated with this
<facubatista> I still feel it backwards
<jam> facubatista, you are telling apache about yourself, not telling it how it should be configured.
<jam> what happens when there are 3 different relations to apache, each one can't set apache directly
<facubatista> but, but... I DO want to tell it how it should be configured!!
<jam> they tell apache about themselves and apache responds
<facubatista> how it should be configured *regarding me*, of course
<facubatista> why would I want to tell apache how it would be configured regarding somebody else?
<facubatista> jam, how many "buckets" may we have in relation.data ?
<jam> facubatista, each unit and each app has their own bucket
<facubatista> jam, each unit/app in the whole system, or in the relation?
<jam> in the relation
<facubatista> so, always four? two on the other end of the relation, and two here?
<jam> facubatista, well, more if you have more than 1 unit on either ide
<jam> side
<facubatista> and in "this side" always two, right?
<jam> a given unit will have its data bucket which it can read/write. and it can read other units data, and the remote app data
<jam> if it is the leader, it then also gets to read/write its app data bucket
<jam> Chipaca, I've tested #283 with Juju 2.7 and 2.8 and a couple permutations of symlinks vs shell scripts
<mup_> PR #283: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
<jam> I think we should probably land it, but it doesn't handle Juju 2.7 and hooks/install is a script
<jam> (it thinks it is being invoked as dispatch but no JUJU_DISPATCH_PATH is set)
<jam> I'm not sure if we *can* support that case
<facubatista> jam, is this accurate? https://docs.google.com/document/d/1EXXsHXOb3ECAev-M2M2IIljnWgXEenrX2g86b57Wwwo/edit (feel free to edit to improve wording) -- thanks!!
<jam> facubatista, "how the other end presents to you", "what the other end is presenting to you" might be clearer,
<jam> but yes, looks correct to me
<facubatista> clearer how? I think being as precise as possible there improves the value, I was vague, but because I lack deep understanding of that point exactly
<jam> It feels like it is clearer English.
<facubatista> "Virtual host templates can also be specified via relation. See the vhost-config relation section below for more information." <-- aja! I'm setting the data in the wrong relation
<facubatista> " A candidate charm should provide a relation on the apache-vhost-config interface." ... /me adds a "provides" in blog's metadata yaml
<jam> facubatista, apache-website docs say "site_config- A vhost configuration block"
<facubatista> jam, yeap
<facubatista> jam, I'm setting this: https://paste.ubuntu.com/p/QhhFd3w4KH/
<facubatista> (but IIUC in the wrong relation)
<jam> looking at https://api.jujucharms.com/charmstore/v5/apache2-35/archive/hooks/hooks.py it looks to write out a file into sites_dir/name.conf containing the vhost config
<facubatista> jam, you're cheating looking at the apache's charm source code, if we want wide adoption the docs should be clear enough :p
<jam> facubatista, I'm not trying to fix legacy/reactive charms just yet.
<jam> I don't disagree, but that is future world
<facubatista> jam, note that there are two ways of setting the config
<facubatista> jam, one through a config change, other through the vhost relation, which allows to be set *from the subordinate charm*
<jam> facubatista, can you look at #264 again? I think I cleaned up the merge.
<mup_> PR #264: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <https://github.com/canonical/operator/pull/264>
<facubatista> jam, will do, yes
<jam> thx
<facubatista> Chipaca, I was wrong, Enum defaults to a nice way of seeing the value:
<facubatista> >>> Relations = enum.Enum('Relations', 'PEER PROVIDES REQUIRES')
<facubatista> >>> str(Relations.PEER)
<facubatista> 'Relations.PEER'
<mup_> PR operator#284 opened: ops/model: cover app.status and unit.status better <Created by chipaca> <https://github.com/canonical/operator/pull/284>
<jam> facubatista, internally they are still ints, though. right?
<facubatista> (if you do repr() you will see the underlying int... but you can also define the internal values as the same string, which I'm not sure it's needed)
<facubatista> jam, they're by default, yes
<jam> Chipaca is trying to make it look like he was working today instead of just galavanting around in his backyard
<facubatista> jam, galavanting?
 * Chipaca gallivants with flair
<jam> "go around from one place to another in the pursuit of pleasure or entertainment."
<facubatista> "less common spelling of gallivant"
<jam> just misspelled :)
<facubatista> jam, +1 to 264, please see the comment, thanks!
<Chipaca> jam: i'm going to emulate the "2.7 with dispatch and hooks/install not a symlink" by also supporting "no dispatch and hooks/install not a symlink" directly (which i think master supports)
<jam> Chipaca, so hooks/install as a script works if you set JUJU_DISPATCH_PATH, but 2.7 won't be setting that
<jam> which is the thing we need to fix
<Chipaca> yep yep
<jam> "no dispatch and hooks/install is a script and no JUJU_DISPATCH_PATH" sounds great
<jam> So it seems that since ops is part of 'github.com/canonical' we end up getting serialized in travis with all other Canonical projc.ts
<MarkMaglana> good meeting! glad i could help!
<facubatista> MarkMaglana, :)
<Chipaca> jam: i didn't realise you were still around, i pushed the signature fix to 264 for you
<jam> Chipaca, I stopped by to check on the progress, and was pleased to see that you fixed my bug for me
<Chipaca> jam: now travis is being travis
<jam> Chipaca, not really around :) Just trying to follow up on my PR before the weekend
<jam> it just started mine again
<jam> Chipaca, from what I can tell, Travis will only let 2 jobs from 'canonical' run, and multipass has a 2hr job
<Chipaca> jam: the limit is 5 simultaneous workers, for free tier users
<jam> Chipaca, clearly that isn't the number they are actually running
<Chipaca> jam: 264 now green fwiw
<jam> Chipaca, yeah, I'm writing the commit now
<Chipaca> jam: per organisation? i see 3 in use for cloud-init right now for example
<jam> Chipaca, ah, I only see 1 "job" but it is a top level job. I guess it is indivi
<jam> sub jobs that are limited to 5
<Chipaca> yeah, by workers i meant the vms
<Chipaca> you can limit it to less than 5 to be fairer within the org
<Chipaca> or you can pay them :)
<jam> landed #264
<mup_> PR #264: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/264>
<Chipaca> woop woop
<mup_> PR operator#264 closed: test/test_model.py: Test Model using Harness._get_backend calls <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/264>
<facubatista> jam, pushed another version of charmcraft#1 and answered all conversation
<facubatista> s
<mup_> PR charmcraft#1: Charmcraft tool base skeleton <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/1>
<Chipaca> facubatista: thanks for the review on 190, i've commented out the TBD links
<facubatista> Chipaca, in #283 I'm really confused about "legacy"... you wrote a "run_any_legacy_hook" method that starts working with "dispatch" (which is not a legacy hook, right?), and if dispatch is not there, it's looged like "Legacy <this> is not there"
<mup_> PR #283: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
<facubatista> Chipaca, mind to explain that a little to me? thanks!
<Chipaca> facubatista: say you have a charm running under 2.8
<Chipaca> facubatista: and your charm has a dispatch file
<Chipaca> facubatista: and your charm also has hooks/install
<Chipaca> facubatista: juju will see the dispatch file and call it, ignoring all hooks/* guff
<facubatista> yes
<Chipaca> facubatista: it is dispatch's responsibility to call the legacy hooks/install file
<facubatista> yes
<Chipaca> facubatista: the end
<facubatista> not the OF
<Chipaca> facubatista: not the OF?
<Chipaca> ah, the operator framework
<Chipaca> facubatista: what do you mean, not the OF?
<facubatista> mmm... I was expecting that if the developer put a dispatch file, and still wanted her hooks/* scripts to be called, that she would handle that in the dispatch file
<facubatista> but yes, we could handle that
<facubatista> and put a dispatch that is a symlink to the source, and we'll make the hooks/* to be called
<Chipaca> facubatista: that is already supported
<facubatista> if she doesn't want the hooks/* to be called after setting the dispatch file, she can remove them
<Chipaca> facubatista: this is about dispatch being a shim that still calls us, we still need to do this -- or the shim does, but we want the shim to be minimal
<Chipaca> facubatista: for a custom dispatch all they need to do is unset the appropriate variable
<Chipaca> facubatista: and everything would carry on as before :)
<facubatista> unset which variable?
<Chipaca> MAKE_FACUNDOBATISTA_GREAT_AGAIN
<Chipaca> facubatista: or maybe JUJU_DISPATCH_PATH
<Chipaca> facubatista: if JUJU_DISPATCH_PATH is unset by dispatch, and they then execute e.g. hooks/install (that's a symlink to src/charm.py), it'll Just Work (tm)
<facubatista> yes
<Chipaca> facubatista: anything else i can answer? otherwise i'm going to eod
<facubatista> Chipaca, I need to see this with fresher eyes, no worries
<Chipaca> i can mail you one of my son's eyes
<Chipaca> i'm sure they won't mind
<Chipaca> they've got, like, four of them
<facubatista> each?? :p
<Chipaca> facubatista: yours dont?!?
<facubatista> Chipaca, nop, only two eyes per kid... shall I ask for a rebate?
<Chipaca> facubatista: are you sure they're not halflings?
 * facubatista checks in the kids documentation
 * facubatista is out
<Chipaca> facubatista: take care
<Chipaca> i too should wrap
<facubatista> Chipaca, hasta maÃ±ana
<Chipaca> facubatista: disfrute
#smooth-operator 2020-05-15
<MarkMaglana> <mrs. doubtfire impression>Well hellooooo</mrs. doubtfire impression>
<MarkMaglana> @jam would you mind if I started a discourse thread discussing the different options you mentioned here (https://github.com/canonical/operator/issues/282#issuecomment-627930376). I'm not satisfied with the option I picked but would also like to discuss the other options further before trying them out.
<jam> MarkMaglana, I'm officially off today, so I probably won't be active in the discussion just yet, but you don't need my approval to start a discussion thread. It sounds like a great idea.
<MarkMaglana> excellent. enjoy your long weekend!
<Chipaca> good morning all!
<Chipaca> also, TGIF
 * Chipaca tired
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð
<facubatista> hola Chipaca
<Chipaca> facubatista: if I may make a pairing suggestion, a small cup of #283 would go really well with that mate
<mup_> PR #283: ops/main: handle dispatch being a shim  <Created by chipaca> <https://github.com/canonical/operator/pull/283>
<facubatista> Chipaca, yes, I have fresh eyes now
<Chipaca> facubatista: would you believe me i forgot we were talking about this last
 * Chipaca didn't sleep well
<facubatista> Chipaca, you need a fresh brain (?)
<Chipaca> i'll ask the boys
<Chipaca> etc
<facubatista> Chipaca, I think I'm starting to understand; in _JujuEvent.__init__ you will be calling `self._init_dispatch` when having a modern Juju (even if Juju executed the charm via hooks/install), else you will be calling `self._init_legacy` (that in contrast would mean "legacy juju")
<facubatista> Chipaca, so you may set self.is_dispatch in True, even if it's not the "dispatch" script that was executed, but hooks/install
<facubatista> Chipaca, right?
<Chipaca> facubatista: the thing juju executed will have been the dispatch script
<facubatista> Chipaca, in which case?
<Chipaca> facubatista: when is_dispatch is true
<facubatista> Chipaca, I think you're wrong, let's HO?
<Chipaca> facubatista: in 5?
<facubatista> Chipaca, deal
<facubatista> Chipaca, https://meet.google.com/veq-yfqm-kdk, anytime you want
<facubatista> new juju, not having a dispatch script:
<facubatista> unit-bdv-2: 07:30:00 DEBUG unit.bdv/2.config-changed ============ sysargv0 path '/var/lib/juju/agents/unit-bdv-2/charm/hooks/config-changed'
<facubatista> unit-bdv-2: 07:30:00 DEBUG unit.bdv/2.config-changed ============ dispatch path 'hooks/config-changed'
<facubatista> new juju, having a dispatch script:
<facubatista> unit-bdv-2: 07:51:44 DEBUG unit.bdv/2.upgrade-charm ============ sysargv0 path '/var/lib/juju/agents/unit-bdv-2/charm/dispatch'
<facubatista> unit-bdv-2: 07:51:44 DEBUG unit.bdv/2.upgrade-charm ============ dispatch path 'hooks/upgrade-charm'
<facubatista> Chipaca, +1ed, please check comments
<Chipaca> will do
<Chipaca> thanks
<Chipaca> facubatista: is_dispatch_aware ?
<facubatista> Chipaca, as long it doesn't confuse with "we're the dispatch script", I'm fine
 * facubatista brb
 * Chipaca â lunch
 * facubatista is back
 * Chipaca is back too, somehow
<Chipaca> facubatista: let me know what you think of 283 now
<facubatista> Chipaca, ack
<Chipaca> facubatista: pretty please :)
<facubatista> Chipaca, +1ed
 * MarkMaglana is EOWing. Y'all have a great weekend. Stay safe and healthy, you fine folks you!
<mup_> PR operator#283 closed: ops/main: handle dispatch being a shim  <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/283>
 * facubatista -> lunch
 * Chipaca brb (to the shop and back)
 * facubatista is back
<facubatista> Chipaca, jam, pushed my "unittest refactoring", now it's "class based"
<Chipaca> facubatista: it looks like tmpdir=self.tmpdir should be the default :-)
<Chipaca> facubatista: but i do understand why not
<Chipaca> facubatista: the docstring still has the same typos tho
<facubatista> Chipaca, you don't always has a tmpdir
<facubatista> Chipaca, we could go to a model of "always having a temp dir", but we would be creating a lot of temp dirs and removing them without need
<facubatista> oh, docstring?
<Chipaca> facubatista: but you could assume self has a tmpdir unless you pass in in_memory=True for eample
<facubatista> ah, docstring
<facubatista> Chipaca, so we would change 10 `tmpdir=self.tmpdir` for 30 `in_memory=True`?
<Chipaca> facubatista: maybe?
<Chipaca> facubatista: wdyt?
<Chipaca> facubatista: wwgvrd?
<Chipaca> :-p
<facubatista> ENOPARSE
<facubatista> Chipaca, so, you're not suggesting tmpdir as default just for simplicity... so what for?
<Chipaca> facubatista: ww(?P<entity>\w+)d == what would $entity do
<Chipaca> facubatista: I am
<Chipaca> facubatista: that's what I'm suggesting, yes indeed
<Chipaca> facubatista: but it's a suggestion, nothing more
<facubatista> isn't it simpler to have 10 `tmpdir=self.tmpdir` than 30 `in_memory=True`?
<facubatista> Chipaca, specially because the onely moments when you pass tmpdir=self.tmpdir is when you're testing what happens between different framework runs
<facubatista> the rest of the test suite, that only needs a framework, they don't care where stuff is located
<Chipaca> facubatista: i might be slow, because i didn't realise it was 10 vs 30
<Chipaca> facubatista: given that, then the current is fine!
<Chipaca> is it really that split? i thought it was the other way around
 * Chipaca counts with his toes
<Chipaca> facubatista: i count 18 create_framework(), vs 16 create_framework(tmpdir=self.tmpdir), which isn't as bad as you said but still favours the current approach
<Chipaca> facubatista: sorry for the noise
<facubatista> Chipaca, https://paste.ubuntu.com/p/MXrT3mx8zv/
<Chipaca> funny how my impression from the pr was that it was almost all (tmpdir=self.tmpdir)
<Chipaca> facubatista: i was doing
<Chipaca> git diff master | grep '^+.*create_framework()'
<facubatista> Chipaca, because those were the ones that "had a diff"
<Chipaca> :) ok
<Chipaca> i think i'm going to soft-EOW. pizza is on its way and i think it's well past beer o'clock.
<facubatista> Chipaca, `+`?
<Chipaca> facubatista: have a good rest-of-the-fridays, and a great weekend! see you monday
<facubatista> I totally NOT understand that grep, but it can wait to Monday :p
<facubatista> Chipaca, have nice pizza time and a better weekend :)
<Chipaca> facubatista: it's grep, not egrep, so the + is literal
<facubatista> ah, you were grepping the diff
 * facubatista ends the day in success \o/
<facubatista> see you all on Monday
