[13:48] power is back! [13:48] ¡Muy buenos días a todos! [13:49] * facubatista got the power! https://www.youtube.com/watch?v=j1BNcSBApOU [13:55] jam, hello! did you see alejdg question from yesterday? [14:12] alejdg, I'd have to see how you are defining your pod spec, my guess is that you should be setting a single container pod spec, and that Juju would handle the 'count' portion. I'm not sure how you're trying to distinguish specifics for each unit [14:12] thanks facubatista I had missed it. [14:14] jam, my plan is to review all issues, delay current ones marked with milestone 0.3.0 to 0.4.0, except anything that we want to include this week [14:14] jam, I'll check out your PR first, see if we can land it, and then maybe change build to use it, so we start including everything in the project? [14:15] sgtm [14:18] jam, travis is not happy with your branch... [14:22] facubatista, thanks for the heads up, looking [14:23] looks like a 3.5ism [14:23] pathlib.Path *sigh* [14:26] yes, 3.5 [14:27] jam, after you deal with that, let's have a HO to sync? just ping me, thanks! [14:36] I've heard about harness being the new way to do unit tests with the ops framework. Is there any documentation out there about it ? [14:39] crodriguez__, don't think so, but maybe we can provide you with examples? [14:49] facubatista, yeah, anything that could help [14:50] Hello ! [14:52] hello ballot [15:04] any link you could share facubatista ? [15:08] crodriguez__, 5' [15:21] crodriguez__, https://paste.ubuntu.com/p/67Hcd5yPT3/ [15:22] jam, let me know if we can talk at some point today so I organize myself [15:37] thank you facubatista [16:57] jam: How would I set specific secrets for each unit? Is there a way to do that? [18:59] I don't understand harness... I thought it was supposed to mock the charm? But it looks like it is executing functions of the charm directly on my system instead. For example, I am testing harness.update_config , which triggers render_config in my charm. render_config, amongts other things, tries to create a directory in /etc/, which is denied because of lack of permissions [20:14] crodriguez_, we'll need help from jam for that :/ [20:18] facubatista, is he on PTO? [20:22] crodriguez_, nop, but we'll need to wait for tomorrow [20:30] Ok facubatista, thanks for the info. I might schedule a meeting/work session for that [20:32] crodriguez_, nice [20:46] @crodriguez_: Re: your questions about operator framework - if you don't mind, I'm going to paraphrase a few of the questions here [20:47] I missed backscroll in this channel as I just joined [20:48] Your main question was: operator framework is supposed to mock the charm, thus why is it running stuff directly on your box? ...Is that a fair way of rephrasing, or did I miss something? [20:48] "For example, I am testing harness.update_config , which triggers render_config in my charm. render_config, amongts other things, tries to create a directory in /etc/, which is denied because of lack of permissions" [20:48] pretty much yeah vultaire2 [20:48] yeah, you've got it, vultaire2 [20:49] * drewn3ss is wondering iif you still need to mock things like the render as we do in reactive unit tests [20:49] * crodriguez_ wondering the same thing :) [20:51] Sorry for the delay here, jumping around a bit... [20:51] So, basically: it is mocking a lot of the stuff. You could kind of say it lets you test functions of your charm code without juju running underneath it [20:52] that being said, it's not any sort of virtualization or anything like that, it's not spinning up containers or anything - all code _is_ running locally on your machine [20:53] with normal unit testing, you're typically running single functions directly on your development system, perhaps mocking out areas where the code does things you don't want it to (like talking to a DB, for example) [20:53] basically, with unit testing you're trying to test one function, or a small area of code, in isolation from the rest of the code [20:54] Now, this is normally pretty difficult with charms, especially pre-operator charms, as there's a lot of stuff running "under" them [20:54] all the juju binaries and such which get called behind the scenes [20:54] if you're just running unit tests and not doing a full end-to-end integration test, you typically don't want that, and thus you end up having to mock out stuff. Lots of stuff. [20:55] With operator framework, a large amount of that is effectively mocked out for you [20:56] Just like with non-juju unit tests, your tests run on your machine. So if your charm does things that you don't want modifying your system environment (like installing packages), you'll still need to mock those bits out [20:57] ...Let me stop here. Does this make sense somewhat? [20:57] so, harness isn't providing a mocked virtual environment in total, but rather mocking out the juju layer in general? [20:57] ok, thanks for the explanation. Yes that makes sense, I'll need to mock out some functions so it doesn't mess up my system haha.. [20:57] yes [20:57] your video is helpful too with the examples! [20:58] I'll give it another shot and might ask more precise questions when I hit blockers [20:58] crodriguez_: you might look to the unit tests I was just poking at for mock_render https://git.launchpad.net/charm-prometheus-ceph-exporter/tree/tests/unit/test_reactive_ceph_exporter.py#n95 [20:58] Sounds good, please do and best of luck [20:59] it's not operator, but maybe some of that code will help you mock the render [21:00] thanks drewn3ss! [21:06] vultaire, drewn3ss, thanks! [21:19] * facubatista eods