#smooth-operator 2020-08-03
<Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
* ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.7.0 || charmcraft 0.3.0
<Chipaca> brb, dog's whining about something
<jam> morning Chipaca
<Chipaca> jam: you should now be able to ask chanserv to change the channel topic (and other fun stuff)
<jam> Chipaca, I can feel the power....
<Chipaca> jam: that heady feeling of being able to kickban people
<facubatista> Â¡Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð!
<facubatista> hola Chipaca!
<jam> Chipaca, question about Harness. While I'm adding support for auto triggering relations. There is a question for Peer relations.
<jam> Currently with Harness, you have to call 'add_relation' even for peer relations that 'always exist'.
<jam> I'd like for begin_with_hooks to do so automatically
<jam> but should we also do so for just begin()? IMO it makes it harder to figure out when the associated hook would fire, etc.
<Chipaca> jam: that seems in line with the difference between begin and begin_with_hooks
<jam> Chipaca, chans-erv seems to have issues with facu :)
<Chipaca> jam: the first two are me being lazy with flags (it's easier to +* and then deop than figure out the right invocation to do it in one pass)
<facubatista> jam, we're setting it up
<Chipaca> jam: i'm guessing the second is facu poking around :-)
<jam> morning facubatista
<Chipaca> jam: by 'in line' i mean, 'begin' should continue being barebones, so you can poke at things without everything else happening
<jam> Chipaca, yeah, that's how I read it. SGTM
<Chipaca> jam: and begin_with_hooks can be the 'what does it look like in the middle of an actual run'
<Chipaca> bthomas: ð
<bthomas> thanks Chipaca
<Chipaca> facubatista: there's a bug with the charmcraft release you did :-/
<Chipaca> facubatista: and with the HOWTO i guess
<Chipaca> facubatista: you're building locally, meaning you only build for amd64
<Chipaca> facubatista: so charmcraft 0.3 is only out for amd64, any other arch gets 0.2
<Chipaca> facubatista: 'snapcraft remote' should probably be in there :-|
<Chipaca> remote-build*
<facubatista> Chipaca, let me see
<facubatista> Chipaca, ah, yes, there's even a FIXME in the howto: # FIXME: what about other archs
<Chipaca> facubatista: 'snapcraft remote-build' :-)
<Chipaca> facubatista: although right now you could just promote edge to beta
<Chipaca> i've just built 0.3.0 from github master
<facubatista> the remote-build is currently working
<facubatista> Chipaca, let's HO?
<Chipaca> facubatista: in 5?
<facubatista> deal
<jam> Chipaca, facubatista : for 'Harness.begin_with_initial_hooks()'. Juju doesn't guarantee the order of firing hooks if you have more than 1 relation hook (I confirmed in the code that it iterates a map, which is not a stable ordering)
<jam> for *testing* it seems it would be easier to write assertions if you had a stable ordering
<jam> but I don't really want code written that assumes a stable ordering
<jam> Chipaca, thoughts?
<jam> should Harness emit events in a stable ordering to make testing easier, or intentionally unstable to avoid code that assumes the order
<facubatista> even firing in random order in the testing harness will not make that clear
<facubatista> if it passes, people may assume it's ordered, even if we trigger them at random
<Chipaca> jam: let them be ordered or however is easiest to implement in python for the harness, but if you have more than one relation hook issue a warning from _with_hooks?
<jam> Chipaca, but it isn't wrong to have a relation to DB and a peer relation
<jam> Juju just doesn't guarantee whether peer-relation-created or db-relation-created will be fired first
<Chipaca> jam: the warning would just be about the order of events
<jam> Chipaca, so it is easiest in the Harness to just iterate a map, which will also be 'unordered'
<Chipaca> jam: in python maps aren't unordered though, since 3.6
<Chipaca> jam: ask bthomas :-)
<jam> Chipaca, I wonder if that introduces faults vs the old mechanism to avoid poisoned data
<bthomas> :-) yep that bit me
<jam> Chipaca, django used to have a security bug where the Query parameters were put into a dict
<jam> and you could reverse engineer the dict ordering to make it collide.
<jam> I guess if the hash index is still random at startup the iteration order can be stable but you can't force collisions on the hash table
<facubatista> Chipaca, I did all the releases, and improved the text here: https://github.com/canonical/charmcraft/pull/101
<mup> PR charmcraft#101: Release 0.3.0 <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/101>
 * facubatista -> lunch
 * facubatista is back
