#smooth-operator 2020-06-15
<MarkMaglana> jam: thanks for commenting on the Existing Tools section! Very good comments. Helps with thinking about and evaluating possible solutions.
<jam> MarkMaglana, happy to. I think we're also very invested in recommendations for how to get the dependencies into the charm and into the deployment
<jam> MarkMaglana, I should mention that the current plans are looking to have a build step for charms that can be run on a Launchpad build farm (like snaps and debs) so that charms end up series/architecture specific for deployment.
<jam> We've tried to avoid that in Juju for a long time, but it is just a practical matter that charms depend on python extensions
<jam> (even PyYAML uses libyaml)
<jam> note that the charm store and Juju don't currently support looking up charms by series+architecture so a lot of that ends up in 'room for growth'
<MarkMaglana> jam is this build step plan documented anywhere? I'm curious and would like to reference that in my document.
<davigar15> Hey jam!
<davigar15> Ian Booth told me that the issue https://bugs.launchpad.net/juju/+bug/1882127 is fixed in 2.7/edge
<jam> davigar15, well, it now properly reports an error rather than a nil panic, we still need to understand what the underlying error is
<davigar15> jam: okay! great! I will investigate if I have time. Let me know if you find out anything
<davigar15> have a nice day :-)
<jam> davigar15, you too
<Chipaca> good morning people!
<Chipaca> jam: should I tell people to give #323 a try if they're interested in it?
<mup> PR #323: 317 state get <Created by jameinel> <https://github.com/canonical/operator/pull/323>
<jam> It isn't wired up yet, so I still need to do a bit
<jam> morning Chipaca
<Chipaca> jam: ok, i'll just mention it's a WIP and on target for 0.7 then :)
<vgrevtsev> hi jam - any chance you can take a one more look into the https://github.com/canonical/operator/issues/328? Still have no idea what could be wrong :/
<jam> vgrevtsev, is src/charm.py executable and have the right #! line?
<jam> maybe python isn't found at the path you expect inside the application container?
<jam> replied to the bug
<vgrevtsev> jam: yes it's exec-able, the charm itself is running fine
<Chipaca> vgrevtsev: do you get debug logs?
<jam> vgrevtsev, that is running in the operator pod, while the actions run in the application pod
<jam> vgrevtsev, different python
<Chipaca> jam: but the charm ran in the application pod as well, otherwise what created the symlink
<vgrevtsev> jam: yeah but it didn't raise the bad interpreter or smth similar
<jam> Chipaca, juju when it copies the charm directory from the operator pod to the application pod during init
<Chipaca> ahhh
<jam> vgrevtsev, $ ./foo
<jam> bash: ./foo: /bin/ash: bad interpreter: No such file or directory
<jam> that does say "No such file or directory"
<vgrevtsev> but it also says "bad intepreter"
<jam> vgrevtsev, yeah, and there is some sort of python that is trying to exec the script
<vgrevtsev> well wait
<vgrevtsev> i think i found smth
<vgrevtsev> `/bin/sh: /usr/bin/env: not found`
<vgrevtsev> (in the app container)
<vgrevtsev> while my `charm.py` has `#!/usr/bin/env python3`
<Chipaca> hehe
<Chipaca> /usr/bin/env bites again
<Chipaca> (this wrt: people doing '/usr/bin/env bash' to make things more portable --- despite env being in /usr/bin less frequently than bash is)
<Chipaca> s/(?<=than bash is)/ in \/bin/
<vgrevtsev> yeah, and here is another problem: my app container doesn't have python installed :\
<vgrevtsev> so that basically means that I can't run actions against it
<Chipaca> yeah
<jam> vgrevtsev, you can write non-python actions, it depends what you want them to do
<vgrevtsev> true
<vgrevtsev> just wondering why the actions are executed at the app pod but charm itself runs on the operator pod?
<Chipaca> vgrevtsev: I think there's an ongoing conversation about that
<Chipaca> or a few actually?
<Chipaca> seems a lot more work needs to be done still
<Chipaca> mostly juju-side aiui
<jam> vgrevtsev, a lot of it depends on what you want out of an action. many types of actions require running with the appliaction (eg, backup the database)
<Chipaca> BTW, PROMPT_COMMAND='printf "â%$((COLUMNS-1))s\\r"' FTW
<Chipaca> jam: in zookeeper_cluster, am i reading it right that it uses both framework.model.get_relation(...) and framework.relations[...] for the same relation, despite the usage of the first meaning that any checks on the length of the second are spurious?
<Chipaca> because get_relation raises an exception if it's not unique
<jam> Chipaca, meeting?
<Chipaca> jam: another one?
<Chipaca> oh wait
<jam> Chipaca, https://github.com/canonical/operator/pull/327 needs your review
<mup> PR #327: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>
 * Chipaca gets out the red pen
<jam> Chipaca, 'oh wait' ?
<jam> Chipaca, if you can find a way to get your red pen marks online, I'm all for it
<Chipaca> jam: saw your 'meeting?' message _after_ the meeting :)
<Chipaca> stub: filed #329
<mup> Issue #329: dependencies <enhancement> <ð§  big brain> <Created by chipaca> <https://github.com/canonical/operator/issues/329>
<mup> Issue operator#329 opened: dependencies <enhancement> <ð§  big brain> <Created by chipaca> <https://github.com/canonical/operator/issues/329>
<Chipaca> jam: i'd actually gotten half way through reviewing that on Friday
<Chipaca> I lie
<Chipaca> Thursday
<jam> Chipaca, I can imagine it was "I reviewed it but didn't hit send"
<Chipaca> i hadn't gotten to the bottom :)
<mup> Issue operator#223 closed: Operator fails on Juju 2.7.0 and below <bug> <Created by chris-sanders> <Closed by chipaca> <https://github.com/canonical/operator/issues/223>
<mup> PR operator#324 closed: model: don't use --app for relation-get/-set before 2.7.0 <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/324>
<mup> PR operator#326 closed: make abc TestMain private to help pytest <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/326>
 * Chipaca stepping out for 30'
