jammorning Chipaca08:26
Chipacahi jam08:26
Chipacajam: did we have anything to review for today's meeting?08:31
jamChipaca, probably would be good to think about a policy wrt mocking multiple interactions08:33
jamChipaca, 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 now08:52
mupPR #325: ops/main.py: Use CSafeLoader <Created by jameinel> <https://github.com/canonical/operator/pull/325>08:52
Chipacajam: nice08:53
Chipacanow i think i need to get ready for a meeting08:53
Chipacaand by 'get ready' i mean 'put a shirt on'08:53
jamyeah, in 5min, right?08:53
mthaddonjust 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:17
mthaddont0mb0 put it live earlier today ^09:19
jammthaddon, very nice to hear09:23
Chipacamthaddon: nice09:29
Chipacamthaddon: how's the mattermost one coming along?09:29
mthaddonChipaca: it's up and running, but still in preview mode (getting themes and plugins in place, etc.)09:30
Chipacamthaddon: good one09:31
jamChipaca, are you happy with the wording of that log message?09:32
jamChipaca, I'm not sure how to test it, as yaml that comes by default on Ubuntu images has cyaml available09:33
Chipacajam: import yaml; _nukularize(yaml); main(Charm) --> ooh look a logline09:34
Chipacajam: granted i'm not sure how much value that adds, as a test :)09:35
jamChipaca, I was more meaning testing it practically that it actually shows up, etc. but yeah, I can add a test of main directly09:35
Chipacajam: alternatively we could have an integration test that creates its own venv09:36
Chipacajam: it feels like on the outside of what's a reasonable integration-in-unit-dress test09:37
jamChipaca, 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:44
Chipacajam: a charm with PyYAML in its requirements.txt should end up with a non-libyaml yaml unless you're very careful09:49
jamChipaca, because you have to have the -dev package installed before fulfilling requirements?09:50
Chipacathere isn't yet code in charmcraft to not ship PyYAML in the generated env09:50
Chipacajam: and cython09:50
jamChipaca, and build-essential, right?09:50
jam(that's one of the big things we're trying to avoid :)09:50
Chipacajam: i'm thinking of when you 'charmcraft build' it09:51
Chipacajam: meaning you'd need those things on the build machine, but not in the run machine09:51
jamChipaca, so how does that work across series?10:05
Chipacajam: perfectly10:05
* Chipaca hides10:05
Chipacajam: sorry, what do you mean in particular?10:06
jamChipaca, I'm just thinking of "I wrote a charm, and I want to support bionic and focal"10:06
Chipacajam: we're ignoring that until the new api supports platform properly10:07
jamChipaca, if we are defaulting to a venv that *doesn't* have system libs, then you can't get compiled extensions from the platform10:07
jamI keep coming around to if 'charmcraft build' is doing too much, it has to fill too many holes10:08
Chipacajam: but if you run on the same python as you build you should be able to get .so things even now10:08
Chipacajam: the plan is that a charm is platform-specific, and built N times once per platform, so hopefully that makes it simpler :)10:08
Chipacaa .charm i mean, the built artifact10:09
Chipacathat's where the launchpad builders come in, also10:09
Chipacaand 'charmcraft remote'10:09
facubatistaMuy buenos días a todos!11:30
Chipacafacubatista: o/! :-)11:42
facubatistahola Chipaca :)11:46
Chipacajam: is there a reason but main.main and model._ModelBackend get the unit name from the environ?11:46
Chipacafacubatista: when you have time to look at a long and complicated PR, 326 is there for you11:47
facubatistaChipaca, ack11:49
jamChipaca, I don't quite follow. "is there a reason they get the model name from the environ"?11:52
Chipacajam: 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 environ11:53
Chipacajam: UNIT_NAME i meant sorry11:53
jamChipaca, ... 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 layer11:53
jamChipaca, I did the main() one, someone else did the UNIT_NAME one. I could be convinced that we should move it to ModelBackend11:54
jamWhat I don't want is Model itself to look at environ11:54
Chipacaagreed on that at least :)11:55
jamChipaca, fwiw, I'm not super happy about 4+ arguments on Model11:58
jamChipaca, 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 arg12:01
jamChipaca, what would you prefer? Should we move the environ call out of ModelBackend and pass the unit name in?12:01
jamChipaca, or would you rather the Model read the unit name from the backend ?12:01
Chipacajam: haven't decided what i prefer yet, i just noticed the duplication and thought to ask if there was context for it12:01
mupIssue operator#32 closed: The charm tool should offer an initial skeleton <Created by woutervb> <https://github.com/canonical/operator/issues/32>12:15
Chipacaniemeyer: 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
mupPR #32: Implement interface base layer with examples <Created by johnsca> <Closed by niemeyer> <https://github.com/canonical/operator/pull/32>12:42
mupIssue operator#240 closed: Shared StoredState between kubernetes workload pods <Created by davigar15> <Closed by jameinel> <https://github.com/canonical/operator/issues/240>12:53
davigar15jam: Is the issue solved ^12:55
jamdavigar15, 240 is a duplicate of 317 so I closed it to avoid having 2 bugs. I'm actively working on it now.12:55
mupIssue operator#291 closed: Log event re-emission <bug> <Created by chipaca> <Closed by chipaca> <https://github.com/canonical/operator/issues/291>12:55
davigar15sorry, i didn't see the duplicated message :-)12:56
jamChipaca, given the earlier discussion: https://github.com/canonical/operator/pull/32713:24
mupPR #327: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>13:24
jamIt moves both unit name and model name to be read from the backend, and cleans up things quite a bit IMO13:24
mupPR operator#327 opened: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327>13:25
facubatistaChipaca, where, the meeting?15:00
Chipacafacubatista: standup?15:00
facubatistaChipaca, so, how do we proceed about the CLA thing15:41
Chipacafacubatista: in particular, or in general?15:41
facubatistaChipaca, for charmcraft15:42
facubatistaChipaca, shall we put a travis thing?15:42
Chipacafacubatista: we shall, if nothing better works15:42
Chipacafacubatista: i'15:42
Chipacafacubatista: i've reached out to other managers to find out if anything easier is working15:43
Chipacathere are CLA-signing web services that integrate with github15:43
Chipacabut i suspect they don't work with our CLA15:43
facubatistaChipaca, ack; in the meantime, we should tell this person to sign that somehow?15:43
Chipacafacubatista: i already have15:43
facubatistaChipaca, thanks15:43
facubatistaChipaca, 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" section15:51
Chipacafacubatista: I wouldn't expose it until we're sure we want to support it15:52
facubatistaChipaca, we need to automatic do that after an upload, until "all is green", but if the developer issues that at any moment, it's fine15:52
Chipacafacubatista: but for them to do that we'd need to print that long upload id for them to use15:52
Chipacaand that sounds like a bad idea15:52
facubatistammm... ok, let's see later15:53
facubatistaChipaca, I added four cards to the "core backlog" column (they're in the bottom), after separating all the commands we talked about in four groups15:57
facubatistaChipaca, we may put those in a new "charmcraft" column?15:57
Chipacathank you15:57
facubatistaChipaca, I do it15:57
Chipacafacubatista: thank you16:08
Chipacafacubatista: i'm going to head out shortly. Anything you need from me?16:46
facubatistaChipaca, sorry, was lunching; when you have some minutes for the comments in the Charm packaging spec it would be great, thanks17:20
facubatista*having lunch17:45
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 it19:03
facubatistaCynerva_, not yet, we have a PR that will bring that soon20:02
Cynerva_ack, thanks20:17
Cynerva_ah yep there it is https://github.com/canonical/charmcraft/pull/3120:18
mupPR charmcraft#31: Include config.yaml in built charm <Created by charness> <https://github.com/canonical/charmcraft/pull/31>20:18
* facubatista eods20:54

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!