<Chipaca> facubatista: ð
<Chipaca> facubatista: can you look at https://github.com/chipaca/ops-lib-k8s/pull/2/files and tell me if the _path thing is clear and readable, or if I should add an explanatory comment, or change the approach entirely?
<mup> PR chipaca/ops-lib-k8s#2: lots of small tweaks and cleanup <Created by chipaca> <https://github.com/chipaca/ops-lib-k8s/pull/2>
<facubatista> will do
<mup> PR operator#364 opened: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <https://github.com/canonical/operator/pull/364>
<jam> facubatista, Chipaca : I'm definitely way past EOD, but ^^ is up. I'm happy to bikeshed on the name of the functiona
<jam> and if we look at that test and say "no we really should give a stable order" then we can fix it
<jam> but it does what I wanted.
<facubatista> jam, awesome, thanks
<jesseleo> Hello facubatista I'm still running into the error of adding a resource to my test harness
<jesseleo> facubatista https://paste.ubuntu.com/p/MJd3cDKfxG/
<Chipaca> jesseleo: what version of ops are you using?
<Chipaca> jesseleo: because the version with add_resource was added in #359 which has not been released yet
<mup> PR #359: ops/testing.py: Harness.add_resource <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/359>
<Chipaca> jesseleo: so unless you're runing with master, that error is expected
<jesseleo> yeah I have this in my requirements git+https://github.com/canonical/operator.git@master
<Chipaca> jesseleo: to answer the 'what version' question, just add "raise Exception(ops.__version__)" to the top of yor test method
<Chipaca> it should give you something like 0.7.0+8.g<hex>
<Chipaca> to be more precise, master is 0.7.0+6g169794c right now
<Chipaca> jesseleo: what I imagine might be happening is that your test environment has a different ops version and you need to update/upgrade/refresh it
<Chipaca> thus my suggestion
<jesseleo> oh yes I see I did have ops installed at the system level and wasn't activating my virtual env Chipaca facubatista
<jesseleo> everything looks good now
<jesseleo> thanks for being so responsive
<Chipaca> jesseleo: glad we got it working!
 * Chipaca EODs
<Chipaca> ð
<facubatista> jesseleo, as a general rule, I don't ever never do "sudo pip install", as at some point always confuse things
 * facubatista eods
#smooth-operator 2020-08-04
<mup> Issue operator#286 closed: charms/test_main should not use Pickle <Created by jameinel> <Closed by jameinel> <https://github.com/canonical/operator/issues/286>
<mup> PR operator#363 closed: 0.8 test charm no pickle <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/363>
<Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
<jam> morning Chipaca
<Chipaca> jam: ð how's things?
<jam> Chipaca, going pretty well. I still need your review on operator#364
<mup> PR #364: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <https://github.com/canonical/operator/pull/364>
<jam> Chipaca, I'll probably miss the standup today, I have a conflicting meeting
<Chipaca> ack
<jam> Chipaca, how's it with you?
<Chipaca> jam: needing more coffee :)
 * Chipaca has more coffee now
<Chipaca> jam: instead of diving into preconditions, i've been tinkering with ops-lib-k8s
<Chipaca> still haven't touched the tests though
<mup> Issue operator#237 closed: Feature request: Harness helper function/flag to run initial hooks as juju would execute? <enhancement> <Created by Vultaire> <Closed by jameinel> <https://github.com/canonical/operator/issues/237>
<mup> PR operator#364 closed: ops/testing.py: Harness.begin_with_initial_hooks() <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/364>
<jam> Chipaca, ah nice. I don't think I gave much feedback on that one, I should
<Chipaca> jam: latest pr sets things up for them to work with opslib because design was wanting a real-world example of what a non-interface component looked like
<gnuoy> Chipaca, I'm in the process of updating charmcraft issue 104. Would I be right in saying that for charms running in Juju <2.8 the operator framework needs to create the hook symlinks when the install hook runs ?
<mup> Issue #104: Symlink for `hooks/upgrade-charm` is not created when missing <Created by evhan> <Closed by jameinel> <https://github.com/canonical/operator/issues/104>
 * gnuoy assumes it should and updates the bug
