[08:25] <Chipaca> hellooooo
[08:26] <jam> morning Chipaca
[08:26] <Chipaca> hi jam
[08:31] <Chipaca> jam: did we have anything to review for today's meeting?
[08:33] <jam> Chipaca, probably would be good to think about a policy wrt mocking multiple interactions
[08:52] <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
[08:52] <mup> PR #325: ops/main.py: Use CSafeLoader <Created by jameinel> <https://github.com/canonical/operator/pull/325>
[08:53] <Chipaca> jam: nice
[08:53] <Chipaca> now i think i need to get ready for a meeting
[08:53] <Chipaca> and by 'get ready' i mean 'put a shirt on'
[08:53] <jam> yeah, in 5min, right?
[08:53] <Chipaca> yeah
[09:17] <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)
[09:19] <mthaddon> t0mb0 put it live earlier today ^
[09:23] <jam> mthaddon, very nice to hear
[09:29] <Chipaca> mthaddon: nice
[09:29] <Chipaca> mthaddon: how's the mattermost one coming along?
[09:30] <mthaddon> Chipaca: it's up and running, but still in preview mode (getting themes and plugins in place, etc.)
[09:31] <Chipaca> mthaddon: good one
[09:32] <jam> Chipaca, are you happy with the wording of that log message?
[09:33] <jam> Chipaca, I'm not sure how to test it, as yaml that comes by default on Ubuntu images has cyaml available
[09:34] <Chipaca> jam: import yaml; _nukularize(yaml); main(Charm) --> ooh look a logline
[09:35] <Chipaca> jam: granted i'm not sure how much value that adds, as a test :)
[09:35] <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
[09:36] <Chipaca> jam: alternatively we could have an integration test that creates its own venv
[09:37] <Chipaca> jam: it feels like on the outside of what's a reasonable integration-in-unit-dress test
[09:44] <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.
[09:49] <Chipaca> jam: a charm with PyYAML in its requirements.txt should end up with a non-libyaml yaml unless you're very careful
[09:50] <jam> Chipaca, because you have to have the -dev package installed before fulfilling requirements?
[09:50] <Chipaca> there isn't yet code in charmcraft to not ship PyYAML in the generated env
[09:50] <Chipaca> jam: and cython
[09:50] <jam> Chipaca, and build-essential, right?
[09:50] <jam> (that's one of the big things we're trying to avoid :)
[09:51] <Chipaca> jam: i'm thinking of when you 'charmcraft build' it
[09:51] <Chipaca> jam: meaning you'd need those things on the build machine, but not in the run machine
[10:05] <jam> Chipaca, so how does that work across series?
[10:05] <Chipaca> jam: perfectly
[10:05]  * Chipaca hides
[10:06] <Chipaca> jam: sorry, what do you mean in particular?
[10:06] <jam> Chipaca, I'm just thinking of "I wrote a charm, and I want to support bionic and focal"
[10:07] <Chipaca> jam: we're ignoring that until the new api supports platform properly
[10:07] <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
[10:08] <jam> I keep coming around to if 'charmcraft build' is doing too much, it has to fill too many holes
[10:08] <Chipaca> jam: but if you run on the same python as you build you should be able to get .so things even now
[10:08] <Chipaca> jam: the plan is that a charm is platform-specific, and built N times once per platform, so hopefully that makes it simpler :)
[10:09] <Chipaca> a .charm i mean, the built artifact
[10:09] <Chipaca> that's where the launchpad builders come in, also
[10:09] <Chipaca> and 'charmcraft remote'
[11:30] <facubatista> Muy buenos días a todos!
[11:42] <Chipaca> facubatista: o/! :-)
[11:46] <facubatista> hola Chipaca :)
[11:46] <Chipaca> jam: is there a reason but main.main and model._ModelBackend get the unit name from the environ?
[11:47] <Chipaca> facubatista: when you have time to look at a long and complicated PR, 326 is there for you
[11:49] <facubatista> Chipaca, ack
[11:52] <jam> Chipaca, I don't quite follow. "is there a reason they get the model name from the environ"?
[11:53] <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
[11:53] <Chipaca> er
[11:53] <Chipaca> jam: UNIT_NAME i meant sorry
[11:53] <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
[11:54] <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
[11:54] <jam> What I don't want is Model itself to look at environ
[11:55] <Chipaca> agreed on that at least :)
[11:58] <jam> Chipaca, fwiw, I'm not super happy about 4+ arguments on Model
[12:01] <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
[12:01] <jam> Chipaca, what would you prefer? Should we move the environ call out of ModelBackend and pass the unit name in?
[12:01] <jam> Chipaca, or would you rather the Model read the unit name from the backend ?
[12:01] <Chipaca> jam: haven't decided what i prefer yet, i just noticed the duplication and thought to ask if there was context for it
[12:15] <mup> Issue operator#32 closed: The charm tool should offer an initial skeleton <Created by woutervb> <https://github.com/canonical/operator/issues/32>
[12:42] <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)
[12:42] <mup> PR #32: Implement interface base layer with examples <Created by johnsca> <Closed by niemeyer> <https://github.com/canonical/operator/pull/32>
[12:53] <mup> Issue operator#240 closed: Shared StoredState between kubernetes workload pods <Created by davigar15> <Closed by jameinel> <https://github.com/canonical/operator/issues/240>
[12:55] <davigar15> jam: Is the issue solved ^
[12:55] <jam> davigar15, 240 is a duplicate of 317 so I closed it to avoid having 2 bugs. I'm actively working on it now.
[12:55] <mup> Issue operator#291 closed: Log event re-emission <bug> <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/291>
[12:56] <davigar15> great!
[12:56] <davigar15> sorry, i didn't see the duplicated message :-)
[13:24] <jam> Chipaca, given the earlier discussion: https://github.com/canonical/operator/pull/327
[13:24] <mup> PR #327: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>
[13:24] <jam> It moves both unit name and model name to be read from the backend, and cleans up things quite a bit IMO
[13:25] <mup> PR operator#327 opened: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>
[15:00] <facubatista> Chipaca, where, the meeting?
[15:00] <Chipaca> facubatista: standup?
[15:41] <facubatista> Chipaca, so, how do we proceed about the CLA thing
[15:41] <facubatista> ?
[15:41] <Chipaca> facubatista: in particular, or in general?
[15:42] <facubatista> Chipaca, for charmcraft
[15:42] <facubatista> Chipaca, shall we put a travis thing?
[15:42] <Chipaca> facubatista: we shall, if nothing better works
[15:42] <Chipaca> facubatista: i'
[15:43] <Chipaca> facubatista: i've reached out to other managers to find out if anything easier is working
[15:43] <Chipaca> there are CLA-signing web services that integrate with github
[15:43] <Chipaca> but i suspect they don't work with our CLA
[15:43] <facubatista> Chipaca, ack; in the meantime, we should tell this person to sign that somehow?
[15:43] <Chipaca> facubatista: i already have
[15:43] <facubatista> Chipaca, thanks
[15:51] <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
[15:52] <Chipaca> facubatista: I wouldn't expose it until we're sure we want to support it
[15:52] <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
[15:52] <Chipaca> facubatista: but for them to do that we'd need to print that long upload id for them to use
[15:52] <Chipaca> and that sounds like a bad idea
[15:53] <facubatista> mmm... ok, let's see later
[15:57] <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
[15:57] <facubatista> Chipaca, we may put those in a new "charmcraft" column?
[15:57] <Chipaca> thank you
[15:57] <Chipaca> yeah
[15:57] <facubatista> Chipaca, I do it
[16:08] <Chipaca> facubatista: thank you
[16:46] <Chipaca> facubatista: i'm going to head out shortly. Anything you need from me?
[17:20] <facubatista> Chipaca, sorry, was lunching; when you have some minutes for the comments in the Charm packaging spec it would be great, thanks
[17:45] <facubatista> *having lunch
[19:03] <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
[20:02] <facubatista> Cynerva_, not yet, we have a PR that will bring that soon
[20:17] <Cynerva_> ack, thanks
[20:18] <Cynerva_> ah yep there it is https://github.com/canonical/charmcraft/pull/31
[20:18] <mup> PR charmcraft#31: Include config.yaml in built charm <Created by charness> <https://github.com/canonical/charmcraft/pull/31>
[20:54]  * facubatista eods