#smooth-operator 2020-06-08
<mup> Issue operator#304 closed: Use git describe to log version when running from git <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/304>
<mup> PR operator#319 closed: ops: get version from git <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/319>
<mup> Issue operator#309 closed: KeyError: 'JUJU_MODEL_NAME' while emitting event from Harness <Created by exceptorr> <Closed by chipaca> <https://github.com/canonical/operator/issues/309>
<Chipaca> pjdc: ð
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: ð
<facubatista> hola Chipaca
 * Chipaca integrates https://jazzkeys.plan8.co/ into emacs
<Chipaca> facubatista: https://jazzkeys.plan8.co/?msg=-M9IfwcZxxA0wD6iLmb1
<facubatista> Chipaca, ja, nice!!
<facubatista> I wonder how it be to really integrate it with the keyboard, maybe not with the editor, just at a system level
<Chipaca> facubatista: snap install bucklespring
<facubatista> it's a wonder how it's balanced across speakers :)
<Chipaca> facubatista: you can adjust how "wide" that goes, as well
<Chipaca> with headphones i find i need to set it to a lot less than the default for it to be reasonable
<Chipaca> with speakers the default sounds 'right'
<Chipaca> having written that, it's obvious why =)
<facubatista> yes
<facubatista> Chipaca, so, how we continue with that spec?
<Chipaca> facubatista: let it prove for another day
<facubatista> Chipaca, ack, let me know
<Chipaca> facubatista: but AIUI we need to expand on the contents of charmcraft.yaml and give a go through a .charm contents in the concrete
<jam> morning facubatista
<facubatista> Chipaca, a) charmcraft.yaml is for the whole tool, not just build, we may write about it in a different doc, and point from this one?
<facubatista> jam, hola!
<Chipaca> jam: #320 gtg, #318 and #322 waiting for +1s
<mup> PR #320: ops/framework.py: Move pickle into Storage <Created by jameinel> <https://github.com/canonical/operator/pull/320>
<mup> PR #318: Simplified the CharmBase init signature <Created by facundobatista> <https://github.com/canonical/operator/pull/318>
<mup> PR #322: log: set up sys.excepthook to log exceptions <Created by chipaca> <https://github.com/canonical/operator/pull/322>
 * Chipaca the taskmaster
<facubatista> Chipaca, b) you say to dump the content of a real .charm's tree there?
<Chipaca> facubatista: and IIRC the build directory itself also (but that can wait until we've made it not be so symlinky)
<Chipaca> (or pretend we've already done that :)
<facubatista> Chipaca, we need to talk about that, I don't see the benefit of copying bytes
<Chipaca> facubatista: ok
<Chipaca> (i don't see the benefit of copying bytes either)
<facubatista> (in this case in particular, copying bytes is a good thing in lot of places for this thingies called computers)
<Chipaca> facubatista: the trick is always to copy as little as possible
<Chipaca> 1/2 of all computer science treaties are about that
<Chipaca> the other 3/4 are about estimation
<facubatista> :)
<facubatista> Chipaca, so, let's talk about symlinks! here? HO? later?
<Chipaca> facubatista: here is fine
<Chipaca> facubatista: so i'll start saying what I'd like
<Chipaca> facubatista: then you tell me why i'm wrong
<Chipaca> facubatista: I'd like build to do the equivalent of 'cp -al' of all the relevant bits, and then explicitly symlink things like hooks that we want to be symlinks, and then create the zip with the actual symlinks in it
<facubatista> Chipaca, you're never wrong! you may not be as much right as I am
<Chipaca> facubatista: I'd like build to create the venv outside of build (.venv maybe?) and the 'cp -al' it into build also, so it can be thrown away / recreated cheaply when not changed
<Chipaca> facubatista: but this last thing is just optimization
 * facubatista does `man cp` for first time in years
<Chipaca> facubatista: hardlink files, create directories
<Chipaca> facubatista: almost no byte copying :)
<facubatista> Chipaca, let's leave the venv to a second phase of this talk
<Chipaca> totes
<facubatista> Chipaca, so, doing 'cp -al' is compared to 'symlinks' in: (let me finish)
<facubatista> a) nicer, as it no create actual symlinks (hardlinks are cheap!)
<facubatista> b) more work, as we need to actually do a lot of recursive work to create trees and all files inside those trees
<facubatista> c) nicer, as we may get to have "actual symlinks" in the zip file
<facubatista> Chipaca, is (c) the real benefit of your proposal here? is this what you're actually searching for?
<Chipaca> d) nicer, as a developer looking into build/ will see something a lot closer to what they get from unzipping the charm
<Chipaca> (c) and (d) are what i'm going for
<Chipaca> (a), meh; (b), smop :-)
<facubatista> Chipaca, ah, (d) convinced me
<facubatista> Chipaca, I'm writing something, it may take me 5-10'
<Chipaca> second monday of late standup, it throws me every time
 * Chipaca gets tea