<Chipaca> gnuoy: yes
<gnuoy> kk, thanks
<Chipaca> gnuoy: bah, whatever hook runs first
<gnuoy> yep, understood
<Chipaca> in <2.8 on k8s that was 'start', for ex
<Chipaca> and it couldbe upgrade-charm? i think
<Chipaca> iffen you're upgrading :)
<gnuoy> so I think the bug is correct, if you use charmcraft then a legacy deployment is never detected and the symlinks never created.
<gnuoy> I assumed it was deliberate hence the min-version thing. I'll update the title.
<Chipaca> gnuoy: what's a 'legacy deployment'?
<gnuoy> Chipaca, I'm stealing the phrase from the ops framework. I believe it to mean a non-dispatch aware version of Juju
<gnuoy> https://github.com/canonical/operator/blob/master/ops/main.py#L173
<Chipaca> ah :)
<Chipaca> gnuoy: this is with juju <2.8?
<gnuoy> right
<Chipaca> hmmâ¢
<gnuoy> I've put more detail in https://github.com/canonical/charmcraft/issues/104
<Chipaca> thanks
<Chipaca> gnuoy: this is code i wrote, so it cannot _possibly_ have bugs
<gnuoy> haha, must be feature.
<Chipaca> gnuoy: https://youtu.be/qhXjcZdk5QQ?t=52
<gnuoy> exactly!
<Chipaca> that's quite a pickle
<facubatista> Â¡Muy buenos dÃ­as a todos!
<Chipaca> facubatista: (null)
<Chipaca> er
 * Chipaca checks his config
