#smooth-operator 2020-05-25
<mup_> Issue operator#292 opened: Need ability to trigger k8s jobs from within charms <Created by jayk-canonical> <https://github.com/canonical/operator/issues/292>
<MarkMaglana> hello folks
<MarkMaglana> so i got a question related to my charming work on prometheus and alertmanager. anyone got time to discuss with me?
<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>
#smooth-operator 2020-05-26
<mup_> Issue operator#293 opened: passing k8s_resources to pod.set_spec does not work <Created by jetpackdanger> <https://github.com/canonical/operator/issues/293>
<Chipaca> good morning peeps!
 * Chipaca takes a break
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð!
<facubatista> hola Chipaca :)
<MarkMaglana> question: is it possible to emit an interface event that comes with a data structure which the charm then fills in with data? i tried it but it looks like the data that the charm set doesn't make its way back to the interface. i suppose it's cloned before being passed to the charm?
<Chipaca> MarkMaglana: you'd need to implement custom serialisers and de-serialisers
<Chipaca> MarkMaglana: other than that i'd expect it to work
<MarkMaglana> Chipaca: got an example? That's not the `snapshot` and `restore` methods is it?
<Chipaca> MarkMaglana: i don't have an example, no -- and yes, snapshot and restore
<Chipaca> MarkMaglana: 'The current storage state is committed before and after each observer is notified.' (what it doesn't say is that _emit is just _reemit with more steps)
<Chipaca> ie the event gets written out, and then read back in
<MarkMaglana> OK thanks! Let me try that out then.
 * Chipaca goes back to having lunch
<Chipaca> facubatista: https://www.pythonpodcast.com/pip-resolver-dependency-management-episode-264/ fwiw
<facubatista> Chipaca, will read, after I finish the review of your branch
<Chipaca> facubatista: I approve of this ordering
<MarkMaglana> Chipaca: I may be doing something wrong. The data that the charm set doesn't make its way back to the interface.
<MarkMaglana> Here's the data structure with custom snapshot and restore: https://github.com/relaxdiego/charm-k8s-alertmanager/blob/7704df683400057208a3f18d79eaf326ce64e22c/src/interface_prometheus.py#L14-L39
<MarkMaglana> Here's the interace's handler/emmitter: https://github.com/relaxdiego/charm-k8s-alertmanager/blob/7704df683400057208a3f18d79eaf326ce64e22c/src/interface_prometheus.py#L85-L95
<MarkMaglana> ...and here's the charm code that tries to modify the data structure: https://github.com/relaxdiego/charm-k8s-alertmanager/blob/7704df683400057208a3f18d79eaf326ce64e22c/src/charm.py#L73-L80
<Chipaca> MarkMaglana: and what do you see in the logs?
<MarkMaglana> Chipaca: https://gist.github.com/relaxdiego/dc3af6827f150cd1b698e2da9106b603
<Chipaca> MarkMaglana: but that shows you getting the data
<Chipaca> MarkMaglana: what are you seeing as broken?
<MarkMaglana> from the interface to the charm, yes. i was hoping that the additional 'test': 'test1' that I set from inside the charm would make its way back to the interface.
<MarkMaglana> see line 14 of that gist
<Chipaca> ohhhh
<Chipaca> MarkMaglana: sorry, I had misunderstood
<Chipaca> MarkMaglana: I don't think that's going to work
<MarkMaglana> did i misunderstand the concept of interfaces? i thought it was meant to be a dumb pipe that both ends of the interface can send and receive messages through.
<Chipaca> facubatista: you froze
<MarkMaglana> Chipaca: oh. I should call `framework.relation_data_set()` inside the charm, huh?
<MarkMaglana> ok i need to revisit this.
<MarkMaglana> time to call it a day for now
<Chipaca> MarkMaglana: i don't see a relation_data_set, but let's talk more tomorrow
<Chipaca> also ja_m comes on early tomorrow so maybe that's more timely for you (he's off today)
 * Chipaca feels like half his brain is off today too
<Chipaca> facubatista: addressed all your concerns with ops.lib except the have-a-dict-per-api one
<Chipaca> still thinking about that one
<facubatista> Chipaca, ack, thanks!
<Chipaca> facubatista: it can't be exactly as you show because then we'd risk overwriting an newer patch-level with an older one for the same api
<Chipaca> but it's an easy tweak
<facubatista> yes, (api, patch)
<Chipaca> but, but, not sure it's simpler. OT1H it's got a better behaviour in a pathologic case
<Chipaca> facubatista: nah, you don't want the patch in that dict, just the api
<facubatista> Chipaca, in any case, even if we keep the current structure, let's think about "repeated" stuff there
<Chipaca> and if d[api] < the_one_i_just_found, then replace it
<Chipaca> facubatista: ok let's do that
<facubatista> mmm... you still need to put 5.4 in that structure, even if you have 5.5, because the user may specify 5.4
<Chipaca> facubatista: no they mayn't
<Chipaca> facubatista: the user may only specify api, not patch
<facubatista> ah, right
<Chipaca> so we only need to keep one
<Chipaca> facubatista: that's we the list is kept sorted
<Chipaca> facubatista: but
<Chipaca> facubatista: the common case is going to be to have just one of these things
<Chipaca> two is already stretching it
<Chipaca> so the current approach seems fine
<facubatista> Chipaca, ok
<Chipaca> if it turns out we're wrong about this and need to change to a dict because, it's a private, invisible change
<Chipaca> so i'm happy as is
<facubatista> Chipaca, +1 with a comment
<facubatista> OTOH, I'm concerned about the quantity of exit points in None, after not finding exactly what we want, without any logging or anything.
<facubatista> this would make debugging that part of the lib really hard
<Chipaca> facubatista: yes. I'm thinking about that a bit.
<facubatista> Chipaca, I propose to be silent only when checking all the sys.path and searching for "opslib" dir... but after that, if we do find a "opslib", we should log in debug why we're skipping what we found
<Chipaca> facubatista: OTOHÂ², I was thinking of writing a second ops.lib.use
<Chipaca> ]:-)
<facubatista> a second one?
<Chipaca> facubatista: one that you run at build time
<Chipaca> facubatista: or at debug time
<Chipaca> and it tells you what it would find, what you're missing, that sort of thing?
<facubatista> ops.lib.search
<facubatista> super verbose
<Chipaca> "you have ops.lib.use('foo') but no foo anywhere", or "you have ops.lib.use('foo') but your requirements do not include those from the foo opslib"
<Chipaca> dunno, spitballing here
<facubatista> ops.lib.use('foo', debug=True)
 * Chipaca wonders why it's called 'spitballing', that's disgusting
<facubatista> verbose=True
<facubatista> explain=True
<Chipaca> facubatista: i was thinking more "charmcraft build runs the charm with DEBUG_OPS_LIB=1"
<facubatista> "foo opslib found, discarding it because LIBPATCH constant is not an int"
<Chipaca> in any case, these are incremental improvements we can â¦ improve
<Chipaca> or we can increment them :-p
<facubatista> Chipaca, checking this "at lib building" (through charmcraft, for example) would bring issues when all these checkings evolve ("it's clean when I build it but in production is not getting found", then to realize the user has OF 0.7 in dev and 0.6 in prod)
<Chipaca> facubatista: so we should be logger.debug(...) stuff in any case
<Chipaca> or logger.info() even
<facubatista> Chipaca, logging in debug why the opslib that we find is not really considered, at .use() time, would be a nice thing
<Chipaca> right
<facubatista> in any case, after we find the "opslib" dir, none of those loggings should be seen, unless the lib itself is malformed
<facubatista> "misformed"? "misshaped"?
<Chipaca> "an mp3 file of a scream"?
<Chipaca> d'oh, forgot to drop the XXX
<facubatista> Chipaca, this is a good source about the "solver": https://github.com/pypa/pip/issues/988
<Chipaca> facubatista: ack
<facubatista> it starts ~7 years ago :)
<Chipaca> facubatista: it's almost as if this stuff were hard
<facubatista> jajaja
<facubatista> go figure
 * facubatista -> bank errands, bb~1h
 * facubatista is back