<mup> Issue operator#328 closed: k8s charm throws a "not found" error when invoking the action <Created by exceptorr> <Closed by exceptorr> <https://github.com/canonical/operator/issues/328>
<Chipaca> jam: i'll be along as soon as i've figured out why i have a conflicting meeting
<jam> ok
<jam> Chipaca, so far nobody else is here
 * Chipaca gives up
<Chipaca> slightly early EOD from me
<Chipaca> ttfn! might pop in later, but i'll go run now
#smooth-operator 2020-06-16
<mup> PR operator#330 opened: test/test_main: move actions.yaml into the charm <Created by jameinel> <https://github.com/canonical/operator/pull/330>
<Chipaca> morning all
<MarkMaglana> wazaaaaaaaaaaaaaaaaaaap
<Chipaca> MarkMaglana: snapcraft <3 charmcraft, and/or viceversa
 * Chipaca having fun with that
<MarkMaglana> heh.
<jam> morning Chipaca and MarkMaglana
<jam> Chipaca, operator#330 is an attempt to make it possible to deploy 'test_main' as a real charm
<mup> PR #330: test/test_main: move actions.yaml into the charm <Created by jameinel> <https://github.com/canonical/operator/pull/330>
<jam> also, turns out we weren't cleaning up our TMP garbage correctly.
<Chipaca> yeah i'd been meaning to look into the tmp garbage but there was always something else
<Chipaca> thank you
<lourot> o/ I was trying to create a new charm with the operator framework, inspiring myself from charm-ceph-iscsi and other tutorials, with and without charmcraft. It seems like the behavior of the Operator has changed regarding actions. I've created the most simple hello-world example I could: https://github.com/AurelienLourot/charm-ops-with-action
<lourot> without charmcraft
<lourot> we're coming to the conclusion that I should create the actions/ folder myself to get this to work
<lourot> but it seems like it wasn't need for charm-ceph-iscsi in the past (I had a chat with gnuoy about that)
<lourot> Chipaca, should this work? i.e. are actions.yaml and an observe() supposed to be enough to create an action?
<Chipaca> lourot: yes
<Chipaca> lourot: in what way does this not work?
<lourot> see the readme
<lourot> AttributeError: 'CharmOpsWithAction' object has no attribute 'hello_action'
<Chipaca> lourot: CharmOpsWithAction is your code
<Chipaca> lourot: in has no 'hello_action'
<lourot> oh
<lourot> wow
<Chipaca> lourot: it does have a 'on_hello_action'
<Chipaca> lourot: that might be the thing you want?
<Chipaca> it's just python Â¯\_(ã)_/Â¯ (but also :-D )
<lourot> sorry, I misread the exception, because yesterday I had an exception that self.on was missing hello_action and I was trying to reproduce it with a super simple example
<lourot> so -> pebkac
<lourot> thanks a lot!
<Chipaca> lourot: no problem! i wish they were all this easy to help with :-)
<lourot> Chipaca, ok so now I managed to reproduce the exception I had in mind: https://github.com/AurelienLourot/charm-ops-with-action
<lourot> it seems that I end up in that state only if I use charmcraft
<lourot> gnuoy, icey, fyi ^
<lourot> in the ops code I see that there is a loop iterating on actions and populating methods on CharmEvents
<lourot> but somehow there must be a bit missing in my example
<Chipaca> lourot: does charmcraft copy actions.yaml into the charm?
<lourot> Chipaca, nope indeed. I see you have a PR for copying config.yaml but none yet for actions.yaml
<Chipaca> lourot: yeah, i'll push one for actions.yaml in a bit
<lourot> ah cool
<lourot> thanks!
<Chipaca> i've gotten as far as i'm going to get with snapcraft for now :)
<Chipaca> lourot: sorry :) this comes from not having any real-world tests for its first release into the wild :)
<Chipaca> the charms we did test didn't have config nor actions ð²
<Chipaca> anyhoo, will fix
<Chipaca> grr
<lourot> Chipaca, thanks! does it help you if I create an issue and point to my example? it'll help me at least to point to it for a related change I need to do
<Chipaca> lourot: sure!
<lourot> gnuoy, so I'll create a PR to ops-openstack with a try/catch around observe() for pause/resume - alternatively I could also not use charmcraft for now, what do you think?
<jam> Chipaca, I finally managed the magic invocation to do a bit of performance timing and see that we spend 90% of our test suite time in _simulate_event
<jam> of the 30s it takes for me to run 'test_main': it breaks down as: https://paste.ubuntu.com/p/RmHn6gSwyS/
<jam> so install/start is most of the time.
<Chipaca> lourot: want to try charmcraft from my branch (charmcraft#36)?
<mup> PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/36>
<Chipaca> jam: is that because a lot of tests just run install? or is install beig silly
<jam> Chipaca, I haven't dug past the subprocess barrier yet. My guess is that install does all the 'setup' stuff like creating all the symlinks. I'd like to adjust that with counts as well (eg, we might call install 10x more than the next one)
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: buen dÃ­a!
<facubatista> hola Chipaca!
<Chipaca> facubatista: lourot noticed we also don't ship actions.yaml in the .charm
<Chipaca> so charmcraft#36 fixes that and config.yaml
<mup> PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/36>
<Chipaca> facubatista: it feels bad enough to do a .4 tbh
<Chipaca> .3?
<Chipaca> that
<Chipaca> .9Â¾
<facubatista> Chipaca, what about #31 ?
<mup> PR #31: Remove DeadRelation in favor of empty relations <Created by johnsca> <Merged by niemeyer> <https://github.com/canonical/operator/pull/31>
<facubatista> ugh
<facubatista> Chipaca, what about charmcraft#31 ?
<mup> PR charmcraft#31: Include config.yaml in built charm <Created by charness> <https://github.com/canonical/charmcraft/pull/31>
<Chipaca> facubatista: we're still waiting for the CLA
<Chipaca> facubatista: i made a comment on it
<facubatista> Chipaca, pr46 approved
<Chipaca> woo, approval from the future
<facubatista> 36 I mean
<Chipaca> aw
<lourot> Chipaca, yep, fetching coffee and I'll give it a try, thanks!
<Chipaca> coffee sounds like a good idea
<Chipaca> so does lunch
<lourot> yay, it worked, thanks. commenting on the PR
<jam> Chipaca, charmcraft#36 has a comment from me, there are a couple more files to pull in
<mup> PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/36>
<jam> morning facubatista
<facubatista> hola jam
<jam> Chipaca, facubatista I'd say charmcraft#36 supersedes 31, and since it is done in a different way, doesn't have to worry too much about licensing.
<mup> PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/36>
<Chipaca> jam, facubatista, actually, why aren't we copying everything into the charm? (a refactor for later perhaps)
<jam> Chipaca, I don't know why we wouldn't copy something that someone felt was worthy of including
<facubatista> Chipaca, what do you mean "everything"?
<jam> Chipaca, certainly things like 'files/' that we saw was content the *charm* expected to exist. The ones I mentioned are ones that *juju* will do something with
<Chipaca> the current behaviour flies against what we've said all along, that the result of charmcraft build looks almost exactly like the charm it's built from
<facubatista> Chipaca, you'd put also the .gitignore inside?
<Chipaca> facubatista: I would not, but putting it inside breaks less things than not putting something
<Chipaca> ie our approach is backwards right now, we should be excluding things, not including them
<Chipaca> again, it's a bigger change
<facubatista> Chipaca, you can always include things later; I'm worried about including by default something the user wouldn't want to leave his machine (as in a 'credentials.txt' file)
<Chipaca> if charmcraft#36 is bad enough to trigger a point release, i'd go with that
<mup> PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/36>
<Chipaca> and then later a refactor to change the approach
<facubatista> Chipaca, what we at least need to include is a way for the dev to say "also these files, please"
<facubatista> a kind of... manifest
<Chipaca> jam: WRT 'revision', that one seems weird
<Chipaca> jam: revision means something else in the new APIs
<Chipaca> jam: what does it mean in juju?
<jam> Chipaca, IIRC, revision is meant to be populated by the store, and indicates an official number for the charm
<Chipaca> yeah, but not inside the charm itself
<jam> 'juju deploy mysql-22' is a specific revision of the mysql charm
<jam> Chipaca, I do believe once we get the charm on disk, it has revision with 22 in it
<Chipaca> because the charm's hash is used to sign it
<Chipaca> hmm
<Chipaca> i'll check with store people to see if this is true for charms in the new APIs
<Chipaca> anyway it's not something that'd be there at build time so i'll skip it :
<Chipaca> jam: how hard would it be (and how big would it be) to build a juju that _only_ knew how to do 'juju deploy'?
<jam> Chipaca, so presuming you already had bootstrapped a controller, and you just wanted something that can interact with the API to deploy ?
<Chipaca> jam: yeah
<Chipaca> jam: (wondering if we can do a strictly confined charmcraft that shipped its own juju just for the deploy bit, if and when we get around to that)
<jam> Chipaca, I believe we've prototyped a stripped down Juju, but I don't remember the exact numbers.
<jam> A lot of the overhead of the binary is from bootstrap, IIRC, since it needs to know all the different provider code.
<Chipaca> otoh i hear snapd is working on snaps running snaps, so maybe that'll dtrt
<Chipaca> jam: i was surprised at how big juju-the-binary was fwiw
<Chipaca> anyway, just some idle thoughts
<Chipaca> jam, facubatista, wdyt, should we do a charmcraft 0.1.3?
<facubatista> Chipaca, release often, etc, etc
<facubatista> Chipaca, iow, yes, please
<Chipaca> ikr
<Chipaca> facubatista: you ok with my argument on the pr wrt tests?
<facubatista> Chipaca, if you strict with checking "the wanted behaviour" you should add tests for all those files
<jam> Chipaca, yeah, juju is >100MB uncompressed, IIRC.
<facubatista> Chipaca, what about leaving that test as it is, and adding other one that reflects that we're including (if exists) whatever is in that CHARM_OPTIONAL?
<jam> ah, only 89MB, I think it was bigger at times. (I believe 'make install' supplies the 'strip' flags to go)
<Chipaca> $ ls -sh /snap/juju/current/bin/juju
<Chipaca> 120M /snap/juju/current/bin/juju
<Chipaca> Â¯\_(ã)_/Â¯
<jam> Chipaca, jujuc that only talks to the unit agent socket is only 8.5MB, so it can go down quite a bit.
<jam> Chipaca, hm.
<jam> $ ll /snap/juju/current/bin/juju -h
<jam> -rwxr-xr-x 1 root root 149M Apr 21 07:45 /snap/juju/current/bin/juju*
<mup> PR #21: Persist stored state before framework commit <Created by dshcherb> <Merged by niemeyer> <https://github.com/canonical/operator/pull/21>
<jam> but $ ll ~/dev/go/bin/juju -h
<jam> -rwxrwxr-x 1 jameinel jameinel 89M Jun 11 12:52 /home/jameinel/dev/go/bin/juju*
<facubatista> Chipaca, your "I don't like the 'charmcraft: error: invalid choice: thing" comment, is feedback for Lilyana, or shall we open an issue in the project about it?
<Chipaca> jam: snap info juju | yq r - tracking
<Chipaca> jam: maybe the snap is not stripping the binary?
<Chipaca> it says 'not stripped' here :-\
<Chipaca> anyhoo
<Chipaca> coffee
<Chipaca> then meetings
<jam> Chipaca, https://bugs.launchpad.net/juju/+bug/1883703
<jam> Chipaca, so 'go install' without the strip flags is 120MB and 'make go-install' with them is 89MB.
<jam> so it does seem like our snap build is broken.
<jam> I wonder if we switched to using the snap plugin to build, which doesn't run the extra magic strip flags.
<Chipaca> i wonder if snapd-the-snap could also benefit from the extra magic strip flags =)
<Chipaca> snapd in the snap says 'stripped' though Â¯\_(ã)_/Â¯
<jam> Chipaca, https://github.com/juju/juju/blob/develop/snap/snapcraft.yaml looks like we have a 'juju-go' plugin because the snapcraft one doesn't allow us to do everything.
<Chipaca> facubatista: you comng?
<Chipaca> facubatista: i
<facubatista> yes
<Chipaca> jam: now all you need to do is push everything onto the stack, and then treat it as a queue, right?
<Chipaca> or was it the other way around
<facubatista> Chipaca, jam, we could do the standup right now, and have some minutes between that and the next meeting...
<jam> Chipaca, don't you put it all on the stack and then throw the stack in the circular file?
<Chipaca> facubatista: works for me
<Chipaca> jam: me? i put everything in the stack, and then kill the process
<Chipaca> *cheff kiss* works every time
<jam> Chipaca, facubatista wfm
<facubatista> going in...
<Chipaca> facundo__, jam, added a test to charmcraft#36, hope it's what we agreed on :)
<mup> PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/36>
<facundo__> Chipaca, I use simple 'patch' for that kind of patching, but it's fine for me
<Chipaca> jam: how do i trigger that charmdir build-a-zip code from juju?
<jam> Chipaca, IIRC, 'juju deploy ./directory' will build and upload a .zip to the controller, but I don't know of a way to just get the .zip
<jam> Chipaca, coming to prep?
<Chipaca> y
<Chipaca> facundo__, jam, thanks
<Chipaca> facundo__, jam, I'll be merging charmcraft#36 and releasing 0.1.3 in half an hour unles you holler to the contrary
<mup> PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml <Created by chipaca> <https://github.com/canonical/charmcraft/pull/36>
<facundo__> Chipaca, go, go
<lourot> thanks for the quick reaction/implementation today! (re: #36)
<mup> PR #36: Refactor how relation endpoint and storage events are handled <Created by johnsca> <Closed by johnsca> <https://github.com/canonical/operator/pull/36>
<Chipaca> lourot: thank you for using our stuff, and reaching out when it didn't work, *and* testing the fix :-D
<Chipaca> facundo__: should the release now also include the code of conduct?
<Chipaca> as in, should i add it to the manifest
<facundo__> Chipaca, do we have it?
<facubatista> ah, yes
<facubatista> Chipaca, yes, any specific file must go in the MANIFEST to be included
<Chipaca> facundo__:  i guess what i'm asking is whether to include it or not :)
<facundo__> Chipaca, if we have other text in the README or something about "how to collaborate with the project", we should mention the CoC and include it
<Chipaca> facubatista: we do not yet reference the one from t'other
<Chipaca> facubatista, facundo__, i've just noticed that charmcraft is not including tests in the releases
<Chipaca> in the wheel that seems alright, but not so much in the sdist
<Chipaca> but i'd have to check other projects to know if this is normal/right/accepted practice
<Chipaca> anyway this one'll go out like the previous
<Chipaca> facundo__: charmcraft#38 plz
<mup> PR charmcraft#38: bump version for 0.1.3 <Created by chipaca> <https://github.com/canonical/charmcraft/pull/38>
<facundo__> Chipaca, approved
* ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.6.1 || charmcraft 0.1.3
<Chipaca> lourot: should work now
 * facundo__ eods
<Chipaca> yeah, eod sounds nice
#smooth-operator 2020-06-17
<mup> PR operator#327 closed: many: move Model.name to be read from _ModelBackend <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/327>
<mup> PR operator#330 closed: test/test_main: move actions.yaml into the charm <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/330>
<mup> PR operator#331 opened: test/test_model.py: racing tests <Created by jameinel> <https://github.com/canonical/operator/pull/331>
<Chipaca> moin moin
<jam> morning Chipaca
<Chipaca> jam: how's things?
<jam> Chipaca, doing ok. I joined mattermost at https://chat.canonical.com
<jam> Hopefully you've seen the emails
<jam> had a couple hiccups this morning. my VM had crashed, so I hopefully recovered a fresh one
<mup> PR operator#325 closed: ops/main.py: Use CSafeLoader <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/325>
<jam> Chipaca, we also had a 'bug' in our landing process. I was able to land my Model.name patch, but it actually broke the test suite on master
<jam> (the tests passed on my branch, and on your branch that you landed, my batch removed an import that your patch started using)
<jam> I fixed in in the next PR that I just landed, but we should
<jam> think about if we want to change anything.
<Chipaca> yeah, that race exists
<Chipaca> at some point it'll be worth it to serialise commits with a bot
<jam> Chipaca, I think you can set the github flag "PRs must include master tip" before landing
<jam> it causes humans to serialize, but means you at least don't have the race
<Chipaca> ah, that i can do
<mup> PR operator#331 closed: test/test_model.py: racing tests <Created by jameinel> <Closed by jameinel> <https://github.com/canonical/operator/pull/331>
<Chipaca> jam: done
<jam> time to cover up your hanging lamps: https://www.schneier.com/blog/archives/2020/06/eavesdropping_o_9.html
<jam> "passively look at the lightbulb of a hanging lamp" and can recreate speech/music playing inside
<jam> https://www.nassiben.com/lamphone
<jam> measured from 25 meters away
<Chipaca> hah, joke's on them, i can't afford lamps
<facubatista> stes:helo:
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð!
<facubatista> Chipaca, hola!
<facubatista> Chipaca, what pip does wrt vendoring?
<Chipaca> facubatista: it grabs all the wheels it needs and plops them down somewhere
<Chipaca> facubatista: then when you import _vendor it loads all the wheels
<Chipaca> takes a couple of seconds here
 * facubatista -> kids' school (virtual) meeting
<davigar15> Hello, where should I ask reactive related questions? There's a guy at Telefonica that has a reactive charm with an action. At the top of the action, he is putting this: `log("Executing action"`. log is imported `from charmhelpers.core.hookenv import log`. For whatever reason, he cannot see the log in `juju debug-log`
<davigar15> any ideas?
<jam> davigar15, I would probably ask in #juju
<jam> davigar15, aside from that I would consider "juju model-config logging-config" to figure out if the default log level is omitting his messages
<jam> Chipaca, interesting yak to dig into. pip install pytoml, which is now deprecated in favor of 'toml'
<stub> You use pip to build wheels, which you vendor. You can then tell pip to install wheelhouse/*.whl
<Chipaca> stub: pip itself does something funkier with them though
 * facubatista is back
<mup> Issue operator#332 opened: Model.config is mutable <Created by jameinel> <https://github.com/canonical/operator/issues/332>
 * Chipaca takes a break
#smooth-operator 2020-06-18
<mthaddon> jam: you may be interested in https://code.launchpad.net/~pjdc/charm-k8s-mattermost/+git/charm-k8s-mattermost/+merge/385953 - just looking over it now myself
<jam> mthaddon, thanks for the heads up
<mthaddon> jam: have just asked for some updates - I noticed the test pod spec structure is a bit different from what we're actually defining in the charm
<Chipaca> ð
<jam> heh
<jam> so it actually was something different than I thought
<jam> Chipaca, https://paste.ubuntu.com/p/4RKzm4PW5h/
<jam> so I noticed that if I did: foo: "bar: 42" | state-set --file -
<jam> then when I did 'state-get'
<jam> It would say:
<jam> foo: "bar: 42"
<jam> but if I did
<jam> foo: |\n  bar: 42 | state-set -file -
<jam> then the output would be
<jam> foo: |
<jam>   bar: 42
<jam> However, that is because those 2 strings are subtly different, can you tell why?
<Chipaca> jam: newline?
<jam> Chipaca, yep '|' includes a trailing newline '|-' and the one-line form do not
<Chipaca> phew
<Chipaca> if it wasn't that, it was cursed :-)
<jam> Chipaca, you can see the output of 'state-get foo' was 'bar: 42\n\n'
<jam> I thought it was somehow remembering how I set the value and preserving it, which didn't really make sense
<Chipaca> bar: 12\n\n i guess?
<Chipaca> i believe preserving layout was one of the goals of gustavo's yaml.v3, but i'm not 100% positive on that (nor on whether he achieved it)
<Chipaca> i never got to play with that, actually
<Chipaca> still on my ToDo
<jam> Chipaca, that is as go not python, though, right?
<jam> and not a YAML spec but just a parser quirk?
<Chipaca> correct
<jam> Chipaca, do we think it is a problem if we treat foo='' as NoSnapshot ?
<Chipaca> and maybe it wasn't layout but comments?
<jam> It is fine as long as your snapshot isn't just a string that can be empty
<jam> (we could enforce snapshots are dicts again :)
<jam> Chipaca, or I could do the "if we get '' read the whole state-get and see whether the key exists"
<Chipaca> so this is only a problem for a snapshot that serialises as a string, and only if it cares about the difference between a string and not being there
<Chipaca> right?
<Chipaca> snapshot returns a simple serialisable object and the ones writing it out into yaml is us, right?
<Chipaca> so what we could do, if the above is right, is !!str strings
<jam> Chipaca, actually, it isn't a problem, because we yaml.dump('') => "''\n"
<Chipaca> and then we know because we get '' vs '!!str ""'
<jam> yaml.load('') => None, but yaml.lod("''\n") => ''
<Chipaca> ahhhh
<Chipaca> also aaaaah *and* ahahaha
<Chipaca> jam: cool cool, then :)
<jam> Chipaca, I'll make sure to add '' to my permutation tests
<jam> hm. seems I also need to handle None
<jam> >>> print(yaml.dump(None))
<jam> null
<jam> ...
<jam> yaml.safe_load('') => None, yaml.safe_load('null\n...\n') => None
<jam> Chipaca, and, of course, I'm simulating some of this via my own scripts, which is definitely stuff that I'd want to test against actual Juju
<Chipaca> jam: do we have a list of 'things we want to try in real jujus tee emm'? (should we?)
<jam> Chipaca, well, I consider that writing a 'juju test suite' as part of test-main was one of my goals of this PR
<Chipaca> facundo__: 'charmcraft --verbose build' not being exactly the same as 'charmcraft build --verbose' is surprising and painful
<jam> but we can split it out if we prefer
<Chipaca> jam: i hadn't realised that, is there any of this already up? (how were you approaching it?)
<Chipaca> s/were/are/
<jam> Chipaca, that was part of my trying to make test-main be a RealCharm
<jam> but it isn't something I've actively started
<jam> Chipaca, my intent was to add an action to test_main, such that you could run "juju deploy test_main; juju run-action ops-tests"
<Chipaca> jam: given you can make travis install snaps, and in particular lxd snaps, i was hoping we'd be able to use that to run tests
<jam> Chipaca, snap install lxd; snap install --classic juju; juju bootstrap lxd; juju deploy; juju run-action
<jam> Chipaca, I don't expect it to be very fast (bootstrap lxd here is a minute or so)
<Chipaca> jam: i was thinking of looking at having it as a cron test rather than unit tests unless we got them to be faster than i expect them to be, though
<Chipaca> yeah
<Chipaca> i mean, up to ~5 minutes is probably fine for PR tests
<Chipaca> longer than that and i'd punt them to cron / manual
<Chipaca> heh, https://github.com/juju-solutions/charms.reactive/blob/master/.travis.yml
<Chipaca> and a job run: https://travis-ci.org/github/juju-solutions/charms.reactive/jobs/675789700
<Chipaca> (somebody needs to tweak that travis, but it essentially seems to work?)
<Chipaca> anyhoo
<jam> Chipaca, "ran for 2min43s" isn't bad
<jam> apt install snapd pwgen is 80s of it
<Chipaca> jam: "didn't actually *run* run" kinda is tho =)
<jam> yeah, I see that now
<Chipaca> i mean, juju bootstrap fell over
<jam> It is doing the usermod, but not doing the newgrp so the active process knows it is in the group
<Chipaca> hopefully it's that and not some weird apparmor-inside-apparmor-inside-apparmor thing
<Chipaca> (travis already runs inside lxd in some situations)
<Chipaca> (i think it's when you're doing weird arches, and then it's in vms and not containers, but still)
<jam> Chipaca, ah right, they recently switched so amd64 can be run in a container
<jam> Chipaca, the actual failure is that it can't talk to the lxd socket, but that might be because lxd failed to start?
<jam> Chipaca, do you have any quick magic for timing what is taking long in a test run?
<jam> I've gotten some stuff to work with cProfile, etc, but it is always a bit clumsier than I would expect
<Chipaca> jam: i've monkeypatched the test constructors to track time
<Chipaca> jam: otoh pytest i think has things for that?
<Chipaca> let me see if i still have the monkey patching thing somewhere
<Chipaca> jam: pytest --durations=10 will print the 10 slowest tests
<jam> Chipaca, yeah, pytest-profiling sems to get me where I'd like to be
<jam>  py.test test/test_storage.py::TestJujuStorage::test_emit_event --profile
<jam> gives me a cumulative time spent
<Chipaca> jam: --durations gives you something like
<Chipaca> 2.24s call     test/test_main.py::TestMainWithNoDispatchButJujuIsDispatchAware::test_multiple_events_handled
<Chipaca> 2.21s call     test/test_main.py::TestMainWithNoDispatch::test_setup_event_links
<Chipaca> etc
<Chipaca> jam: also, pip install pytest-xdist  and then  pytest -n $(nproc)
<jam> Chipaca, sure. The issue is that I know one test is running slow, and I'm trying to figure out why
<Chipaca> ahh
<Chipaca> you want timings _inside_ the test?
<Chipaca> that i don't have
<jam> Chipaca, yeah. Which --profiling gives me. the issue is that one of my tests with SQLite backend is about 3ms, and with Juju backend it is about 600ms
<jam> I'd like to understand why :)
<Chipaca> jam: did you set SSH_TO_THUMPERS_BOX=0 ?
<Chipaca> 600ms is enough time to do that and more â¦ :)
<Chipaca> jam: what happens if you set PYTHONVERBOSE in the environ?
<jam> 376ms spent in subprocess.communicate, 376ms spent in wait()
<jam> stupid process barriers
<jam> Chipaca, PYTHONVERBOSE is a bit... verbose? :)
<jam> Chipaca, stripping it down to a single emit() shows it as 200ms, https://paste.ubuntu.com/p/XY7dmtXNxv/
<Chipaca> jam: is something reading stdin/stdout with it being buffered on a timeout?
<jam> Chipaca, it is about 20m-30ms per subprocess invocation, we just do a lot of them for each emit()
<jam> Chipaca, $ time python3 -c ''
<jam> real    0m0.015s
<Chipaca> :-(
<Chipaca> jam: try -Sc
<jam> goes down to 7ms
<Chipaca> (not practical irl but good to know how low we could take it with some environ handholding)
<jam> Chipaca, gives "No module named 'yaml'" if I try it in the script
<Chipaca> yeah, as i say, not practical :)
<Chipaca> it comes up with a very empty pythonpath, for one
<jam> Chipaca, it works for the ones that don't need yaml, though
<jam> but that only shaves ~10ms off the test time
<Chipaca> jam: what are all the calls the reemit does?
<jam> so emit() calls _emit(), which does a 'save_snapshot()' for the event, then 'save_notice()' for each observer.
<Chipaca> and each of those is a save-set
<jam> then _reemit calls 'read all notices', and for each one it will then call load_snapshot and possibly drop_snapshot/drop_notice
<Chipaca> jam: right
<Chipaca> jam: sounds to me like we want to consider refactoring things to at least save in a batch
<Chipaca> but later
<Chipaca> i mean, let's not block save-set on this :)
<jam> so I think in practice it won't be as bad, 'juju run 'time state-get' is 5ms vs 20ms
<Chipaca> but let's not call save-set *done* without looking at it
<jam> but it is still a lot slower than interacting with an in-process SQLite file
 * Chipaca reaches for his 'shocked pikachu' face again
<jam> Chipaca, ð²
<Chipaca> :-) that's the on
<jam> ð±
<Chipaca> nah that's the dog :-p
<jam> Chipaca, I do think given how much the Operator framework is based around events, we'll want to be cautious about its performance
<Chipaca> (somebody pointed it 'the scream' kinda looks like the guy tried to draw a dog and then somebody said 'oh wow a person screaming' and they went with it)
<jam> https://emojipedia.org/face-screaming-in-fear/ I'm not seeing the dog
<jam> nor here: https://www.bookdepository.com/Edvard-Munch-Masterpieces-of-Art-Candice-Russell/9781783613564?redirected=true&utm_medium=Google&utm_campaign=Base3&utm_source=AE&utm_content=Edvard-Munch-Masterpieces-of-Art&selectCurrency=AED&w=AFCFAU968L892MA8VCPZ&gclid=Cj0KCQjwoaz3BRDnARIsAF1RfLeKR4-ljbzhpZgajGSi2f4h-DLQp_FaX-dDHKqVeiWmSi23iue6HVAaAlf2EALw_wcB
<jam> Chipaca, ah, the hands are the ears
<Chipaca> there you go :)
<Chipaca> once you see it it's easy to flip-flop
<jam> if you get rid of the nose and mouth, then I can see the dog nose, but I don't see how they fit on the dog face
<jam> not as good a flip/flop as https://www.independent.co.uk/news/science/duck-or-rabbit-the-100-year-old-optical-illusion-that-tells-you-how-creative-you-are-a6873106.html
<jam> duck bunny
<Chipaca> the duck/bunny one is very good (i first saw it on a joke)
<Chipaca> anyway. pop.
<Chipaca> facundo__: so, wrt charmcraft and secrets, i think a reasonable approach is to use keyring and have the snap ask for the secrets plug; it won't auto-connect, but we can detect the failure in code and fall back to plaintext (or notify the user to manually connect or pass --plaintext?)
<Chipaca> the token isn't a general-purpose do-anything token fwiw, which is why storing it plaintext isn't _that_ bad an idea
<jam> 'time python3 -c import yaml' is 30ms here.. :(
<Chipaca> 0.05user 0.00system 0:00.06elapsed 98%CPU (0avgtext+0avgdata 11216maxresident)k
<jam> 50-60ms ?
<Chipaca> yep
<Chipaca> and 11MB
<facundo__> Muy buenos dÃ­as a todos!
<Chipaca> jam: of course that's slower in great part because my cpu aggressively freqs down; if i pin it hot it drops to 30ms
<Chipaca> and if i were to enable 'turbo' mode it'd probably drop another ~5ms
<Chipaca> but i don't like my fans being on loud all the time =)
<Chipaca> facubatista: muyy buen dÃ­a su seÃ±orÃ­a mantantirulirulÃ¡
<facubatista> Chipaca, supercalifragilÃ­sticoespialidosas maÃ±anas!
<jam> Chipaca, thinking about Ajduk... It came to light that Operators can trigger an action to be run, which means the Operator charm *should* be able to cause a script to run in the application container
<jam> Chipaca, https://discourse.juju.is/t/coordinating-actions-for-a-k8s-operators/3161/2
<jam> Chipaca, I added a comment to the doc
<facubatista> Chipaca, https://github.com/canonical/charmcraft/issues/42
<jam> Chipaca, facubatista : all wired up! turns out we aren't very good at cleaning up after ourselves:
<jam> $ juju run --unit uo/2 'state-get'
<jam> '#notices#': |
<jam>   []
<jam> StoredStateData[_stored]: |
<jam>   {event_count: 12}
<jam> Ubuntu/on/config_changed[7]: |
<jam>   null
<jam>   ...
<jam> Ubuntu/on/install[1]: |
<jam>   null
<jam>   ...
<jam> Ubuntu/on/leader_elected[4]: |
<jam>   null
<jam>   ...
<jam> on/commit[3]: |
<jam>   null
<jam>   ...
<jam> on/commit[6]: |
<jam>   null
<jam>   ...
<jam> on/commit[9]: |
<jam>   null
<jam>   ...
<jam> on/commit[12]: |
<jam>   null
<jam>   ...
<jam> on/pre_commit[2]: |
<jam>   null
<jam>   ...
<jam> on/pre_commit[5]: |
<jam>   null
<jam>   ...
<jam> on/pre_commit[8]: |
<jam>   null
<jam>   ...
<jam> on/pre_commit[11]: |
<jam>   null
<jam> https://paste.ubuntu.com/p/NWZy54VMk4/
<jam> (didn't mean to paste the content here)
<facubatista> :)
<Chipaca> i'll be 10 minutes late for the revue
<Chipaca> (small lunch chaos here)
<jam> Chipaca, facubatista so the bug is that events that have no handlers are always treated as deferred
<facubatista> oh
 * facubatista plans the meeting for 10' past normal time
<Chipaca> jam: that's a nasty bug :-|
<facubatista> Chipaca, https://discourse.juju.is/t/how-to-build-a-charm-using-modern-tools/3246
<mup> Issue operator#333 opened: Events with no observers never get deleted <Created by jameinel> <https://github.com/canonical/operator/issues/333>
<Chipaca> what's the generic name for what 'juju deploy' deploys to?
<facubatista> Chipaca, the "backing cloud"?
<Chipaca> facubatista: hmm
<Chipaca> facubatista: in the end i rewrote the sentence to not need it, fwiw
<Chipaca> facubatista: https://discourse.juju.is/t/what-files-would-you-expect-charmcraft-build-copies-into-the-charm/3247
<Chipaca> stub: mthaddon: ^ if you have opinions on it please speak up :)
<mthaddon> ack, will try and take a look soon
<mup> PR operator#334 opened: Unobserved events <Created by jameinel> <https://github.com/canonical/operator/pull/334>
<jam> Chipaca, PRs should be up for review
<jam> facubatista, review of charmcraft is up
<facubatista> jam, thanks
<Chipaca> jam: which are the python implementations of state-set that are slow? where can i play with that?
<Chipaca> s/set/[sg]et/ fwiw
<facubatista> jam, what do you mean with "make it contextual"?
<Chipaca> facubatista: pass it around either explicitly or implicity, i think
<facubatista> it could be done
<facubatista> I like it how it's now, though, as it should be an omnipresent object, the only interaction with the module, etc
<jam> Chipaca, https://github.com/canonical/operator/pull/323/files#diff-54d96dff01765335f1f08f6254aa0de6R197-R250 is the python backend
<mup> PR #323: 317 state get <Created by jameinel> <https://github.com/canonical/operator/pull/323>
<jam> facubatista, yeah, the idea was 'is it worth passing one around' rather than being used as a process global
<Chipaca> heh, silly me was looking for #! :)
<jam> Chipaca, yeah, the #! is fixed to be bash by fake_script
<mup> PR operator#335 opened: make tests 15% faster <Created by chipaca> <https://github.com/canonical/operator/pull/335>
<Chipaca> :-D
<Chipaca> tomorrow is RTD DAY \o/
<Chipaca> ok, i think i'm at eod, mostly
<Chipaca> facubatista: i'm still hoping to finish the review on charmcraft#33 tonight though
<mup> PR charmcraft#33: Refactored all the message sending to the user, including storing everything in a file <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/33>
<Chipaca> but that'll depend on external factors :)
<facubatista> Chipaca, tomorrow is fine, too
<mup> PR operator#335 closed: make tests 15% faster <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/335>
#smooth-operator 2020-06-19
<Chipaca> hmm, github 500ing
<Chipaca> good morning all!
<MarkMaglana> i think it has something to do with that second octocat overtightening that nut: https://www.githubstatus.com/
<MarkMaglana> i could be wrong though
<Chipaca> MarkMaglana: possibly related to a small github project being on frontpage of newsie
<facubatista> Muy buenos dÃ­as a todos!
<facubatista> Chipaca, which project?
<Chipaca> facubatista: https://github.com/dabeaz-course/practical-python
<facubatista> gracias
 * facubatista brb
<MarkMaglana> Chipaca: I'm going to go with that second octocat.
 * Chipaca sets the octocat on fire
<Chipaca> MarkMaglana: and now?
 * Chipaca forgot to not be evil
<MarkMaglana> See. Now Github is OK for me again.
<Chipaca> now you know their secret
<facubatista> Chipaca, may you take a look (as in "initial light review") at https://github.com/canonical/charmcraft/pull/43 before our standup today? thanks!
<mup> PR charmcraft#43: First draft of interaction to the store <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/43>
<Chipaca> facubatista: i may :)
<facubatista> i june!
<facubatista> thanks
<facubatista> Chipaca, LWP crashed when trying to save the credentials :/
<facubatista>   File "/usr/lib/python3.6/http/cookiejar.py", line 1846, in lwp_cookie_str
<facubatista>     keys = sorted(cookie._rest.keys())
<facubatista> AttributeError: 'NoneType' object has no attribute 'keys'
<Chipaca> welp :)
<Chipaca> that answers that question i guess
<Chipaca> uff, that thing pulls in protobuf :-(
<Chipaca> and pynacl
<facubatista> Chipaca, nice things to know to avoid taking the "let's rewrite this" path
<Chipaca> gah, why am i looking at macaroonbakery code instead of at yours :-(
<Chipaca> facubatista: fwiw, wrt cookie jars, do you have the full traceback? i'm curious
<facubatista> Chipaca, https://paste.ubuntu.com/p/YKvgpzftsm/
<Chipaca> facubatista: charmcraft#33 needs a master merge and then it can land
<mup> PR charmcraft#33: Refactored all the message sending to the user, including storing everything in a file <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/33>
<facubatista> Chipaca, thanks!
<Chipaca> facubatista: a reminder that I'd really like you to not use branches on the project itself for development
<facubatista> Chipaca, ah, we forgot to talk about it
<facubatista> Chipaca, I mean, why? it's simpler
<Chipaca> facubatista: it's untidy, and it dirties the project itself, meaning anybody cloning the project also pulls 'your' branches
<facubatista> Chipaca, we could delete those old branches...
<Chipaca> facubatista: and when we start having release branches it'll make them harder to find
<Chipaca> ('release branches' here i mean 'we need to cut 0.8.3 but just for this cherry-picked thing, not all of 0.9')
<facubatista> yeap
<Chipaca> for now we've been lucky in that all releases have just been master, but that'll not last :)
<facubatista> ok
<Chipaca> facubatista: i'd be interested to know what aspect of your workflow is harder because of this though, as locally it's no harder
<Chipaca> maybe there's some extra configuration i do without thinking at this point?
<facubatista> Chipaca, I always considered "forks" to be something to be done when you didn't own the project
<facubatista> Chipaca, if the 99.9% of the branches come from a 2-4 people, just use the project's repository
<Chipaca> facubatista: that seems like an arbitrary us-vs-them thing to me
<Chipaca> anyhoo, i need to step out for a bit, need to get the boys over to their mum's
<Chipaca> facubatista: also having it in branches fires a lot more traviseses
<Chipaca> (that one we can fix -- but we haven't)
<Chipaca> facubatista: i merged master into 33 and it's good to go, but i'll let you merge it
<facubatista> Chipaca, landed, thanks
<Chipaca> i'm going for a run
<Chipaca> facubatista: have a great weekend!
<facubatista> Chipaca, thanks! same for you
<facubatista> Chipaca, ajÃ¡! it looks some stuff from private internal modules are also exposed in the main module, publicly
<facubatista> Chipaca, this doesn't look so bad, now
<facubatista> and this is why documentation is important :p
 * facubatista eods and eows!
<facubatista> see you all on Monday