<facubatista> Chipaca, what do you think? https://github.com/canonical/charmcraft/issues/29
<facubatista> Chipaca, btw, would you close milestone 0.1.1? thanks
<facubatista> Chipaca, let's talk about the venv?
<Chipaca> veeeeeenv
<Chipaca> facubatista: sorry my brain was momentarily taken over by zombies
<Chipaca> facubatista: what do you want to talk about wrt venv?
<facubatista> Chipaca, where it will be located
<facubatista> the second phase of the talk we had before
<Chipaca> facubatista: so, as per previous discussions, we want a way of not recreating the venv when it wouldn't change, right?
<facubatista> Chipaca, yes
<facubatista> Chipaca, I was thinking about using the hash of all requirements to check if we should or we shouldn't
<facubatista> Chipaca, I like putting the venv inside the build directory, so we only "stain" one place
<facubatista> Chipaca, we can not put that kind of dir in project's directory, as it may already have a .venv, or a .env, or a venv, etc
<Chipaca> facubatista: but doesn't build start by nuking build/?
<facubatista> Chipaca, I would change that, to probably start by nuking everything *but* the venv dir if we shouldn't
<Chipaca> facubatista: so â¦ what's the issue?
<facubatista> Chipaca, before you wanted to put it outside... "I'd like build to create the venv outside of build"
<Chipaca> facubatista: Â¯\_(ã)_/Â¯ details
<Chipaca> facubatista: outside as in 'not nuked'; if you think it's easier / more foolproof to have it inside but not nuked, then, works for me
<facubatista> Chipaca, perfect
<Chipaca> siiigh. Changing 'fake_script' so that all scripts are python instead of bash triples the time our tests take to run
<facubatista> Chipaca, what if we mock them?
<Chipaca> facubatista: that's not very welcoming
<facubatista> jaja
<Chipaca> i'll be playing with different ways of doing it, later
<Chipaca> jam: standup?
 * facubatista -> lunch
<mup> Issue operator#188 closed: Improve calling for Object descendant tree  <enhancement> <Created by facundobatista> <Closed by facundobatista> <https://github.com/canonical/operator/issues/188>
<mup> PR operator#318 closed: Simplified the CharmBase init signature <Created by facundobatista> <Merged by facundobatista> <https://github.com/canonical/operator/pull/318>
<mup> PR operator#320 closed: ops/framework.py: Move pickle into Storage <Created by jameinel> <Merged by jameinel> <https://github.com/canonical/operator/pull/320>
<mup> Issue operator#289 closed: hook exception logged at DEBUG <Created by jetpackdanger> <Closed by chipaca> <https://github.com/canonical/operator/issues/289>
<mup> PR operator#322 closed: log: set up sys.excepthook to log exceptions <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/322>
 * facubatista eods