<mup_> PR operator#294 opened: Log when a served breakpoint is not really activated because of name mismatch <Created by facundobatista> <https://github.com/canonical/operator/pull/294>
 * facubatista eods
#smooth-operator 2020-05-27
<MarkMaglana> hi jam when you're online and have time, i'd like to get some advice on something i wanted to do with interfaces. ultimately what i'd like to achieve is for the interface to have zero knowledge about the charm's domain. rather, i'm trying to just make it provide a data structure to the providing charm and let the latter populate that with the right data which the interface then shoots over to other side.
<jam> morning all
<t0mb0> hi jam I keep getting application-wordpress-k8s: 05:46:42 DEBUG unit.wordpress-k8s/30.start ops.model.ModelError: b'ERROR json: unknown field "readinessProbe"\n' https://pastebin.canonical.com/p/JDc8tjPMfs/
<t0mb0> when I use pod-set-spec version 2
<t0mb0> works for version 1
<jam> t0mb0, I'm not aware of the exact differences, but I do know that some fields are moved around for pod spec v2
<jam> t0mb0, https://discourse.juju.is/t/updated-podspec-yaml-new-features/2124
<jam> t0mb0, looks like in v2 the 'readinessProbe' goes under a "kubernetes" section
<t0mb0> ah okay cool thanks!
<mup_> Issue operator#295 opened: Add resources to harness for oci-images <Created by chris-sanders> <https://github.com/canonical/operator/issues/295>
<mup_> PR operator#296 opened: Oci resources <Created by chris-sanders> <https://github.com/canonical/operator/pull/296>
<Chipaca> good (belated) morning all!
<jam> morning Chipaca
<Chipaca> jam: how was the break?
<jam> pretty good. mostly stayed home. did go out for lunch one day
<Chipaca> jam: oooh! like in the before times!
<jam> indeed. they had the tables spread out, and the menu was a QR code to a PDF so they didn't hand out paper to people
<Chipaca> so like the before times, but updated for the dystopia we actually live in
<Chipaca> fair
<jam> Chipaca, we ended up playing cards and Risk for one day, took several hours to get close to an end of Risk, it was actually pretty fun and back-and-forth.
<jam> How was your extended holiday?
<Chipaca> jam: not bad! didn't do much at all, which was perfect
<Chipaca> facubatista: charmcraft seems to be needing quite a bit of love :-(
<Chipaca> jam: any chance for a review of ops/lib ?
<jam> Chipaca, sure. is that #244, or is there a different PR?
<mup_> PR #244: ops library support <Created by niemeyer> <https://github.com/canonical/operator/pull/244>
<Chipaca> jam: that's the one
<jam> Chipaca, looking
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: buen dÃ­a caeza!
<facubatista> hola Chipaca
<facubatista> Chipaca, thanks for the review
<facubatista> Chipaca, symlinks are not zipped as links, but as the "copied file"
<Chipaca> facubatista: the way we're doing it yes, but it's not the only way
<Chipaca> you can have them as symlinks
<Chipaca> just needs a bit more dancin'
<Chipaca> facubatista: you can see it with the 'zip' tool if you want, 'zip --symlinks' exists
<Chipaca> in python zipfile you need to twiddle things a bit but it works
<Chipaca> facubatista: https://stackoverflow.com/a/60691331/348012
<facubatista> Chipaca, we need to define what stuff in the build directory be like, for "while developing" behaviour; then we can use zip to support what we did there
<facubatista> Chipaca, ack
 * Chipaca starts warming up the valves on his webcam
<jam> brt, my son has a homework questi
<Chipaca> facubatista: charmcraft's setup.py is missing some magic pixie dust or something; it isn't pulling in commands/
<facubatista> Chipaca, oh, nice catch, will check, thanks
<niemeyer> mup_ is now in a better home.. please let me know if something bad happens with it
<niemeyer> I'll be moving the remaining of the configuration from mup to mup_ in the afternoon, and hopefully killing the old instance
<Chipaca> niemeyer: ack
<facubatista> niemeyer, thanks!!
<Chipaca> facubatista, jam, i'm going to be 5 minutes late
<jam> ok
<facubatista> Chipaca, ack
 * facubatista fights auth
<niemeyer> facubatista: np!
<mup_> Issue operator#295 closed: Add resources to harness for oci-images <Created by chris-sanders> <Closed by jameinel> <https://github.com/canonical/operator/issues/295>
<Chipaca> coffee?
<Chipaca> mup_: coffee please. Preferably a flat white, but otherwise a cortado would be fine
<mup_> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
<mup_> Issue operator#297 opened: Remove default target for Framework.observe <Created by jameinel> <https://github.com/canonical/operator/issues/297>
 * Chipaca does the changes and sees a barrage of EEEEs
 * facubatista brb
<Chipaca> jam: would you say that StoredStateData's on_commit is indeed a public api?
<mup_> PR operator#298 opened: ops.framework: Remove default target for Framework.observe <Created by chipaca> <https://github.com/canonical/operator/pull/298>
<jam> Chipaca, offhand I wouldn't think it was meant to be public to others
<facubatista> jam, Chipaca, I included the fix in setup.py in https://github.com/canonical/charmcraft/pull/9
<mup_> PR charmcraft#9: Kill bogus commands, and logged the error when happened <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/9>
<knkski> What is the state of the art for including dependencies in a charmtech charm?
<knkski> previously, it was git submodules, but i'm now seeing references to env/
<knkski> and i'm wondering how that works exactly. am i supposed to vendor all depenencies?
<Chipaca> knkski: where are you seeing references to env?
<knkski> Chipaca: from the readme on https://github.com/canonical/operator:
<knkski> âââ env/â   âââ # ... your Python dependencies, including the operator framework itself
<Chipaca> knkski: depending on what you mean by vendor, git submodules is that already isn't it?
<knkski> Chipaca: i also see "and any Python dependencies (maybe using some kind of virtualenv)"
<Chipaca> knkski: so, we are no longer recommending git submodules. Which does _not_ mean we are dis-recommending them :-)
<Chipaca> knkski: if that works for you, feel free. If you'd rather have a requirements.txt as you would in any python thing, do that
<Chipaca> knkski: does this make sense?
<knkski> Chipaca: so if i have a requirements.txt, how exactly does that work as far as actually getting the items in it installed?
<Chipaca> knkski: can I answer you as if it was this Friday?
<knkski> Chipaca: sure
<Chipaca> knkski: or do you need my answer to be correct and true _today_ :-)
<knkski> Chipaca: lol, friday is fine
<Chipaca> knkski: 'charmcraft build' defaults to picking up a requirements.txt if it exists, and use pip to bundle those into a .charm file
<knkski> Chipaca: how do i get charmcraft installed?
<Chipaca> knkski: pip install charmcraft (this answer is also future-dated; until then github.com/canonical/charmcraft )
<cory_fu> Chipaca: Has the question about different architectures and Python versions been sorted out, then?  (Though that only applies to dependencies which require compilation, like cffi, though I think PyYAML has optional compilation so might hit that as well.)
<knkski> Chipaca: thanks, i'll try it out
<Chipaca> cory_fu: charms will have a 'platform' which is like snaps' 'architecture' but richer (this is not there yet so for now we're ignoring it)
<cory_fu> Chipaca: Ok, that sounds great.  I look forward to that.
 * facubatista missed all this conversation :(
 * facubatista brb
 * facubatista is back
<Chipaca> facubatista: anything I can do for you right now?
<Chipaca> otherwise I'll go for a run and check in later
<facubatista> Chipaca, nop, thanks1
 * Chipaca goes
<knkski> Chipaca: ran into an issue installing charmcraft, and opened up a PR: https://github.com/canonical/charmcraft/pull/10
<mup> PR charmcraft#10: Fix pip installation <Created by knkski> <https://github.com/canonical/charmcraft/pull/10>
<Chipaca> facubatista: what do you think of knkski's fix, compared to yours?
 * facubatista cjecks
<facubatista> Chipaca, the "packages" option is simpler in my case, don't know why the second change is needed
<Chipaca> facubatista: if theirs does what I think it does, it's more future proof, no?
<facubatista> Chipaca, it looks that if in the future we add other subdirs in the project they will be automatically included
<facubatista> Chipaca, not really sure if that's a good thing or not
<facubatista> Chipaca, don't know if the second change is related to the first one, also
<Chipaca> facubatista: I'd have to learn this stuff to answer :
<facubatista> Chipaca, I'm ok with either solution, as long it works
<Chipaca> facubatista: reading the docs, their console_scripts seems more correct, and the find_namespace_packages looks to be the right approach imo (because of the include= arg)
<facubatista> Chipaca, let's land it, and I'll merge my cleanup branch after that
<Chipaca> facubatista: sgtm
<facubatista> Chipaca, landed it, and then merged master in my branch and pushed it...
<Chipaca> facubatista: neat
<mup> PR operator#299 opened: charm: make role an enum, with 'peer' instead of 'peers' <Created by chipaca> <https://github.com/canonical/operator/pull/299>
<mup> PR operator#300 opened: charm: use magic strings a little less <Created by chipaca> <https://github.com/canonical/operator/pull/300>
<Chipaca> ok, i'm off to bed
<Chipaca> hahaha i lied
<Chipaca> ok, now yes
<mup> PR operator#301 opened: charm: role is 'peer', not 'peers' <Created by chipaca> <https://github.com/canonical/operator/pull/301>
<Chipaca> 299, 300, and 301 are all fixes for the same issue. Let's see which one wins the peer review dance :-)
#smooth-operator 2020-05-28
 * facubatista pushed https://github.com/canonical/charmcraft/pull/4
<mup> PR charmcraft#4: First version of the build command <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/4>
<facubatista> now, to sleep
<Chipaca> 's morgens!
<jam> morning Chipaca. I'am about 60% through lib.use. want me to submit what I have so far?
<Chipaca> jam: if it's all good news i can wait :-) if it's things i need to address, i could use the headstart
<jam> Chipaca, I think it mostly breaks down as "we're missing the high level pointers for other people to follow"
<jam> which leads to "why is the code structured this way"
<jam> Chipaca, that, and how much do you want me to dig through the peps to make sure we're using loaders/finders etc as requested for 3.5+
<Chipaca> jam: digging through the peps sounds valuable
<jam> mmm... ananas
<jam> Chipaca, joining?
<Chipaca> jam: i don't seem to have usb â¦ somehow
<Chipaca> i guess a reboot is in order
<Chipaca> i'll be there as soon as i can
<jam> Chipaca, I'll take some time to look over the doc and the issue during this hour
<jam> since its allocated for the conversation
<Chipaca> jam: sounds fair to me
<jam> Chipaca, review submitted
<Chipaca> jam: thanks!
<Chipaca> jam: hah, just realised i've been spamming you with messages instead of batching them up into a comment review thing
<jam> Chipaca, its ok. I'll ignore them all until you tell me to :)
<Chipaca> jam: i've gotten to the bottom of it, and now am writing a missing test and rewriting the 'expected' one to be explicit
<Chipaca> jam: feel free to unignore at this time
 * Chipaca looks for more words that exist both with and without a starting B
<facubatista> Muy buenos dÃ­as a todos!
 * Chipaca wonders on which side of the 'too evil' line using 3âââ3 as an example value is
<pjds> hey operator team, how do we deal with ConfigMaps in the framework?
<facubatista> hello pjds! where, specifically?
<facubatista> (I may not have enought context)
<pjds> hey facubatista, i want to generate and attach a ConfigMap to my pod
<pjds> just trying to see how I can achieve this
<Chipaca> pjds: I don't think we have anything special for that
<jam> pjds, https://juju.is/docs/k8s-charms-tutorial
<jam> pjds, ultimately you'll set the config section as part of the pod spec
<jam> there isn't anything that the Operator wraps around that, so for right now you just pass the config section in.
<pjds> great thank you for pointing me in the right direction
<pjds> ok cool
<Chipaca> facubatista: >  enums are normally compared by equality
<Chipaca> facubatista: the documentation for enum mentions identity directly
<Chipaca> actually i should answer in the PR
<Chipaca> :)
 * Chipaca goes
 * Chipaca gets lunch