<facubatista> je
<Chipaca> facubatista: ðâ
<Chipaca> much better
<facubatista> https://imgflip.com/i/4adkoh
<facubatista> :)
<Chipaca> facubatista: https://www.bbc.com/future/article/20160325-the-names-that-break-computer-systems
<bthomas> This one surely breaks a lot https://xkcd.com/327/ :-)
<facubatista> Chipaca, my mother's last name is MuÃ±iz, and I remember the real life in the pre-unicode era, everything was Mu#iz for her
<facubatista> Chipaca, jam, in charmcraft#104, shouldn't the OF create the rest of the hooks?
<mup> Issue charmcraft#104: Hook symlinks not created for deployments to environments running Juju < 2.8 <Created by gnuoy> <https://github.com/canonical/charmcraft/issues/104>
<Chipaca> facubatista: remember manuel de la peXa?
<Chipaca> facubatista: yes the problem is that charmcraft is setting things up in such a way that ops thinks it's in post-2.7
<jam> Chipaca, facubatista : the code is still there: https://github.com/canonical/operator/blob/master/ops/main.py#L175
<jam> and it is even called: https://github.com/canonical/operator/blob/master/ops/main.py#L334
<Chipaca> jam: but the hooks are symlinks to dispatch
<Chipaca> jam: and dispatch sets JUJU_DISPATCH_PATH
<Chipaca> jam: and dispatch exists
<Chipaca> and that's what ops uses to choose legacy or dispatch
<facubatista> Chipaca, in current charmcraft, after zipping, remember hooks are not symlinks (but will be in future charmcrafts)
<jam> Chipaca, but why is that a problem?
<Chipaca> no difference, it's the fact that it sets JUJU_DISPATCH_PATH and exists that does it
<gnuoy> self.is_dispatch_aware gets incorrectly set to True which causes an early exit from ensure_event_links
<Chipaca> jam: because then no symlinks are created
<jam> Chipaca, ah, dispatch is setting JUJU_DISPATCH_PATH, why would it do that?
<jam> bad script no biscuit
<jam> :)
<Chipaca> jam: other bugs :)
<Chipaca> need to dig
<jam> Chipaca, ok. so it is a charmcraft bug (arguably), at the least, ops and charmcraft don't agree on signaling
<Chipaca> yeup
<facubatista> Chipaca, https://github.com/canonical/charmcraft/commit/a0bdc74c5b2b63eff9248ad8c192a2c9f8a0f5e1
<Chipaca> yup
<jam> Chipaca, thinking about multipass and snapcraft/charmcraft. I find it interesting with snaps that it is so dangerous to depend on a executable in $PATH that the preferred route is to expose a service for anyone to poke via the network
<jam> Is it because it has been easier to grant Network as a policy than granting "access to executable Foo" as a policy?
<Chipaca> jam: it isn't about it being dangerous, it's a limitation of the security layers
<Chipaca> jam: (there's also the policy issue of letting a confined thing execute an unconfined thing meaning you've just unconfined the confined)
<jam> Chipaca, so find a way to execute the unconfined thing via an HTTP post instead of a CLI exec
<Chipaca> jam: the thing is already exposing a grpc api over a socket to itself
<jam> Chipaca, I just mean, a CLI is an API just like an HTTP API is.snapcraft is able to confine things to not find executable, but doesn't have fine grained control to say what services you could talk to
<jam> but it means people break their confinement via HTTP requests instead of via CLI requests
<Chipaca> gnuoy: we're going to be 5 minutes late
<gnuoy> sure np
<Chipaca> jam, facubatista, wrt charmcraft#104, not super clear to me what we can do
<mup> Issue charmcraft#104: Hook symlinks not created for deployments to environments running Juju < 2.8 <Created by gnuoy> <https://github.com/canonical/charmcraft/issues/104>
<facubatista> Chipaca, create all hooks symlinks everytime?
<Chipaca> that's less than ideal for a couple of reasons
<Chipaca> the issue is that calling charm.py drops the name of the hook
<Chipaca> that is, we lose sys.argv[0]
<jam> Chipaca, not set JUJU_DISPATCH_PATH in dispatch
<jam> ah right
<Chipaca> so it seems to me
<jam> is there a magic in 'exec' ?
<Chipaca> that what we should do is set our _own_ variable
<Chipaca> with blackjack and â¦
<Chipaca> â¦ built-in help?
<Chipaca> jam: i think bash exec does, sh exec does not
<Chipaca> but i'd have to double-check
<jam> Chipaca, 'exec --help' says 'exec -a NAME'
<Chipaca> right, that's bash
<facubatista> Chipaca, the builtin help is a good idea, there's a recurrent question when dealing with this new "dispatch thing" that is "so I'm in here with debug-hook, how I call my hook manually?"
<jam> $ /bin/dash -c 'exec -a foo echo hello'
<Chipaca> jam: ooh, undocumented?
<jam>  /bin/dash: 1: exec -a: not found
<Chipaca> jam: b'doh
<jam> nope, just copy&paste didn't work because IRC interpreted the opening '/' :)
<jam> Chipaca, I'm not opposed to #!/bin/bash in dispatch
<Chipaca> or we could make it a python script ]=)
<facubatista> Chipaca, +1
<Chipaca> but bash sounds alright for a last-minute thing
<jam> facubatista, Chipaca we could. I know that breaks on RedHat because python3 isn't in the default instal
<Chipaca> drop JUJU_DISPATCH_PATH, and use -a
<Chipaca> or
<Chipaca> OR
<Chipaca> use symlinks
<Chipaca> :)
<facubatista> Chipaca, symlinks how?
<Chipaca> this all goes away if we stop flattening symlinks
<Chipaca> doesn't it?
<Chipaca> (maybe it doesn't)
<jam> Chipaca, if you change hooks/install => ../src/charm.py it would go away, but you can't do that because we want to put the "use the venv" somewhere
<Chipaca> right
 * Chipaca sets the venv on fire and sits back to watch
<Chipaca> I'll write the "use bash w/exec -a" as the quickest way out
<Chipaca> â¦ that doesnt work
<Chipaca> python's fiddling with argv
<facubatista> Chipaca, you that know Unix (?), is it ok to have a space rigth after the shebang in "#! /usr/bin/env python3" ?
<Chipaca> facubatista: yep (and they've been documented as required at some point, although weren't)
<facubatista> thanks
<Chipaca> facubatista: also, env -S exists (as of when? no idea)
<ballot> Hello !
<facubatista> hello ballot!
<ballot> I'm looking for a way to retrieve the pod_spec using ops.testing. I see that self.harness.get_pod_spec is defined in 0.8 (https://github.com/canonical/operator/blame/master/ops/testing.py#L423). I guess I don't have a way to test this easily with 0.7 right ? :)
<ballot> well, I don't really have a problem trying to use 0.8 for my charm tbh anyway, i'll give it a try
<Chipaca> ballot: and 0.8 should be out this week :)
<Chipaca> ballot: pre that, there wasn't an easy way of doing that, no
<ballot> Chipaca: alright, just wanted to be sure I was not missing something. I have an issue with charmcraft build, I'll bring that to the right channel, thanks :)
<Chipaca> ballot: 'charmcraft build' issues is also here :)
<ballot> Ah !
<Chipaca> ballot: unless you're building something so secret you can't talk about it in public :-D
<ballot> Well, I put "-e git+https://github.com/canonical/operator.git@master#egg=ops" in my requirement.txt and confirmed it works with "pip install -r requirements.txt"
<ballot> When I do charmcraft build, in the full log I have
<ballot> https://pastebin.ubuntu.com/p/jmyJh58WCT/
<ballot> (sorry bad habit of using the internal one)
<Chipaca> whoa
<facubatista> Chipaca, jam, where I can read about the order of first events sent by Juju?
<ballot> It's fine, I can workaround it easily by manually pulling the wheel in the right location, but probably bug worthy. Just wanted to be sure it was not something obvious on my side
<Chipaca> ballot: does that still happen if your requirements.txt has 'git+https://github.com/canonical/operator.git' instead of your more funky line?
<ballot> Chipaca: let me try
<jam> facubatista, https://discourse.juju.is/t/event-cycle/1117
<facubatista> jam, thanks
<jam> https://discourse.juju.is/t/charm-hooks/1040 and https://discourse.juju.is/t/the-hook-environment-hook-tools-and-how-hooks-are-run/1047 are also relevant
<ballot> Chipaca:  :: ERROR: Could not detect requirement name for 'git+https://github.com/canonical/operator.git', please specify one with #egg=your_package_name
<Chipaca> super strange, i've got that here and it works
<ballot> Chipaca: also tried to remove the @master, but then, read-only filesystem again
<Chipaca> ballot: this is with charmcraft 0.3 from the snap, yes?
<ballot> Chipaca: yes
<Chipaca> facubatista: ^ any ideas?
<ballot> Chipaca: I think I know what happens, I just need to find in pip where is the default location for pulling the dependencies
<ballot> Chipaca: ah, that's the "-e"
<ballot> Chipaca: it works without the "-e"
<Chipaca> augh
<ballot> yeah right, makes sense
<Chipaca> i totally ignored that :-)
 * Chipaca needs a better parser in his brain
