| Chipaca | hellooooo | 08:25 |
|---|---|---|
| jam | morning Chipaca | 08:26 |
| Chipaca | hi jam | 08:26 |
| Chipaca | jam: did we have anything to review for today's meeting? | 08:31 |
| jam | Chipaca, probably would be good to think about a policy wrt mocking multiple interactions | 08:33 |
| 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:52 |
| 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 | 08:53 |
| 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:17 |
| mthaddon | t0mb0 put it live earlier today ^ | 09:19 |
| jam | mthaddon, very nice to hear | 09:23 |
| Chipaca | mthaddon: nice | 09:29 |
| Chipaca | mthaddon: how's the mattermost one coming along? | 09:29 |
| mthaddon | Chipaca: it's up and running, but still in preview mode (getting themes and plugins in place, etc.) | 09:30 |
| Chipaca | mthaddon: good one | 09:31 |
| jam | Chipaca, are you happy with the wording of that log message? | 09:32 |
| jam | Chipaca, I'm not sure how to test it, as yaml that comes by default on Ubuntu images has cyaml available | 09:33 |
| Chipaca | jam: import yaml; _nukularize(yaml); main(Charm) --> ooh look a logline | 09:34 |
| 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:35 |
| Chipaca | jam: alternatively we could have an integration test that creates its own venv | 09:36 |
| Chipaca | jam: it feels like on the outside of what's a reasonable integration-in-unit-dress test | 09:37 |
| 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:44 |
| Chipaca | jam: a charm with PyYAML in its requirements.txt should end up with a non-libyaml yaml unless you're very careful | 09:49 |
| 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:50 |
| 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 | 09:51 |
| jam | Chipaca, so how does that work across series? | 10:05 |
| Chipaca | jam: perfectly | 10:05 |
| * Chipaca hides | 10:05 | |
| 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:06 |
| 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:07 |
| 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:08 |
| 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' | 10:09 |
| facubatista | Muy buenos días a todos! | 11:30 |
| Chipaca | facubatista: o/! :-) | 11:42 |
| 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:46 |
| Chipaca | facubatista: when you have time to look at a long and complicated PR, 326 is there for you | 11:47 |
| facubatista | Chipaca, ack | 11:49 |
| jam | Chipaca, I don't quite follow. "is there a reason they get the model name from the environ"? | 11:52 |
| 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:53 |
| 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:54 |
| Chipaca | agreed on that at least :) | 11:55 |
| jam | Chipaca, fwiw, I'm not super happy about 4+ arguments on Model | 11:58 |
| 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:01 |
| mup | Issue operator#32 closed: The charm tool should offer an initial skeleton <Created by woutervb> <https://github.com/canonical/operator/issues/32> | 12:15 |
| 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:42 |
| 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:53 |
| 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:55 |
| davigar15 | great! | 12:56 |
| davigar15 | sorry, i didn't see the duplicated message :-) | 12:56 |
| 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:24 |
| mup | PR operator#327 opened: many: move Model.name to be read from _ModelBackend <Created by jameinel> <https://github.com/canonical/operator/pull/327> | 13:25 |
| facubatista | Chipaca, where, the meeting? | 15:00 |
| Chipaca | facubatista: standup? | 15:00 |
| facubatista | Chipaca, so, how do we proceed about the CLA thing | 15:41 |
| facubatista | ? | 15:41 |
| Chipaca | facubatista: in particular, or in general? | 15:41 |
| 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:42 |
| 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:43 |
| 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:51 |
| 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:52 |
| facubatista | mmm... ok, let's see later | 15:53 |
| 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 | 15:57 |
| Chipaca | facubatista: thank you | 16:08 |
| Chipaca | facubatista: i'm going to head out shortly. Anything you need from me? | 16:46 |
| facubatista | Chipaca, sorry, was lunching; when you have some minutes for the comments in the Charm packaging spec it would be great, thanks | 17:20 |
| facubatista | *having lunch | 17: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 it | 19:03 |
| facubatista | Cynerva_, not yet, we have a PR that will bring that soon | 20:02 |
| Cynerva_ | ack, thanks | 20:17 |
| 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:18 |
| * facubatista eods | 20:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!