<facubatista> jam, Chipaca, may I get a review of my build branch? let's see if we can nail that today, thanks!
<jam> facubatista, yeah, I'm looking at it now
<facubatista> jam, thanks
<facubatista> jam, note travis is unhappy, but only for python 3.5
<facubatista> wow, we need to support Xenial until 2024 :o
<jam> facubatista, releasing now without Xenial support would limit adoption. We don't have to release new versions of operator that still support Xenial once we have one for them to use.
<jam> eg, 1.0 should probably support Xenial, but 2.0 doesn't need to even if it releases is 2023
<facubatista> jam, nice; probably we should extend ourselves until Xenial end of standard support (april 2021)
<facubatista> Xenial has a python 3.5.2 from oct 2019; python 3.5 itself is in "security maintenance mode", with planned end of life on 2020-09-13
<facubatista> *anyway* /me backs to fight 3.5
<jam> facubatista, just checking out your branch and trying to ./run_tests I get a traceback
<jam> https://paste.ubuntu.com/p/mp73VcVbXC/
<jam> (different pytest version?)
<facubatista> jam, maybe! are you using pytest == 5.4.1 ?
<jam> pip3 install --user pytest says I already have 3.3.2 installed
<jam> install --upgrade got me to 5.4.2
<facubatista> jam, you should use a venv
<jam> facubatista, is that a venv, a virtualenv a venv that isn't the other venv ?
<facubatista> jam, what?
<jam> facubatista, there is 'virtualenv' 'pyvenv' 'python3 -m venv'
<facubatista> jam, I use 'fades' 95% of the times, but if I have to create a virtualenv by hand, I use 'virtualenv'
<jam> facubatista, notes that I've seen so far says virtualenv was python2 while venv is python3
<jam> but there doesn't seem to be clear messaging there
<jam> https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe
<jam> has a lot of the confusion
<facubatista> jam, with my rule above I don't have problems :)
<facubatista> note that if you want to try fades, r9 is being released these days, you should use that (I have a .deb already prepared)
<jam> facubatista, but how does a 'virtualenv' get found when ./run_tests just calls "python3" which means I need to somehow put the virtualenv's python3 for *this* project first in PATH?
<facubatista> jam, you first do `virtualenv --python3=python env` to create a venv there in your project directory, then `source env/bin/activate` to "jump into the venv", then you do ./run_tests
<facubatista> jam, sorry, after jumping into the venv and before run_tests, `pip install -r requirements-dev.tx`
<facubatista> to install the requirements, of course
<jam> though requirements.txt exists but is empty and pip complains if you try to use it...
<facubatista> jam, requirements.txt is only for "using" the tool, for "developing" you need the -dev alternative (see my pip install command above)
<jam> facubatista, I understand that, but if it doesn't do anything but cause complaints, I wouldn't recommend having the other file
<facubatista> jam, that's another discussion, isn't it?
<facubatista> jam, Chipaca, there I pushed another revision of my build branch; it should support py3.5 ok (and also refactored a little the "link" helper
<facubatista> )
<DominikF> Hey everyone, does anyone have experience with using actions with the python operator framework in a k8s charm? I created a Dockerfile with python3 installed but when I execute an action I get the following error: https://paste.ubuntu.com/p/hwmNQgmmV4/ What additional dependencies need to be installed besides python3?
<jam> DominikF, the only other dependency for the operator framework is pyyaml
<DominikF> jam: in that case `apt install python3 && apt install pyyaml` should be enough?
<jam> DominikF, I would guess it is python3-yaml
<jam> (and I'd use apt install python3 python3-yaml)
<DominikF> jam: ack, thanks, I'll let you know if I keep having issues
<jam> facubatista, non-build PRs have been reviewed
<Chipaca> facubatista: can you show me how to make the setup.py with 'import <project>' fail?
<facubatista> Chipaca, I'll try :)
<Chipaca> facubatista: meanwhile I'll be reading https://packaging.python.org/guides/single-sourcing-package-version/
<Chipaca> facubatista: ah
<Chipaca> facubatista:
<Chipaca> Warning
<Chipaca> Although this technique is common, beware that it will fail if sample/__init__.py imports packages from install_requires dependencies, which will very likely not be installed yet when setup.py is run.
<Chipaca> facubatista: ^ about my suggested approach
<Chipaca> so it works iff charmcraft/__init__.py doesn't import anything non-stdlib
 * Chipaca adds more negation pairs in there for extra fun
<facubatista> Chipaca, what about __init__ importing stuff from the project itself?
<Chipaca> facubatista: basically setup.py will be run before installing any of the requirements so if it tries to import any of those it'll fail
<Chipaca> facubatista: from that document, option 7: Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using setuptools_scm.
<Chipaca> that's https://pypi.org/project/setuptools-scm/
<facubatista> Chipaca, which will not work if you run the project from a tarball
<Chipaca> facubatista: f the normal methods for detecting the version (SCM version, sdist metadata) fail, and the parent directory name starts with parentdir_prefix_version, then this prefix is stripped and the rest of the parent directory name is matched with tag_regex to get a version string. If this parameter is unset (the default), then this fallback is not used.
<Chipaca> This is intended to cover GitHubâs ârelease tarballsâ, which extract into directories named projectname-tag/ (in which case parentdir_prefix_version can be set e.g. to projectname-).
<Chipaca> facubatista: quisiÃ³
<Chipaca> facubatista: i only mention it because you liked the git describe approach :)
<facubatista> Chipaca, I found that setuptools-scm thingie when I explored the version alternatives, it looked a good idea... then I started to read it's README, stuff like
<facubatista> The preferred way to configure setuptools_scm is to author settings in a tool.setuptools_scm section of pyproject.toml.
 * Chipaca sets toml on fire and runs away