<facubatista> the -e tries to install it in your home or something?
<Chipaca> it's the "develop" thing
<facubatista> Chipaca, I though it was why you suggested to use a simpler line
<ballot> It's to point toward the module you're working on so you don't have to update your env
<ballot> facubatista: yes, I missread, and did remove the "-e"
<Chipaca> yep, like 'python setup.py develop'
<Chipaca> ballot: but if you did that for a charm, you'd end up with a .pth and not the actual code you need inside your charm, right?
<ballot> anyway, I don't think using -e makes sense for a charm anyway
<ballot> Chipaca: yeah, it was merely a bad habit on my side
<Chipaca> sounds like an argument against charmcraft supporting 'full' requirement.txt
<Chipaca> :-/
 * Chipaca oh noes
<ballot> sorry :/
<Chipaca> facubatista: maybe we should detect and fail early or with a clearer message
<ballot> Chipaca: does charmcraft support constraints files ?
<Chipaca> ballot: no
<facubatista> Chipaca, let's use fades, that doesn't support "-e" :p
<Chipaca> ballot: but not because of philosophical reasons, just nobody's asked us :-)
<ballot> Chipaca: well, "priorities" :)
<ballot> Chipaca: I'm not sure it's worth spending time on it right now. The only use case I see is if the application code and charm are hosted on the same repository, then to limit in one place some module version for the app, the charm and the tests, it's better to use constraints rather than repeating the limitation in all requirements.txt
<Chipaca> k
<Chipaca> i need to step out (physio! here's hoping for a better back)
<ballot> Chipaca: np, thanks !:
<ballot> My tests are running now :)
<ballot> (well failing of course, as one would expect, but for good reasons now)
<Chipaca> :-D
 * Chipaca disappears into the sunset
 * facubatista eods
#smooth-operator 2020-08-05
<ballot> Hello ! I've pushed the last modifications of the charm and all the tests in https://code.launchpad.net/~ballot/charm-k8s-mm-pd-bot/+git/charm-k8s-mm-pd-bot/+merge/388497 if you want to review part of it. Since it's the initial push with a working charm, this is quite a huge one, sorry for that
<Chipaca> ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
<bthomas> Morning
<jam> morning Chipaca
<bthomas> Hmmm got the following error on snap installing juju "Run hook connect-plug-peers of snap "juju" (run hook "connect-plug-peers": error: cannot communicate with server: timeout exceeded while waiting for response)"
<bthomas> and looks like juju did not install as shown by snap list
<bthomas> worked second time. Odd.
<jam> bthomas, that sounds like something to share in #juju/as a Juju bug.
<jam> I know there are some snap hooks that let Juju know about things like microk8s
<bthomas> jam : got it. worked second time so I am not sure if I can reproduce it. If I can will report it.
<jam> bthomas, it definitely sounds like a race condition that the script should be handling.
<Chipaca> jam, bthomas, that looks like a snapd bug to me
<jam> Chipaca, depends what "server" it is trying to talk to :)
<Chipaca> unless juju has a concept of 'plugs'
<Chipaca> that's a snappy thing :)
<jam> Chipaca, so it is certainly part of snap installing, I thought it might be the script failing to talk to a Juju server during the plug hook execution.
<jam> But if it is *snap* failing to talk to the server to ask it to run the hook, that would certainly be a snap issue
<Chipaca> bthomas: you could enable debug logs in snapd so you have useful logs for the next time it happens for people to debug it, but it is rather chatty
<bthomas> Chipaca: will do
<Chipaca> bthomas: https://forum.snapcraft.io/t/4668/2?u=chipaca
<Chipaca> easiest way to enable debug :)
<bthomas> thanks
 * Chipaca has that bookmarked
 * Chipaca always forgets he has it bookmarked