#smooth-operator 2020-06-09
<mup> PR operator#324 opened: model: don't use --app for relation-get/-set before 2.7.1 <Created by chipaca> <https://github.com/canonical/operator/pull/324>
<davigar15> Any updates on this? https://bugs.launchpad.net/juju/+bug/1882127 I have asked in the #juju channel too. I'm not sure which team should look into it.
<Chipaca> moin moin
<jam> morning Chipaca
<Chipaca> jam: had a bit of insomnia yesterday
<jam> hi davigar15, I don't have any updates, I'll raise it in standup today with the Juju team to hopefully increase visibility. At a minimum there is a Juju bug if it *ever* panics.
<Chipaca> jam: so there's a pr up
<jam> Chipaca, yeah, I saw about --app. I was trying to set up different Juju versions to test it for you.
<Chipaca> jam: (and email with context on snapcrafters)
<Chipaca> jam: <3
<Chipaca> incidentally we have no tests with is-app true
<jam> Chipaca, well, you can fix that one :)
<Chipaca> should i fix it in the same pr i'm touching the code tho
<jam> Chipaca, do you know how far back we care about? eg, do we care about 2.6?
<jam> Chipaca, adding tests when touching the code sounds like a good thing, no?
<Chipaca> jam: I wouldn't care about 2.6 unless somebody asks for it
<Chipaca> jam: but i would like to know what would break in 2.6 :-)
<Chipaca> at some point
<Chipaca> wrt tests, yeah, on it
<jam> Chipaca, k. I can at least spin one up and be somewhat aware.
<Chipaca> brain not fully engaged
<jam> Chipaca, we should (eventually) look to have a "test the features" charm that we can run against various Juju versions. Maybe we can polish 'test-main' to grow into that.
<Chipaca> d'oh there's a bug in my pr
 * Chipaca fixes
 * Chipaca writes tests first
<Chipaca> today is going to be a long day
<Chipaca> spent 10 minutes trying to figure out why 1.8.0 was saying it didn't have app data
<jam> Chipaca, 1.8 ? ah, in testing
<jam> I don't think Juju ever had a 1.8 (due to odd numbering with pyjuju vs go juju, etc.)
<Chipaca> jam: as opposed to 2.8
<Chipaca> ah, yeh
<Chipaca> that
<Chipaca> i think i'm going to take a break, go outside, see if the cobwebs go away
<Chipaca> can't be this /lelo/ for the hangouts
<jam> Chipaca, feeling any better?
<jam> i'm trying to figure out what the actual issue is that they're running into, because --app was introduced in 2.7.0
<mup> Issue operator#223 closed: Operator fails on Juju 2.7.0 and below <bug> <Created by chris-sanders> <Closed by jameinel> <https://github.com/canonical/operator/issues/223>
<mup> Issue operator#223 opened: Operator fails on Juju 2.7.0 and below <bug> <Created by chris-sanders> <https://github.com/canonical/operator/issues/223>
<Chipaca> jam: omw
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: [citation needed]
<Chipaca> facubatista: :) hola
<facubatista> Chipaca, hola! sorry I skipped the first meeting, had a rough night
<Chipaca> facubatista: same here (but 4 time zones)
<Chipaca> jam: ping
<jam> Chipaca, pong
<jam> ah, sorry, brt
<Chipaca> and now i'm going to have lunch
<Chipaca> i blame james for that
<jam> davigar15, can you confirm which charm it is where you run into https://bugs.launchpad.net/juju/+bug/1882127 ?
<davigar15> Zookeeper one
<jam> Chipaca, reading operator#223 I'm pretty sure it is just "below 2.7.0" where we fail
<mup> Issue #223: Operator fails on Juju 2.7.0 and below <bug> <Created by chris-sanders> <https://github.com/canonical/operator/issues/223>
<davigar15> When relating to Kafka
<Chipaca> jam: but note in email '~2.7.4' is mentioned
<jam> Chipaca, so if it is 2.7.4 then it is about bugs in reading application data in K8s charms, not about --app not being available as an arg
<jam> but I have the feeling they saw something that kind-of sounded like what they were seeing and decided it was the same
<jam> Chipaca, sorry, having a serious discussion in daily, will be to standup soon
<Chipaca> jam: yay
<Chipaca> need to step out, bbiab
<Chipaca> facubatista: i'll be 5 minutes late
<facubatista> Chipaca, no worries
<facubatista> (I'm there, just step in)
<Chipaca> OK
<Chipaca> I am EOD, peeps
<Chipaca> i didn't think i'd make it this far after barely sleeping, but hey :-)
 * facubatista eods and tomorrow is off