<facubatista> and starts to talk about stuff that we do not have
<facubatista> and then I decided that I would not change the whole project structure just to use an extra dependency just to get a version number, specially if we still didn't decide what we want in that regard
<Chipaca> facubatista: I want the pig, and the piglets, *and* the sausages
<Chipaca> facubatista: what's so hard to understand
<facubatista> nice, now my branch fails with
<facubatista> AttributeError: module 'setuptools' has no attribute 'find_namespace_packages'
 * Chipaca hugs facubatista 
<Chipaca> facubatista: that's from #10
<mup> PR #10: Code spacing is a useful organizational aid <Created by niemeyer> <Merged by niemeyer> <https://github.com/canonical/operator/pull/10>
<Chipaca> no, charmcraft#10
<mup> PR charmcraft#10: Fix pip installation <Created by knkski> <Merged by facundobatista> <https://github.com/canonical/charmcraft/pull/10>
<facubatista> Chipaca, yes, I know
<Chipaca> facubatista: but setuptools has had find_namespace_packages since 3.4 or something
<facubatista> Chipaca, remember I wanted it to be simpler?
 * Chipaca hugs facubatista more
<Chipaca> facubatista: where is it failing like this?
<mup> Issue operator#271 closed: Relation.role should be 'peer' not 'peers' <bug> <Created by jameinel> <Closed by chipaca> <https://github.com/canonical/operator/issues/271>
<mup> PR operator#299 closed: charm: make role an enum, with 'peer' instead of 'peers' <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/299>
<Chipaca> ooh, #298
<mup> PR #298: ops.framework: Remove default target for Framework.observe <Created by chipaca> <https://github.com/canonical/operator/pull/298>
<Chipaca> facubatista: could you take a poke at it? while i continue to review your build pr :-p
<mup> PR operator#300 closed: charm: use magic strings a little less <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/pull/300>
<facubatista> Chipaca, after I unblock charmcraft
<mup> PR operator#301 closed: charm: role is 'peer', not 'peers' <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/pull/301>
<facubatista> Chipaca,
<Chipaca> facubatista: k
<facubatista> (Pdb) pp setuptools
<facubatista> <module 'setuptools' from '/home/facundo/.local/share/fades/faa8b89f-fb63-4517-b6af-d769529e94a3/lib/python3.6/site-packages/setuptools/__init__.py'>
<facubatista> (Pdb) pp setuptools.__version__
<facubatista> '39.0.1'
<facubatista> (Pdb) pp setuptools.find_namespace_packages
<facubatista> *** AttributeError: module 'setuptools' has no attribute 'find_namespace_packages'
<Chipaca> facubatista: what python version?
<Chipaca> facubatista: i have setuptools 45 here fwiw
<Chipaca> 45.2.0
<facubatista> Chipaca, ah, wonderful
<facubatista> Chipaca, see, https://setuptools.readthedocs.io/en/latest/setuptools.html#find-namespace-packages
<facubatista> Chipaca, it DOES NOT say "available since vX.Y"
<Chipaca> facubatista: yeah
<Chipaca> facubatista: was about to say that much :)
<facubatista> Chipaca, that is a mistake we must not commit
<Chipaca> facubatista: indeebly
<facubatista> Chipaca, I added     install_requires=['setuptools>=45'], in setup.py
<facubatista> Chipaca, but we'd need to really test that
<facubatista> Chipaca, if I build a tarball, and try to install from that tarball, it fails with
<facubatista> AttributeError: module 'setuptools' has no attribute 'find_namespace_packages'
<facubatista> (I'd expect with something like "setuptools doesn't match")
<facubatista> ah, let's try fades on it
<facubatista>     AttributeError: module 'setuptools' has no attribute 'find_namespace_packages'
<facubatista> Chipaca, I'm tempted to go back to my simpler way of doing it, and in any case fight this in the second release (when we know everything else already works)
<Chipaca> facubatista: +1
<jam> facubatista, feedback on 'charm build'. I'm going to go have dinner, I'll try to be back around for responses.
<Chipaca> jam: thank you!
<facubatista> jam, thanks!
<facubatista> Chipaca, now this works as expected:
<facubatista> $ fades -d file:///home/facundo/canonical/charmcraft/ -m charmcraft version
<facubatista> Version: 0.0.1
<Chipaca> facubatista: hu to the zah
<facubatista> Chipaca, so, I pushed charmcraft#8
<mup> PR charmcraft#8: Have a version in the project, show it in the command and on startup <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/8>
<facubatista> Chipaca, I simplied setup.py, in general (grab __version__ from charmcraft.__init__, and better packaging, but also removed requirements.txt stuff (as it is empty! if we start to have stuff there in the future we put it back)
<facubatista> Chipaca, let me know if you want to take a look at it or I just land it
 * facubatista brb
<Chipaca> facubatista: charmcraft#8 is GTG
<mup> PR charmcraft#8: Have a version in the project, show it in the command and on startup <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/8>
 * facubatista is back
<facubatista> ok, the only missing branch is the build one
<facubatista> Chipaca, I'll address jam comments there and then attack your branch, as jam would probably be almost gone
<Chipaca> facubatista: ok
<mup> Issue operator#122 closed: Interface class repository <Created by majduk> <Closed by chipaca> <https://github.com/canonical/operator/issues/122>
<mup> PR operator#244 closed: ops library support <Created by niemeyer> <Merged by chipaca> <https://github.com/canonical/operator/pull/244>
<facubatista> jam, ooohhh, we do not HAVE to put stuff under src? I thought we had, this is great!
<Chipaca> facubatista: we do not
<facubatista> great, so I will stop creating the src/ dir inside the build
<Chipaca> yeah that bit is weird, i hadn't noticed it
<Chipaca> facubatista: this is so close :-D
<Chipaca> facubatista: the comment on '--quiet' feels off
<facubatista> Chipaca, which comment where?
<Chipaca> facubatista: should i push a pr for that?
<facubatista> ah, my branch
<Chipaca>   -q, --quiet    shh!
<Chipaca> ^^ that one :)
<facubatista> ah
<facubatista> Chipaca, no, just tell me what to put there
<Chipaca> facubatista: depending on exactly what it does (i haven't checked), it could be 'suppress the usual output' or 'only print errors'
<facubatista> Chipaca, it puts the logger in WARNING level, so no normal info will be seen
<facubatista> jam, I will address all specific comments on each conversation, but from your general comment:
<facubatista> 1. you're right! src not needed, will remove that
<Chipaca> facubatista: "only show warnings and errors, not progress"? something like that
<facubatista> 2. regarding symlink in build and then expand in the file: let's land current behaviour now, please open an issue in the project with what you think would be a better alternative
<facubatista> Chipaca, like it; for -v I put "be more verbose and show debug information", what do you think?
<Chipaca> facubatista: sgtm
<Chipaca> facubatista: don't forget a review on 298 please
<Chipaca> i'm going for a run, and then we'll be having dinner -- ttfn but ttyl
<facubatista> Chipaca, no worries
<jam> facubatista, Chipaca sgtm for build
<facubatista> jam, question regarding HOOKs
<jam> sure
<facubatista> jam, you mentioned TWO issues in your parragraph, right? first, why I'm handling only some hooks, and not others; second, what about symlink chains -- right?
<jam> that sounds correct
<facubatista> jam, so, 1. I think you're right, I'm not checking "all the other stuff under hooks"... so I propose this behaviour: let's "respect" everything the user has under hooks, and also verify that the "mandatory" ones are present, else create them
<facubatista> what do you think?
<jam> facubatista, I like it. We should think about how we want to handle 'helper' files. Should we only include hooks that we know about or should we bring everything in the 'hooks' dir.
<facubatista> jam, I'd bring everything
<jam> facubatista, I agree
<facubatista> jam, great
<facubatista> jam, 2. that symlink chain works for now, as the zip is putting just the content; but let's talk about this in the future when we revisit this "why all links?" -- what do you think?
<jam> facubatista, yeah, creating hooks/install => ../src/charm.py will end up expanded (if I understand the code correctly), but we can address that when we address symlinks generally
<facubatista> jam, great
<facubatista> jam, all addressed, sorry for the delay
<facubatista> Chipaca, bb in 15' and do that review
<facubatista> jam, please let me know when you have news on my branch, thanks!
<facubatista> Chipaca, you need to change two small details in operator#298
<mup> PR #298: ops.framework: Remove default target for Framework.observe <Created by chipaca> <https://github.com/canonical/operator/pull/298>
 * facubatista bb ~30'
<jam> facubatista, reviewed
<jam> Chipaca, https://github.com/canonical/charmcraft/pull/4 needs your sign off, IIRC
<mup> PR charmcraft#4: First version of the build command <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/4>
<facubatista> jam, thanks!
<facubatista> Chipaca, regarding charmcraft, shouldn't we have a snap?
<Chipaca> facubatista: at some point, yes! the name is already reserved
<Chipaca> jam: i've been poking at it irl and giving facundo feedback from there, which he's been integrating. I'll take another pass now :-)
<Chipaca> facubatista: how's things?
<facubatista> Chipaca, I think I need your re-review in https://github.com/canonical/charmcraft/pull/4
<mup> PR charmcraft#4: First version of the build command <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/4>
<Chipaca> facubatista: yep
<Chipaca> facubatista: doing that
<Chipaca> facubatista: niiice
<facubatista> Chipaca, ?
<Chipaca> facubatista: src and lib and requirements handling improved
<Chipaca> facubatista: it's good :-)
<facubatista> Chipaca, do I owe you changes in that branch?
<Chipaca> facubatista: other than the typo, no :)
<Chipaca> i don't think so
<facubatista> Chipaca, would you approve it?
<Chipaca> facubatista: i think we can call it a wrap
<facubatista> (the typo is already fixed)
<Chipaca> facubatista: yeah i saw
<Chipaca> facubatista: i need a re-review on #298 tho
<mup> PR #298: ops.framework: Remove default target for Framework.observe <Created by chipaca> <https://github.com/canonical/operator/pull/298>
<Chipaca> facubatista: charmraft#4 is green
<Chipaca> facubatista: also charmcraft#4
<mup> PR charmcraft#4: First version of the build command <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/4>
<Chipaca> facubatista: i really need a re-review on #298 tho :)
<mup> PR #298: ops.framework: Remove default target for Framework.observe <Created by chipaca> <https://github.com/canonical/operator/pull/298>
<facubatista> Chipaca, yes
<facubatista> Chipaca, approved, but please bring the message checking back
<facubatista> (I put in a comment the syntax to do that while still using assertRaises
<facubatista> )
<Chipaca> facubatista: I thought the `msg` arg to assertRaises did that automagically
<Chipaca> facubatista: but assertRaisesRegexp does what i want \o/
<Chipaca> Regex*
<pjdc> hi, i'm adding unit tests to a charm i'm working on, but it's blowing up while the hardness is initializing. here's the transcript: https://pastebin.canonical.com/p/n78cRHhV57/
<pjdc> is this a bug in my charm, the psql interface, the framework, or something else?
<pjdc> and here's my __init__: https://git.launchpad.net/charm-k8s-mattermost/tree/src/charm.py#n44
<pjdc> s/hardness/harness/ d'oh
<Chipaca> hmm
<Chipaca> there's something strange, but i need facubatista's eyes on it maybe
<pjdc> just pushing the tests branch now
<Chipaca> pjdc: you're doing
<Chipaca> self.framework.observe(self.db.on.database_relation_joined, self._on_database_relation_joined)
<Chipaca> which seems weird to me
<Chipaca> but maybe i'm missing something :)
<pjdc> https://git.launchpad.net/~pjdc/charm-k8s-mattermost/+git/charm-k8s-mattermost/tree/tests/unit/test_charm.py?h=s3-wip
<pjdc> Chipaca: fwiw, the charm does work, only the tests are new
<Chipaca> pjdc: because i'd expect that line to look more like  self.framework.observe(self.on.db_relation_joined, self._on_database_relation_joined)
<pjdc> self.db is a pgsql.PostgreSQLClient(self, 'db')
<Chipaca> yep
<pjdc> pretty sure this is copy and paste from the interface README, but lemme check
<Chipaca> :)
<pjdc> yeah, looks the same to me https://git.launchpad.net/~stub/interface-pgsql/+git/operator/tree/README.md
<facubatista> Chipaca, it makes sense to me, IIUC it's doing the same than in my fake charm with an interface: https://paste.ubuntu.com/p/Ns2sMzrJk9/
<facubatista> see line 24 there
<Chipaca> facubatista: right, but the <relation>_relation_joined event is "ours"
<Chipaca> facubatista: it's not a custom interface-provided one
<pjdc> but, as mentioned, the charm does work, so it seems the harness is adding a new expectation
<Chipaca> pjdc: wouldn't be surprising :) but it also might be pointing at something deeper
<Chipaca> unfortunately it's beyond my expertise still; you'd have to check with j_am but he's away until Sunday
<facubatista> I'm for sure too tired to debug that
<Chipaca> pjdc: could you file an issue with just the info you've given it, so he gets to go through that when he gets in?
<Chipaca> s/given it/given us/
<pjdc> sure thing
<facubatista> pjdc, let's see if tomorrow I could give you a hand
<Chipaca> pjdc: thanks!
<Chipaca> facubatista: if you can, it'll be in an issue :-D
<pjdc> this is my last working day this week, but i'm on call so i should be able to c heck in
<pjdc> will file that issue now
<facubatista> pjdc, ah, so we're not making lose you a day
<Chipaca> pjdc: thanks! sorry it's not as expedient as I'd like it to be (we'll get there! but not there yet)
<facubatista> *making you lose a day
<pjdc> no worries
<facubatista> Chipaca, we can call it a day, and do the releases tomorrow?
<Chipaca> facubatista: let's land everything today, and tag and release tomorrow
<Chipaca> facubatista: i just need to wait for #298 to be green and I'm done :-D
<mup> PR #298: ops.framework: Remove default target for Framework.observe <Created by chipaca> <https://github.com/canonical/operator/pull/298>
<facubatista> charmcraft is pristine
 * facubatista opens a bottle of wine
<Chipaca> facubatista: we'll want to work on the README a bit tomorrow also (on both sides)
<Chipaca> but i'm happy with that level of changes :-)
<facubatista> Chipaca, +1
 * facubatista eods, then
<Chipaca> facubatista: chin chÃ­n
 * Chipaca would so have a fernet right now
<mup> Issue operator#302 opened: AttributeError: 'MattermostCharmEvents' object has no attribute 'db_relation_joined' <Created by jetpackdanger> <https://github.com/canonical/operator/issues/302>
<Chipaca> pjdc: thanks!
 * Chipaca tries to get from jetpackdanger to pjdc and falls down a rabbithole of RPN and rum
<Chipaca> woo, 0.6 is code complete
<Chipaca> and on master
 * Chipaca dances
<mup> Issue operator#297 closed: Remove default target for Framework.observe <Created by jameinel> <Closed by chipaca> <https://github.com/canonical/operator/issues/297>
<mup> PR operator#298 closed: ops.framework: Remove default target for Framework.observe <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/298>
<pjdc> the joke is that my middle names are jetpack and danger
<Chipaca> I don't judge. A very good friend has database-breaking middle names too.
<Chipaca> anyway, EOD for me! wish me luck with that Zzz thing
<pjdc> oh, i figured it out. the metadata.yaml i passed to the constructor didn't include the DB relation
<pjdc> actually it seems i can just remove meta and it, i assume, reads metadata.yaml from the charm itself. at any rate, the tests still pass
#smooth-operator 2020-05-29
<mup> Issue operator#303 opened: ints in pod spec somehw become scientific notation <Created by jetpackdanger> <https://github.com/canonical/operator/issues/303>
<MarkMaglana> hi there.
<Chipaca> anybody with a python 3.7 around?
<facubatista> Muy buenos dÃ­as a todos!
<facubatista> Chipaca, I can prepare a docker with it, what do you want to test?
<Chipaca> facubatista: nah, just to be precise in a comment
<Chipaca> facubatista: good morning to you too!
<facubatista> ok
<facubatista> :)
<Chipaca> facubatista: i started playing with getting an ops version in there
<facubatista> I've brought my release day clothes today!
<Chipaca> and went down a bit of a rabbit hole
<Chipaca> facubatista: excellent!
<Chipaca> facubatista: I'm stopping for lunch in 30' but things are looking good
<facubatista> Chipaca, "getting an ops version in py 3.7"? not sure what that means
<Chipaca> facubatista: i wrote this thing, that i'm backing out for now but will push for early 0.7
<Chipaca> facubatista: https://paste.ubuntu.com/p/PBS2TQxVrg/
<Chipaca> facubatista: sorry, the 3.7 was not directly connected to 3.7
<Chipaca> facubatista: just that in 3.5 and 3.6 ast.parse('"42"').body[0].value is ast.Str, and in 3.8 it's ast.Constant
<Chipaca> facubatista: and so I added if isinstance() with a comment # >= 3.8
<facubatista> Chipaca, ah! I got master(ish), it could be of use
<Chipaca> facubatista: i wanted to check if that was accurate, or if the change was in 3.7 already
<facubatista> ah, understand
<Chipaca> facubatista: the documentation is a tiny bit unclear on this; it's been a transition that happened between 3.5 and 3.8 :)
<Chipaca> facubatista: in 3.8 ast.Constant was used for 'all constants', and ast.Str is deprecated, but it's been a transition
<Chipaca> facubatista: it's not super important :-)
<Chipaca> nobody uses 3.7 anyway :-p
<facubatista> jajaja
<facubatista> probably true
<Chipaca> facubatista: and all this is because we can't import ops to get ops.__version__ because yaml
<Chipaca> (boo hiss etc)
<facubatista> Chipaca, which is what normally happens
<Chipaca> facubatista: so i wrote some code :-)
<Chipaca> facubatista: https://paste.ubuntu.com/p/x7kTxBPDwK/
<facubatista> Chipaca, I get it; my solution (in charcramft early version) was way less elegant, but didn't depend on internals, so it's more robust to be executed later in the wild (it's more fragile in the sense that we may break it changing some code, but that would be catched by the test)
<mup> Issue operator#304 opened: Use git describe to log version when running from git <Created by chipaca> <https://github.com/canonical/operator/issues/304>
<Chipaca> facubatista: which internals?
<mup> PR operator#305 opened: Tweaks to the README, setup.py, etc, for release <Created by chipaca> <https://github.com/canonical/operator/pull/305>
<Chipaca> facubatista: ^
<facubatista> Chipaca, "internals" -> ast nodes
<facubatista> Chipaca, on the PR
<facubatista> Chipaca, reviewed
<Chipaca> facubatista: picky, picky
<Chipaca> facubatista: hmm, with '.' in reqs 'pip install -r reqs' installs ops, which might be surprising; wdyt?
<facubatista> Chipaca, yes, you do not want that
<Chipaca> ok, i'll revert
<Chipaca> facubatista: wdyt of making install_requires load requirements.txt?
<facubatista> as this is a lib, +1
<Chipaca> facubatista: hm, the internet seems to think we're using reqs wrong :)
<facubatista> Chipaca, we're stretching it, requirements.txt is normally used to "run" something; this is a pure lib, you don't "run" it
<facubatista> Chipaca, you normally install it, and with install_requires in setup.py it will bring the needed dependencies
<Chipaca> facubatista: looks like doing '-e .' instead of '.' does what we want
<facubatista> that said, how do you express "if you want to use this lib from this branch, you need also these libs to use it"?
<facubatista> Chipaca, we don't *really need* the requirements.txt file (we do need the requirements-dev.txt one, though)
<Chipaca> facubatista: 'python setup.py develop'?
<Chipaca> facubatista: but the -e . in reqs dtrt so \o/
<facubatista> Chipaca, I don't trust doing stuff like 'python setup.py develop' for those libraries that you may be using and developing *at the same time*
<Chipaca> facubatista: ok
<Chipaca> facubatista: can you check that '-e .' does the right thing in that sense, for you?
<Chipaca> facubatista: (when install_requires is ["PyYAML"])
<facubatista> Chipaca, I can check it, I would test it IRL, for that you need to fix first the find_packages thing
<Chipaca> facubatista: what fix to the find_packages thing?
<facubatista> Chipaca, https://github.com/canonical/operator/pull/305#discussion_r432440861
<mup> PR #305: Tweaks to the README, setup.py, etc, for release <Created by chipaca> <https://github.com/canonical/operator/pull/305>
<Chipaca> facubatista: remind me again, what version of setuptools did you have?
<facubatista> Chipaca, an old one, which is my exact point: you need to specify somehow that the installation procedure needs a modern setuptools if you want to use that method in setup.py
<facubatista> Chipaca, otherwise people will not be able to install the lib
<facubatista> btw, I'm in Bionic, not that I have really old stuff
<Chipaca> facubatista: we don't have namespace packages anyway :)
 * facubatista brb
<Chipaca> facubatista: what would you say to recording a video of these things working in concert?
<facubatista> Chipaca, I'm not sure there's a "history to tell" that is best shown in a video than in a tutorial
<Chipaca> facubatista: tutorial then :-D :-D
<Chipaca> facubatista: unrelatedly: you know that 'ops $version up and running' thing? it gets annoying :-|
<Chipaca> facubatista: WDYT of instead having it add [ops:$version] to each log line? would that be less annoying?
<Chipaca> ie '%(asctime)s %(levelname)-8s %(message)s' â '%(asctime)s %(levelname)-8s [ops:$(version)s] %(message)s'
 * Chipaca butchered that line but hopefully the idea survived
<facubatista> Chipaca, remember I wanted to gain "visibility of log lines from the OF"? maybe this "inline version" a good way
<Chipaca> i remembered :)
<Chipaca> facubatista: ok i'll do that
<Chipaca> facubatista: getting my headset
<facubatista> oops
<mup> Issue operator#306 opened: Add [ops:<version>] to operator log lines <Created by chipaca> <https://github.com/canonical/operator/issues/306>
<facubatista> Chipaca, what do we consider more "basic"? the 'install' hook or the 'start' hook?
<Chipaca> facubatista: what does 'basic' mean?
<Chipaca> facubatista: they both have the same Ph :-p
<facubatista> JAJAAJ
<facubatista> Chipaca, "barely first thing you need to see/understand"
<facubatista> if we hook on one event, which one is that? start or install?
<Chipaca> facubatista: i think people not doing k8s will only be dimly aware of the 'start' one, and people doing k8s will know of 'install', so probably install
<Chipaca> facubatista: but, 'if we hook on one event', that depends on the juju version :-)
<Chipaca> facubatista: if you can assume 2.8, then 'install' always
<facubatista> ack
<Chipaca> facubatista: one thing about 'charmcraft build' that i noticed, that was surprising to me
<Chipaca> facubatista: is that the .charm is named after the directory you're in, instead of using the name from the model
<Chipaca> facubatista: ie i think it should use the 'name' from metadata.yaml
<facubatista> mmm, yes
<Chipaca> facubatista: (not for today)
<facubatista> Chipaca, good idea
<Chipaca> facubatista: (issue plz?)
<facubatista> ox courz
<Chipaca> facubatista: for the tutorial, make the directory be the same as the model name so we don't lie but also don't surprise people :-D
<facubatista> perfect
<facubatista> Chipaca, we should make a meeting around charmcraft issues, at least for "basic setup" like creating a couple of milestones, prioritizing, etc
<facubatista> we have 8 open already! :D
<Chipaca> facubatista: i was about to create milestones but then realised we hadnt agreed on cadence so i punted
<Chipaca> facubatista: but yes
<Chipaca> facubatista: would having the same cadence as ops be reasonable?
<facubatista> Chipaca, "punted"?
<Chipaca> facubatista: 'lo patiÃ©'
<Chipaca> punted [it]
<Chipaca> facubatista: i called defer()
<facubatista> :)
<facubatista> Chipaca, one "big number" release per month sounds good; we can have "small number" releases in the middle if we want some urgent fix or whatever
<Chipaca> facubatista: ð
 * facubatista is not sure about calling those major/minor/patch/etc