<Chipaca> anyway, i need to take a break
<bthomas> I create notes of such tasty tips in org-mode
<Chipaca> show-off
<Chipaca> :Ã¾
<bthomas> :-)
<Chipaca> just asked the following in #juju by mistake, so if you're in both, sorry for the noise :)
<Chipaca> jam: I think the only sane way out of this dispatch mess we've dug ourselves into is to look at the juju version, like what we did with has_app_data
<Chipaca> jam: which means main needs to parse the juju version, and so does model (for app data)
<Chipaca> jam: DRY would mean doing that once in main and then passing it in to model
<Chipaca> is that worth it
<Chipaca> what I'm going to do is do it in both places for now, and we can think about refactoring once that's out
<jam> Chipaca, in a meeting, will respond soon, but first cut sounds ok
<jam> Chipaca, can we join a hangout to discuss the options?
<jam>        PYTHONEXECUTABLE
<jam>               If this environment variable is set, sys.argv[0] will be set to its value instead of the value got  through  the  C  runtime.
<jam>               Only works on Mac OS X.
<jam> *so close*
<jam> Chipaca, I'm stepping away for a bit. I think parsing it once and having it available as an attribute of model (probably private to start), would be nice, I do prefer not having Model interact with env vars
<facubatista> Â¡Muy buenos dÃ­as a todos!
<bthomas> facubatista: Buenos dias (but that is as far as my spanish goes :-)
<facubatista> bthomas, hello! :)
<Chipaca> facubatista: q'acÃ© caez'n!
<facubatista> :) hola Chipaca
<Chipaca> jam: d'oh, i didn't see your earlier request-for-hangout
<Chipaca> because, coding
<jam> morning facubatista
<jam> Hi Chipaca I'm back if you'd like to chat
<facubatista> hola jam
<jam> its almost bug revue time anyway
<Chipaca> jam: I'm 5 minutes from a pushable branch
<jam> Chipaca, then finish it!
 * Chipaca looks up the konami code for emacs
<jam> u u d d l r l r a b b a
<Chipaca> not one M-x?
<Chipaca> also, is ABBA part of a konami conspiracy
<Chipaca> oh dang the symlinks won't work will they
<Chipaca> jam: can you get a 2.7 juju, and a charmcraft-built charm, remove the 'dispatch' binary from the charm by hand, and push that to the 2.7 juju?
<Chipaca> jam: and then fire config-changed or something not in the handful of initial events
<jam> Chipaca, you mean 'snap install juju --channel 2.7/stable; juju bootstrap lxd lxd' ?
<jam> yes I can, but you probably can, too :)
<Chipaca> you make it sound so easy
<Chipaca> jam: sorry, yes, i'll do it
<Chipaca> jam: i forgot 2.7 isn't that old that i need you to build it for me :)
<jam> Chipaca, I'm happy to help if it accelerates you, but give a man a fish and all that
 * Chipaca likes fish