<facubatista> see you all on Thursday
#smooth-operator 2020-06-10
<Chipaca> morning all
 * Chipaca bbiab
<jam> morning
<Chipaca> jam: how're you doing?
<jam> pretty good, how about yourself? get any better rest?
<Chipaca> yeah :-) overslept today but hey
<Chipaca> hm, just realised i can make the logic a tiny bit simpler
 * Chipaca goes for it
<Chipaca> hm, simpler but not clearer
 * Chipaca undoes
<Chipaca> jam: i'm moving the bug revue to tomorrow
<jam> ok
<jam> you could move it to Friday :)
<Chipaca> I could
<Chipaca> but I won't
<Chipaca> :-)
 * Chipaca is also off Friday, but might have a masochist streak
<jam> Chipaca, is there any explicit Juju testing that you would like me to do? I'm comfortable with your patch, but I can do a version test if you want
<Chipaca> jam: i'm happy with it too. If we had concrete steps to reproduce an issue with low 2.7.x then I might ask to look at them, but we don't...
<Chipaca> so i think the current approach is the best we can do
<jam> Chipaca, so I'm aware of 'timeit' I was wondering if there was anything better than that for Python benchmarks?
<Chipaca> jam: I don't know of anything. I do feel like there has to be something :)
<jam> pytest mentions benchmarking but there doesn't seem to be stdlib stuff. I do like go test's benchmark utility
<jam> nose and pytest both seem to have something
<jam> Chipaca, pytest doesn't like our test suite because you called TestMain "Test*" even though you didn't inherit from TestCase
<jam> :)
<Chipaca> jam: how so?
 * Chipaca pokes
<Chipaca> ahh
<jam> Chipaca, anything named "Test" gets run as a test, but it can't instantiate because it is an ABC
<Chipaca> silly pytest
<jam> https://gist.github.com/jameinel/c10f81ad708513eafa489a3cdb0ce046
<jam> Chipaca, ^^ seems like CSafeLoader is still important
<jam> I grabbed a modest sized YAML file, and benchmarked loading it. 2ms vs 25ms
<Chipaca> jam: 'modest'
<Chipaca> :)
<jam> Chipaca, it is postgresql's config.yaml: https://api.jujucharms.com/charmstore/v5/postgresql-207/archive/config.yaml
<Chipaca> that aligns with what i remember when poking at snapcraft's usage of it too
<jam> It isn't a book, but it isn't a trivial 2 line thing either.
<Chipaca> ie 8-10x speedups
<jam> 'modest'
<jam> Chipaca, I'm actually rather surprised that PyYAML doesn't just use C if it is available
<jam> having to have try/except /getattr in your code because they seem iffy about it seems odd
<Chipaca> jam: you lost me there, what try/except/getattr?
<Chipaca> jam: you mean to do Loader=<csafeloader if there otherwise safeloader>?
<jam> Chipaca, yeah. Having the API to your library be "wrap everything in a check to see if you actually have what you want" rather than providing that
<Chipaca> jam: agreed, that api is weird
<Chipaca> jam: if you don't like try/except nor getattr, you could use yaml.__with_libyaml__
<Chipaca> jam: what did you use to build that benchmark btw?
<jam> Chipaca, pip3 install --user pytest-benchmark and then wrote a single simple file and "pytest test_bench.py"
<Chipaca> neat
<jam> Chipaca, it has pretty output, so I figured its something reasonable to start with
<jam> I'm still not a huge fan of pytest's magic variable names
<jam> but their rendering is very nice
<Chipaca> pretty output + super simple usage == win
<Chipaca> pretty output + super simple usage - so much magic omg == â¦
<Chipaca> i still can't decide that one :)
<jam> Chipaca, it goes back to discovery/surprise. If I write a function and it magically starts testing it, 'wow'. But then I have TestMain that gets run by accident
<jam> or a parameter that suddenly means something different because I changed a variable name
<jam> If you're deep in pytest it is probably reasonable and avoids boilerplate. When you're not, then it is inscrutable and you don't know what 'caplog' implies
<jam> Chipaca, so does that mean by default yaml.safe_load and yaml.load *don't* use the optimized backend?
<Chipaca> jam: correct
<jam> ugh
<Chipaca> jam: load's default loader is FullLoader
<Chipaca> jam: hopefully subclassing CSafeLoader to add tuples works :)
<Chipaca> dunno
<Chipaca> anyway. had a meeting, now some exercise before lunch and more meetings
<jam> Chipaca, it passes the test suite :)
<Chipaca> jam: huzzah :)
<jam> Chipaca, interestingly, that is a 20ms speedup per hook for Postgresql, since we load metadata.yaml on every hook (at least it isn't every call to Juju, but its still a fair bit)
<jam> Chipaca, this feels very much in violation of the API rule "the obvious way should be the correct way"
<Chipaca> jam: 'this is YAML. we don't do "obvious" here.'
<Chipaca> ok, now yes i go
<mup> PR operator#325 opened: ops/main.py: Use CSafeLoader <Created by jameinel> <https://github.com/canonical/operator/pull/325>
<jam> Chipaca, ^^ when you're back
<Chipaca> jam: i'm back
<Chipaca> run has been postponed by rain :)
<jam> I'm baaa-aaak
<jam> https://youtu.be/QOkSvLqkafU?t=7
 * Chipaca concurs