<Chipaca> facubatista: this is charmcraft 0.1.0, right?
<facubatista> Chipaca, we can go with that, yes
<facubatista> Chipaca, probably we should define "all that charmcraft needs to support" before getting to 1.0; we need to have this in mind when we review all the commands
<Chipaca> facubatista: created 0.2.0 and later milestones for charmcraftrmrmr
<facubatista> thanks
<Chipaca> facubatista: #305 ready for re-review i think
<mup> PR #305: Tweaks to the README, setup.py, etc, for release <Created by chipaca> <https://github.com/canonical/operator/pull/305>
<facubatista> Chipaca, at install level, all is fine: https://paste.ubuntu.com/p/psw4Tpf35g/
<facubatista> Chipaca, +1ed
<Chipaca> facubatista: woo
<mup> Issue operator#290 closed: recommend install hook over start <Created by jetpackdanger> <Closed by chipaca> <https://github.com/canonical/operator/issues/290>
<mup> PR operator#305 closed: Tweaks to the README, setup.py, etc, for release <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/305>
<Chipaca> facubatista: https://pypi.org/project/ops/0.6.0/
<facubatista> Chipaca, rocanrol: https://paste.ubuntu.com/p/SJHGzjdP7m/
<Chipaca> facubatista: con fritas
<facubatista> Chipaca, did I comment you about this new feature? see line 8 in the pastebin
<Chipaca> facubatista: you did not
<facubatista> fades, the easiest way to try Python libraries since libraries were invented
 * Chipaca resurrects 'import pip.<thing>'
 * Chipaca does not