<Chipaca> oh dang i haven't had lunch
<jam> is that a form of nerd sniping?
<Chipaca> https://github.com/canonical/operator/compare/master...chipaca:argv0-woes?expand=1
<Chipaca> i haven't proposed it because AUGH
<Chipaca> and i'm going to have lunch
<jam> Best part: AUGH THE SYMLINKS WON'T WORK NEWS AT 11
<facubatista> Chipaca, meeting?
<mup> Issue operator#362 opened: Create symlinks when Juju version doesn't support dispatch <Created by gnuoy> <https://github.com/canonical/operator/issues/362>
<mup> Issue operator#365 opened: Make JujuVersion.from_environ return 0,0,0 if JUJU_VERSION isn't set <Created by chipaca> <https://github.com/canonical/operator/issues/365>
<mup> Issue operator#358 closed: New configs added to a charm not available <Created by davigar15> <Closed by chipaca> <https://github.com/canonical/operator/issues/358>
<facubatista> Chipaca, meeting?
<Chipaca> whoops
<facubatista> Chipaca, jam, https://obby.co.uk/schools/venturistable
<facubatista> Chipaca, it was pizza: https://blog.taniquetil.com.ar/posts/0517/
<facubatista> Chipaca, indeed you were there https://www.dropbox.com/sh/0pw0yix8qmc3qgy/AADJFfwTzVo28bNt7qexvKjxa?dl=0&preview=IMG17916.JPG
<facubatista> I remember there was an issue with the train, we had to walk quite a lot
<Chipaca> man, we really need spread-like integration tests
<Chipaca> facubatista: charmcraft-built charms on 2.7 don't work at all
<Chipaca> bah, it's gnuoy's bug
<Chipaca> hmm
<mup> PR operator#366 opened: version-check to determine dispatch support <Created by chipaca> <https://github.com/canonical/operator/pull/366>
 * facubatista eods
#smooth-operator 2020-08-06
<jam> morning all
<gnuoy> Hi, I'd like charmcraft to include the charms readme in the built charm, which it doesn't seem to do at the moment. Is there anyway to do that ?
<gnuoy> hmm, looking at the code that looks like a 'no'
<jam> gnuoy, currently no, we are working on a patch that will change charmcraft to use '.jujuignore' to figure out what it will omit, and include everything else (matching the way 'juju deploy' does it today)
<jam> gnuoy, so in the next release, that would change, but currently there isn't a way to tweak it
<gnuoy> jam, ack, thanks. I raised https://github.com/canonical/charmcraft/issues/108 to track it
<jam> morning Chipaca
<Chipaca> jam: ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
<Chipaca> :)
<jam> Chipaca, that's a very good morning
<Chipaca> jam: you have been blessed by the gods of $RANDOM
<jam> Chipaca, ahh
<bthomas> morning all
 * bthomas wondering how Chipaca types all those unicode fonts
<jam> bthomas, I'm sure its a script, but I like to think he has a second keyboard
<bthomas> or a spare set of fingers
<Chipaca> jam: indeed, https://github.com/chipaca/bin/blob/master/beuno
<Chipaca> if it's the unicode side of that that you found interesting though, snap install unifonter
<bthomas> ah
<jam> Chipaca, 2-512, thats... aggressive
<Chipaca> nah, $RANDOM only goes to 32767
<Chipaca> so it's to 63
<jam> Chipaca, just checking that you're aware of the meeting in 30min. It showed up on my calendar earlier today.
<Chipaca> jam: ack
<facubatista> Â¡Muy buenos dÃ­as a todos!
<jam> hi facubatista
<jam> I think one of the release changes are that test suites should probably start calling Harness.cleanup()
<facubatista> hola jam
<Chipaca> jam: standup?
<Chipaca> bthomas: fixed unifonter, thanks for the report
<bthomas> Awesome Chipaca, will redownload and flood this place with unicode goodness
<jam> Chipaca, reviewde
<Chipaca> bthomas: actually, that was a mistake. Now _really_ fixed :)
<bthomas> :-) lucky I haven't checked it yet.
<Chipaca> jam: thanks!
<jam> Chipaca, I sent you some thoughts on how to have the docs for 0.8 changes.
<jam> The examples are a bit weak, so if you feel it is better to omit them, feel free
<Chipaca> weak > none, most of the time
<Chipaca> bah; weak > none for strong values of weak
<jam> :)
<facubatista> Chipaca, meeting?
<Chipaca> facubatista: nah
<facubatista> :)
 * Chipaca pats ChanServ 
<mup> Issue operator#362 closed: Create symlinks when Juju version doesn't support dispatch <Created by gnuoy> <Closed by chipaca> <https://github.com/canonical/operator/issues/362>
<mup> PR operator#366 closed: version-check to determine dispatch support <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/366>
<mup> Issue operator#367 opened: Provide valid "series" in default template charm <Created by balbirthomas> <https://github.com/canonical/operator/issues/367>
* ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.7.0 || charmcraft 0.3.1
<facubatista> charmcraft 0.3.1 released!
<facubatista> jam, Chipaca, https://github.com/canonical/charmcraft/pull/110
<mup> PR charmcraft#110: Release 0.3.1, and improvements in the procedure <Created by facundobatista> <https://github.com/canonical/charmcraft/pull/110>
<mup> Issue operator#111 closed: Provide valid "series" in default template charm <Created by balbirthomas> <https://github.com/canonical/operator/issues/111>
* ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.8.0 || charmcraft 0.3.1
<Chipaca> 0.8.0 is out :-)
 * facubatista eods