<mup> PR operator#326 opened: make abc TestMain private to help pytest <Created by chipaca> <https://github.com/canonical/operator/pull/326>
<jam> Chipaca, I'm available for standup whenever you are. why does YAML and python versions have to be so hard...
<Chipaca> jam: let's do it
<Chipaca> jam: so
<Chipaca> jam: 1. make sure you have the appropriate python-dev on your system
<Chipaca> jam: pip install cython
<Chipaca> erm, that's (2)
<Chipaca> jam: 3. make sure you nuke any previous yamls from the pip cache, find ~/.cache/pip/ -name 'PyYAML*' -delete
<Chipaca> jam: 4. make sure you also have libyaml-dev etc (apt build-dep pyyaml or sth)
<Chipaca> jam: now a pip install PyYAML should rebuild your wheel and get you the good stuff
<jam> nuking pip cache is a bit of a pain for 3 different versions but at least we know
<vgrevtsev> hi everyone - still working on the Prom charm and found something that I'd like to discuss... so tl;dr when I'm doing a `model.pod.set_spec` inside of the hook (let's say, `config-changed`) - it applies  ONLY after the config-changed hook will exit, not in the middle of the process
<Chipaca> jam: it only nukes the wheels, the source will still be there (and you want it rebuilt anyway)
<vgrevtsev> so, that makes impossible to poll the application for the new status (which is relying on the pod spec params, ConfigMap for example)
<vgrevtsev> is this an expected behaviour or should I raise a bug about that?
<jam> Chipaca, $ pip3 uninstall yaml
<jam> Traceback (most recent call last):
<jam> ...
<jam>   File "/home/jameinel/dev/operator/.venv/3.8/lib/python3.8/distutils/__init__.py", line 1, in <module>
<jam>     from distutils import dist, sysconfig
<jam> ImportError: cannot import name 'dist' from partially initialized module 'distutils' (most likely due to a circular import) (/home/jameinel/dev/operator/.venv/3.8/lib/python3.8/distutils/__init__.py)
<jam> (
 * Chipaca covers his eyes and hides
<Chipaca> vgrevtsev: I think that's Juju's behaviour (we call pod-spec-set immediately)
<vgrevtsev> :(
<vgrevtsev> any ideas or suggestions how can we work around this in the charms?
<jam> vgrevtsev, I do know that it is intentional behavior. You're welcome to file a bug about it, I have discussed it a bit, but it is good to know why you need it and lend your voice to the discussion
<vgrevtsev> jam: ah... alright. I will file a bug against Juju then. Thanks!
 * vgrevtsev thinks what can he do to w/a this
<jam> vgrevtsev, how are you depending on a ConfigMap of another pod that you are creating, but then not setting ?
<vgrevtsev> not another...
<jam> Chipaca, fortunately I can just rm .venv and try again, but pip being broken from virtualenv is annoying
<Chipaca> jam: I haven't seen that one myself, fwiw
<jam> vgrevtsev, so, you're running the charm in the -operator pod, you are calling pod-spec-set to create a different pod (for the application), and then what config map entry exists for that pod that you didn't just set from pod-spec-set
<jam> (note that I'm not saying you're wrong in any way, just trying to understand what is going on)
<vgrevtsev> jam: so my usecase is - I'm deploying the pod which has some ConfigMap, and then I'd like to re-configure this pod (that's what `config-changed` for, right?) So I'm setting the new PodSpec against my application pod with the new configmap options
<vgrevtsev> then, I tell my app via API to reload its config and trying to identify, has the config been changed or not
<vgrevtsev> the problem here is, the config will never be in its new state, because the podspec has not been updated in reality
<vgrevtsev> so, I can exit the config-changed handler (so the configmap will apply), but nobody then will tell an application to reload its state
<jam> Chipaca, worked for 3.6 and 3.7, for 3.8 I get warnings about "char*" vs "unsigned char*" but I *think* it worked...
<jam> vgrevtsev, if you actually changed the pod spec, then Juju will tell K8s to schedule the new schema, causing your pod to get stopped and a new one started
<vgrevtsev> interesting thing, but somethimes it doesn't happen, for example if you're changing only the configmap part - it does not lead to pod re-creation
<vgrevtsev> but if you'll change the `containerPort`, it will shut the pod down and create a new one, that's true
<jam> vgrevtsev, so we had a discussion in the past about what should a charm do, and how does that act transactionally wrt other Juju model operations
<jam> vgrevtsev, eg, 'relation-set' doesn't propagate values to other agents until the hook returns, and that is very much intentional
<jam> pod-spec-set was seen a bit as something the charm does that then needs a similar transactionality
<jam> however, I've come to see pod-spec-set as more like "systemd restart"
<jam> which isn't under the same transaction as the hook
<vgrevtsev> I'd be happy to have a way to forcibly restart/rebuild/... the pods.
<vgrevtsev> That actually would solve my problem
<vgrevtsev> Now I can see that pod-spec-set has been invoked, but the pod was left intact
<vgrevtsev> so that leaves an application in non-consistent state, as charm config says `foo=baz`, while app still thinks `foo=bar`, for example :)
<vgrevtsev> (while k8s's ConfigMap stays `foo=baz`, as it got updated by pod-spec-set)
<vgrevtsev> says*
<Chipaca>             spec_path.write_text(json.dumps(spec))
<Chipaca> i wonder why that's done that way around :)
<jam> Chipaca, vs json.dump(open(spec_path)) ?
<Chipaca> jam: or with spec_path.open(...) â¦
<Chipaca> yeh
<vgrevtsev> jam: fwiw, https://bugs.launchpad.net/juju/+bug/1882976
<Chipaca> vgrevtsev: as a (probably sucky) workaround, you could defer and then when you come back the change should be applied (but it'll be 5 minutes later)
<vgrevtsev> was thinking about putting the reload logic in the update-status hook btw
<Chipaca> anyhoo, soft-eod from me, will check in later
#smooth-operator 2020-06-11
<Chipaca> hellooooo
<jam> morning Chipaca
<Chipaca> hi jam
<Chipaca> jam: did we have anything to review for today's meeting?
<jam> Chipaca, probably would be good to think about a policy wrt mocking multiple interactions
<jam> Chipaca, I added a line to https://github.com/canonical/operator/pull/325/files to do a debug log if we aren't using cyaml, I'm trying to test it out now
<mup> PR #325: ops/main.py: Use CSafeLoader <Created by jameinel> <https://github.com/canonical/operator/pull/325>
<Chipaca> jam: nice
<Chipaca> now i think i need to get ready for a meeting
<Chipaca> and by 'get ready' i mean 'put a shirt on'
<jam> yeah, in 5min, right?
<Chipaca> yeah
<mthaddon> just thought you guys might be interested to know https://blog.launchpad.net/ is live with an operator charm on k8s (https://code.launchpad.net/charm-k8s-wordpress)
<mthaddon> t0mb0 put it live earlier today ^
<jam> mthaddon, very nice to hear
<Chipaca> mthaddon: nice
<Chipaca> mthaddon: how's the mattermost one coming along?
<mthaddon> Chipaca: it's up and running, but still in preview mode (getting themes and plugins in place, etc.)
<Chipaca> mthaddon: good one
<jam> Chipaca, are you happy with the wording of that log message?
<jam> Chipaca, I'm not sure how to test it, as yaml that comes by default on Ubuntu images has cyaml available
<Chipaca> jam: import yaml; _nukularize(yaml); main(Charm) --> ooh look a logline
<Chipaca> jam: granted i'm not sure how much value that adds, as a test :)
<jam> Chipaca, I was more meaning testing it practically that it actually shows up, etc. but yeah, I can add a test of main directly
<Chipaca> jam: alternatively we could have an integration test that creates its own venv
<Chipaca> jam: it feels like on the outside of what's a reasonable integration-in-unit-dress test
<jam> Chipaca, yeah, it was mostly that I wanted to deploy something in a fashion that caused it to trigger, so I could see how obvious it was what was going on.
<Chipaca> jam: a charm with PyYAML in its requirements.txt should end up with a non-libyaml yaml unless you're very careful
<jam> Chipaca, because you have to have the -dev package installed before fulfilling requirements?
<Chipaca> there isn't yet code in charmcraft to not ship PyYAML in the generated env
<Chipaca> jam: and cython
<jam> Chipaca, and build-essential, right?
<jam> (that's one of the big things we're trying to avoid :)
<Chipaca> jam: i'm thinking of when you 'charmcraft build' it
<Chipaca> jam: meaning you'd need those things on the build machine, but not in the run machine
<jam> Chipaca, so how does that work across series?
<Chipaca> jam: perfectly
 * Chipaca hides
<Chipaca> jam: sorry, what do you mean in particular?
<jam> Chipaca, I'm just thinking of "I wrote a charm, and I want to support bionic and focal"
<Chipaca> jam: we're ignoring that until the new api supports platform properly
<jam> Chipaca, if we are defaulting to a venv that *doesn't* have system libs, then you can't get compiled extensions from the platform
<jam> I keep coming around to if 'charmcraft build' is doing too much, it has to fill too many holes
<Chipaca> jam: but if you run on the same python as you build you should be able to get .so things even now
<Chipaca> jam: the plan is that a charm is platform-specific, and built N times once per platform, so hopefully that makes it simpler :)
<Chipaca> a .charm i mean, the built artifact
<Chipaca> that's where the launchpad builders come in, also
<Chipaca> and 'charmcraft remote'
<facubatista> Muy buenos dÃ­as a todos!
<Chipaca> facubatista: o/! :-)
<facubatista> hola Chipaca :)
<Chipaca> jam: is there a reason but main.main and model._ModelBackend get the unit name from the environ?
<Chipaca> facubatista: when you have time to look at a long and complicated PR, 326 is there for you
<facubatista> Chipaca, ack
<jam> Chipaca, I don't quite follow. "is there a reason they get the model name from the environ"?
<Chipaca> jam: main.main does gets JUJU_MODEL_NAME from the environ, passes it into model.Model, which then creates a _ModelBackend which again gets the model name from the environ
<Chipaca> er
<Chipaca> jam: UNIT_NAME i meant sorry
<jam> Chipaca, ... I'm not a big fan of 'model' code reading from os.environ. I feel it should be encapsulated at a layer, but not spread throughout the code. That said, I feel like either main() or Backend could be that layer
<jam> Chipaca, I did the main() one, someone else did the UNIT_NAME one. I could be convinced that we should move it to ModelBackend
<jam> What I don't want is Model itself to look at environ
<Chipaca> agreed on that at least :)
<jam> Chipaca, fwiw, I'm not super happy about 4+ arguments on Model
<jam> Chipaca, I just noticed that main() actually grabs both UNIT and MODEL and then passes them in, to which ModelBackend rereads UNIT name rather than taking it as an arg
<jam> Chipaca, what would you prefer? Should we move the environ call out of ModelBackend and pass the unit name in?
<jam> Chipaca, or would you rather the Model read the unit name from the backend ?
<Chipaca> jam: haven't decided what i prefer yet, i just noticed the duplication and thought to ask if there was context for it
<mup> Issue operator#32 closed: The charm tool should offer an initial skeleton <Created by woutervb> <https://github.com/canonical/operator/issues/32>
<Chipaca> niemeyer: when you 'transfer' an issue in github, mup gets confused about its url ^ (that is now issue 32 in charmcraft, but it was a different number in operator)
<mup> PR #32: Implement interface base layer with examples <Created by johnsca> <Closed by niemeyer> <https://github.com/canonical/operator/pull/32>
<mup> Issue operator#240 closed: Shared StoredState between kubernetes workload pods <Created by davigar15> <Closed by jameinel> <https://github.com/canonical/operator/issues/240>
<davigar15> jam: Is the issue solved ^
<jam> davigar15, 240 is a duplicate of 317 so I closed it to avoid having 2 bugs. I'm actively working on it now.
<mup> Issue operator#291 closed: Log event re-emission <bug> <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/291>
<davigar15> great!
<davigar15> sorry, i didn't see the duplicated message :-)
<jam> Chipaca, given the earlier discussion: https://github.com/canonical/operator/pull/327
<mup> PR #327: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>
<jam> It moves both unit name and model name to be read from the backend, and cleans up things quite a bit IMO
<mup> PR operator#327 opened: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>
<facubatista> Chipaca, where, the meeting?
<Chipaca> facubatista: standup?
<facubatista> Chipaca, so, how do we proceed about the CLA thing
<facubatista> ?
<Chipaca> facubatista: in particular, or in general?
<facubatista> Chipaca, for charmcraft
<facubatista> Chipaca, shall we put a travis thing?
<Chipaca> facubatista: we shall, if nothing better works
<Chipaca> facubatista: i'
<Chipaca> facubatista: i've reached out to other managers to find out if anything easier is working
<Chipaca> there are CLA-signing web services that integrate with github
<Chipaca> but i suspect they don't work with our CLA
<facubatista> Chipaca, ack; in the meantime, we should tell this person to sign that somehow?
<Chipaca> facubatista: i already have
<facubatista> Chipaca, thanks
<facubatista> Chipaca, regarding upload-status, there's no harm in making that publicly available, it could be "hidden from the normal help", or even present in the normal help but in an "advanced" section
<Chipaca> facubatista: I wouldn't expose it until we're sure we want to support it
<facubatista> Chipaca, we need to automatic do that after an upload, until "all is green", but if the developer issues that at any moment, it's fine
<Chipaca> facubatista: but for them to do that we'd need to print that long upload id for them to use
<Chipaca> and that sounds like a bad idea
<facubatista> mmm... ok, let's see later
<facubatista> Chipaca, I added four cards to the "core backlog" column (they're in the bottom), after separating all the commands we talked about in four groups
<facubatista> Chipaca, we may put those in a new "charmcraft" column?
<Chipaca> thank you
<Chipaca> yeah
<facubatista> Chipaca, I do it
<Chipaca> facubatista: thank you
<Chipaca> facubatista: i'm going to head out shortly. Anything you need from me?
<facubatista> Chipaca, sorry, was lunching; when you have some minutes for the comments in the Charm packaging spec it would be great, thanks
<facubatista> *having lunch
<Cynerva_> does charmcraft include config.yaml in built charms? i've got a config.yaml alongside metadata.yaml but the .charm file produced by `charmcraft build` doesn't seem to include it
<facubatista> Cynerva_, not yet, we have a PR that will bring that soon
<Cynerva_> ack, thanks
<Cynerva_> ah yep there it is https://github.com/canonical/charmcraft/pull/31
<mup> PR charmcraft#31: Include config.yaml in built charm <Created by charness> <https://github.com/canonical/charmcraft/pull/31>
 * facubatista eods
#smooth-operator 2020-06-12
<facubatista> Muy buenos dÃ­as a todos!
<mup> Issue operator#328 opened: k8s charm throws a "not found" error when invoking the action <Created by exceptorr> <https://github.com/canonical/operator/issues/328>
 * facubatista eods, and will be off on Monday, so see you all on Tuesday!