<Chipaca> i'm going to get a cuppa tea and come back to write a README
<facubatista> Chipaca, Houston, we have a etc, etc
<Chipaca> facubatista: charmcraft#14 if you would
<mup> PR charmcraft#14: update README.md to be more introductory <Created by chipaca> <https://github.com/canonical/charmcraft/pull/14>
<Chipaca> facubatista: what did i break? :-|
<facubatista> Chipaca, let's do a HO, but first let my try something
<Chipaca> facubatista: is the problem charmcraft-side, or ops-side?
<facubatista> Chipaca, charmcraft
<Chipaca> facubatista: ok. what's the problem?
<facubatista> 2020-05-29 12:38:13,904  charmcraft.commands.build DEBUG    :: no such option: --system
<facubatista> Chipaca, let's HO in the standup url
<Chipaca> I'm going for a run, will bbiaw
 * facubatista is back
<facubatista> Chipaca, branch: https://github.com/canonical/charmcraft/pull/15
<mup> PR charmcraft#15: Don't use --system  parameter in pip install <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/15>
<facubatista> Chipaca, first draft of the tuto: https://gist.github.com/facundobatista/d3b7de7a624915227de051cba079e3d6
<facubatista> really in alpha
 * facubatista brb
 * facubatista is back
<facubatista> Chipaca, now the tutorial is "beta" :p
<Chipaca> facubatista: --system isn't needed when used with --target, right?
<Chipaca> facubatista: or are we breaking something else and we'll need to revisit?
<Chipaca> (not now but eventually i mean)
<facubatista> Chipaca, I couldn't find anything that should be fixed
<Chipaca> facubatista: I APPROVE
<Chipaca> facubatista: next week, can i convince you to not do branches on the project itself?
<facubatista> Chipaca, you could try
<Chipaca> facubatista: ok :)
<Chipaca> i'll do my best
<Chipaca> facubatista: travis is being all travis-y
<Chipaca> facubatista: did you look at charmcraft#14 ?
<mup> PR charmcraft#14: update README.md to be more introductory <Created by chipaca> <https://github.com/canonical/charmcraft/pull/14>
<facubatista> nop, will now
<Chipaca> facubatista: thankyoup
<facubatista> Chipaca, approved, with a comment
<facubatista> Chipaca, my branch is ready to land but has only one approve
<Chipaca> facubatista: ï½ï½ï½ï½ï½  ï½ï½  ï½ï½  ï½ï½ï½ï½ï½ï½
 * facubatista checks his spoons