<alejdg> Hey folks, is there a way to block relation-broken or relation-departed when a pod/unit is replaced?
#smooth-operator 2020-08-07
<Chipaca> facubatista: ð
<bthomas> ðºððð ððððððð¡ðð ððððððð
<bthomas>  
<bthomas>  
<Chipaca> :-)
<Chipaca> bthomas: ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½ï½  ï½ï½ï½ï½ï½ï½ï½ï¼
<bthomas> :-)
<bthomas> Chipaca: I messed up and need some help. I created a ticket in the wrong repo
<Chipaca> bthomas: ok :-) tell me more
<bthomas> If it can be deleted I can recreate it. https://github.com/canonical/operator/issues/367
<bthomas> Alternatively if you have rights to do so you may choose to move it.
<bthomas> This might be a good simple issue for me to fix when I finish with prometheus and grafana
<bthomas> I have moved both prometheus and grafana to charmcraft 8 and removed gitmodules. The charms have been built I just need to learn how to test it and deepen my knowlege of charms too.
<Chipaca> bthomas: ah, i transferred that one yesterday
<bthomas> Thanks you.
<bthomas> I have pushed my changes to my github branches at https://github.com/balbirthomas
<Chipaca> bthomas: click that url
<bthomas> :-)
<Facu> Â¡Muy buenos dÃ­as a todos!
<bthomas> Buenos dias
<Chipaca> Facu: ð !
<Chipaca> also ðâ
<Chipaca> Facu: today i found we have bugs in the tab completion thing, which i need to think about how to address
<Chipaca> it only completes the first option
<Chipaca> i need to look at what alternatives i have, because we can't be the first people doing this :)
<Chipaca> subcommands with options i mean
<Facu> hola bthomas, Chipaca
<bthomas> At your service Facu
<Facu> Chipaca, yeap, it's not that weird
<bthomas> FWIW the new operator framework and charmcraft is/was very easy to use. I was able to pip install ops, actually even built a deb package (python3-operator) and tried it that way. It all worked. Even ran tests natively and that worked too.
<bthomas> Facu: I also created source deb package for logassert
<Facu> nice
<Facu> the .deb should not be necessary
<Facu> nice!
<Facu> I just released logassert to be used as a pytest fixture, I plan to bring it to charmcraft
<Chipaca> Facu: oa
<Chipaca> Facu: oa?
<Facu> Chipaca, o/
<Chipaca> Facu: your network is super happy
<Facu> not
<Facu> pff, bytes, who need them?
<facundobatista> Chipaca, bthomas, standup?
<bthomas> i was just there
<bthomas> will login again
<alejdg> Hi everyone, is there a way to block relation-broken or relation-departed when a pod/unit is replaced?
 * Facu is back
<Chipaca> facubatista: you there?
<facubatista> Chipaca, yes
<Chipaca> facubatista: https://paste.ubuntu.com/p/YFWqJDPjsd/
<Chipaca> facubatista: eh, sillyly, s/update_info/instances/ to actually see something
<Chipaca> or maybe even 'for i in x.instances: print(i.name, i.status)'
<Chipaca> no, not status, instance_status
<Chipaca> Â¯\_(ã)_/Â¯
<facubatista> Chipaca, ~/canonical/multipass/src/rpc/ ?
<Chipaca> facubatista: git clone https://github.com/canonical/multipass
<Chipaca> don't you have all git repositories ever in ~ ?
<facubatista> ln -s https://github.com/ ~
<Chipaca> facubatista: 'cp -al' ftw
<facubatista> Chipaca, the last part of line 5 in the pastebin is weird
<facubatista> let's HO 5'?
<Chipaca> hah, didn't notice
<Chipaca> indeed that's wrong
<Chipaca> sure, let me get my headset
<facubatista> Chipaca, 1-1
<Chipaca> facubatista: 0
 * Facu eods
<Facu> and eows
<Facu> will be back on Monday!
<crodriguez_> is there something hidden in the framework that tells that only the leader can execute config_changed hook?
<Chipaca> crodriguez_: nope
 * Chipaca isn't here