<Chipaca> facubatista: wait, does this mean we're Done?
<facubatista> Chipaca, what about the tutorial?
<Chipaca> facubatista: not needed for release :)
<facubatista> Chipaca, you should push to PyPI
<Chipaca> facubatista: yes
<Chipaca> facubatista: but first I should tag
<Chipaca> facubatista: wait, we need one more to actually bump the version
<Chipaca> d'oh
<Chipaca> facubatista: do you want to do the honours?
<facubatista> ok
<Chipaca> facubatista: at some point, let's move all our copyright headers to the juju style
<facubatista> Chipaca, ok
<Chipaca> much cleaner
<facubatista> Chipaca, as long lawyers rest in peace, I'm ok
<facubatista> Chipaca, https://github.com/canonical/charmcraft/pull/16
<mup> PR charmcraft#16: Version 0.1.0 <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/16>
<Chipaca> facubatista: +1
<vgrevtsev> hi all - first of all, congrats with the first release \o
<vgrevtsev> second... I'm writing a test and encountered a little problem, hope someone can help :)
<vgrevtsev> so, tl;dr I'm trying to access a StoredState from the test, but it fails -> https://paste.ubuntu.com/p/BPkFy8zmjP/
<vgrevtsev> any ideas or advices are very appreciated :)
<Chipaca> man, stop breaking our stuff :-p
<facubatista> :)
<vgrevtsev> :'(
 * facubatista bb~1h
<Chipaca> vgrevtsev: where does the charm in line 13 come from?
<vgrevtsev> it's a `charm.py` file. and `on_config_changed_handler` is a function nmame
<vgrevtsev> name*
<vgrevtsev> here is it: https://paste.ubuntu.com/p/ty3YtMtCvx/
<Chipaca> vgrevtsev: i mean, what created it?
<vgrevtsev> `import charm`, that's it
<vgrevtsev> https://paste.ubuntu.com/p/TyXhMSyTXC/ line 98
<Chipaca> vgrevtsev: i have no idea what any of those things are :-(
<vgrevtsev> :(
<vgrevtsev> ok, let me ask another question then: what's the right way to access the StoredState object or mock it? I tried to initialize it in the test itself (in `setUp`), but sounds like it requires a framework context
<Chipaca> vgrevtsev: there seems to be a whole other framework involved in this
<Chipaca> vgrevtsev: are you asking about the framework-private stored state, or about the stored state of your charm?
<vgrevtsev> I wish I knew the difference...
<Chipaca> the framework uses a stored state object for some internal stuff, but i don't think you should care about that
<Chipaca> so i'm assuming it's for your charm
<vgrevtsev> I think I'm asking about the latter - I need to store some state during the hook execution and then check it
<Chipaca> vgrevtsev: so the way you do that is by asking for it explicitly, something like
<Chipaca> class MyCharm(CharmBase):
<Chipaca>     _stored = StoredState()
<vgrevtsev> That's what I did...
<vgrevtsev> (except of the `_stored` naming)
<Chipaca> vgrevtsev: so if you need to test that your charm is saving the right thing in that stored state attribute, you can either replace it with a double, or mock it, or query it directly
<Chipaca> it's just a python dict-that-ends-up-in-a-sqlite
<vgrevtsev> I wonder why Harness instance doesn't have a `charm` object (it returns None) instead of anything
<vgrevtsev> `Note that the Charm is not instantiated until you have called` ah,.......
<vgrevtsev> Well.
<vgrevtsev> Gimme a sec. :-D
<Chipaca> vgrevtsev: did you harness.begin()?
<vgrevtsev> I did (now). And the error is different now: "RuntimeError: unable to define an event with event_kind that overlaps with an existing type <class 'ops.testing.Harness.begin.<locals>.TestEvents'> attribute: http_api_relation_created"
<Chipaca> vgrevtsev: hmm, that's probably a wart we're wanting to fix, that has a workaround that i forget but give me a bit
<Chipaca> vgrevtsev: you have more than one test that's creating a harness on the same charm class, right?
<vgrevtsev> Chipaca: no, that's not correct. I have one test class with one test, creating a Harness object from the inside of the test function
<Chipaca> vgrevtsev: I'm afraid I'm going to ask you to file a bug, and chase jam about it
<Chipaca> i'm pretty sure he knows exactly what to do with that
<vgrevtsev> Sure.
<Chipaca> i might be wrong :)
<vgrevtsev> I assume jam is already eod?
<Chipaca> vgrevtsev: he's eow
<vgrevtsev> yeah true, it's friday :D
<Chipaca> so should i be, but i'm waiting to do a release before disappearing :-)
<Chipaca> vgrevtsev: his week goes sun-thu, to make it more fun
<vgrevtsev> oh wow
<Chipaca> and travis is taking ages! and my beer is going cold!
<Chipaca> well, that last one isn't necessarily bad
<Chipaca> charmcraft 0.1.0 is out
<Chipaca> facubatista: have a great weekend! the tutorial is looking good, I'd like to include a link to it in the status email (going out Monday)
* Chipaca changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.6.0 RELEASED (pip install ops) || charmcraft 0.1.0 RELEASED (pip install charmcraft) || have a great weekend
<facubatista> Chipaca, mmm... we may have a bug
<Chipaca> facubatista: lies!
<Chipaca> facubatista: we only have hard to understand features
<Chipaca> :-p
<facubatista> jajaja
<Chipaca> facubatista: contÃ¡ contÃ¡
<facubatista> Chipaca, https://is.gd/rxVXTp
<Chipaca> facubatista: what's that?
<facubatista> Chipaca, why its setup.py is trying to read requirements.txt?
<facubatista> that is not in master
<facubatista> what did you push? :p
<Chipaca> facubatista: that's also missing commands/
<Chipaca> facubatista: i pushed 0.1.0
<Chipaca> what is that
<Chipaca> ok let me fix this
<facubatista> https://pypi.org/project/charmcraft/#history
<facubatista> Chipaca, something pushed 2 days ago
<Chipaca> facubatista: try now
<facubatista> Chipaca, don't yank it, really delete it
<facubatista> we don't want anybody try to use it even specifying 0.1.1
<Chipaca> yeah
<Chipaca> i don't understand the thinking behind pypi's workflow
<Chipaca> you can't delete a yanked version
<facubatista> Chipaca, can you un-yank it?
<Chipaca> yes
<Chipaca> but then it'll be the tip again
<facubatista> and then delete it
<facubatista> or just release 0.1.2
<Chipaca> facubatista: actually it looks like i can delete it if i enter the CRUD URL by hand â¦ o\
<Chipaca> done
<vgrevtsev> Chipaca: so actually `_stored` did the magic for some reason, I don't know why
<vgrevtsev> `harness.charm._stored.set_default(is_started=False)` & `harness.charm._stored` worked fine
<facubatista> weeeeee
<facubatista> $ fades -d charmcraft -x charmcraft version
<facubatista> Version: 0.1.0
<vgrevtsev> WELL
<vgrevtsev> no
<Chipaca> vgrevtsev: please file the bug :-)
<vgrevtsev> the same code produces the different results
<vgrevtsev> Yeah I was filing the bug
<facubatista> vgrevtsev, thanks
<Chipaca> vgrevtsev: my brain is way ahead of me WRT this EOW thing
<Chipaca> not that it was a whole lot better before mind you :-)
<vgrevtsev> no worries Chipaca - i'm just sending my thoughts to the channel not expecting anyone of you to answer :)
<Chipaca> facubatista: sorted, then? i can go? :-)
<Chipaca> vgrevtsev: :-) cheers man
<facubatista> Chipaca, let's get drunk
 * facubatista prepares a mate
 * vgrevtsev looks at the clock, 22:15...
<Chipaca> facubatista: actual LOL
<vgrevtsev> who said "beer"?
<Chipaca> vgrevtsev: i think i did
<facubatista> vgrevtsev, \o/
<Chipaca> i've got an IPA for ops, and another for charmcraft
 * Chipaca likes the hoppy stuff
 * Chipaca goes
<Chipaca> facubatista: buen fin de semana! and see you Monday. Not too early.
<facubatista> Chipaca, have a nice weekend, eso
<Chipaca> facubatista: we still need to review your charm :-) but we got the release out so i'm super happy
<Chipaca> now i need to tidy my thoughts and write that status email
<facubatista> :)
<Chipaca> but first, beer, sleep, weekend
<Chipaca> ð
<mup> Issue operator#307 opened: Race condition: RuntimeError: unable to define an event with event_kind that overlaps with an existing type <Created by exceptorr> <https://github.com/canonical/operator/issues/307>
<vgrevtsev> ^ that's me
<Chipaca> vgrevtsev: niiice
 * Chipaca sips his beer
<Chipaca> (no coding after beer is being supped)
<Chipaca> in fact, it might be high time to go play civ
 * vgrevtsev counts time down before The Last of Us Part II release
 * Chipaca wonders if said counting down is done using some form of liquid timekeeping device
<mup> Issue operator#308 opened: have a code of conduct <Created by chipaca> <https://github.com/canonical/operator/issues/308>
<mup> Issue operator#309 opened: KeyError: 'JUJU_MODEL_NAME' while emitting event from Harness <Created by exceptorr> <https://github.com/canonical/operator/issues/309>
<vgrevtsev> :-(
<vgrevtsev> it's me again....
<vgrevtsev> Chipaca: oh yes, indeed, liquid time machine...
<vgrevtsev> you can activate it being near your laptop at 8pm and then suddenly realise it's Sunday 5am already and you're in the middle of nowhere
<vgrevtsev> but it was fun :-D
