[04:16] <jam> morning all
[04:25] <Dmitrii-Sh> moring jam
[04:26] <Dmitrii-Sh> morning*
[07:24] <t0mb0> are there any examples for testing operator charms?
[07:32] <Dmitrii-Sh> t0mb0: we have PRs for interfaces with unit tests that use the test harness which was recently merged (https://github.com/canonical/operator/pull/146/files)
[07:34] <Dmitrii-Sh> I am working on getting my interface PRs to a better state and will then switch my charm PRs
[07:34] <Dmitrii-Sh> https://github.com/canonical/cockroachdb-operator/pull/1/files - this charm PR has unit tests but they are for the peer relation
[07:36] <Dmitrii-Sh> I have a task to make it more modular so that I can test it in isolation from the operations that mutate the underlying machine and calls to network-get which are not yet handled by the harness
[07:37] <Dmitrii-Sh> t0mb0: sorry it's at that stage right now but I am doing what I can to move it forward
[07:41] <mthaddon> Dmitrii-Sh: how much are you expecting in the way of changes to how testing is done in the framework? Just wondering if it's worth us / t0mb0 investing time in beginning to write tests now, or whether we should hold off for a bit
[07:42] <mthaddon> test/test_cluster.py certainly looks like it has some useful examples from https://github.com/canonical/cockroachdb-operator/pull/1/files but just want to confirm how much we'd expect things to change at this point
[07:45] <Dmitrii-Sh> mthaddon: I would expect remote_app_data parameter to disappear here https://github.com/canonical/operator/blob/11a1849205d750e28aaa4a13938b5864659f928b/ops/testing.py#L143 per a discussion in https://github.com/canonical/operator/issues/211 but so far I am not aware of any other changes.
[07:45] <Dmitrii-Sh> I think it's worthwhile to start using the harness as-is
[07:46] <mthaddon> Dmitrii-Sh: thx - sounds like some minor changes, but certainly worth getting started with it. t0mb0 ^
[07:47] <niemeyer> Morning all
[07:48] <Dmitrii-Sh> morning
[07:48] <niemeyer> mthaddon, t0mb0: If you find any issues / struggles with the harness, this is a good time to raise them
[07:48] <niemeyer> jam has been pushing it forward and polishing it as we go
[07:49] <mthaddon> thx
[07:50] <t0mb0> no worries will dpo
[07:50] <t0mb0> *do
[08:30] <niemeyer> jam: Second review on #209
[08:35] <Chipaca> moin moin moin
[08:36] <jam> thanks niemeyer
[08:36] <jam> morning Chipaca
[08:38] <niemeyer> Chipaca: Morning!
[08:38] <niemeyer> Chipaca: You just got another review on #203
[08:38] <Chipaca> niemeyer: 👍
[09:30] <niemeyer> jam: You have another review on #196 as well
[09:54]  * Chipaca takes a break
[10:36] <Chipaca> dang, i messed up the revue thing
[11:13] <Dmitrii-Sh> Updated 216. I got rid of pickle but we still need to discuss serialization.
[11:13] <facubatista> Muy buenos días a todos!
[11:14] <Dmitrii-Sh> facubatista o/
[11:14] <Chipaca> facubatista: buen día!
[11:14] <facubatista> hola Dmitrii-Sh, Chipaca :)
[11:14] <Chipaca> I'm off to make lunch for m'boys
[11:14] <niemeyer> Off to lunch as well
[11:15] <facubatista> have a nice lunch!
[11:54] <t0mb0> Dmitrii-Sh, is state something that the harness supports? https://pastebin.canonical.com/p/V44mnMF9NK/ I've tried to pass my charm to the harness but it seems to trip up creating the state attribute
[11:55] <jam> t0mb0, https://github.com/canonical/operator/pull/199
[11:55] <jam> probably you just need to update your operator directory
[11:56] <Dmitrii-Sh> t0mb0: jam speaks the truth :^)
[11:56] <t0mb0> well thats easy!
[11:57] <Dmitrii-Sh> t0mb0: git submodule update --recursive --remote
[11:57] <Dmitrii-Sh> that's one way to update all of your submodules
[12:04] <t0mb0> \o/ works
[12:06] <Dmitrii-Sh> great!
[12:12]  * facubatista brb, doorbell
[12:17] <jam> facubatista, ping me when you'are back
[12:56]  * facubatista is back
[12:56] <facubatista> sorry it took long, it was the meat delivery
[12:56]  * niemeyer is sort of back too.. starting the meeting marathon
[12:58] <facubatista> jam, ping, I'm back :)
[13:02] <jam> hi facubatista, just hitting my meetings now as well. I wanted to check up on https://github.com/canonical/operator/pull/209
[13:03] <jam> Dmitrii-Sh, it seems https://bugs.launchpad.net/juju/+bug/1854635 didn't actually get backported. So it will be in 2.7.6 (landed today)
[13:04] <Dmitrii-Sh> jam: ok, then my tests were sane
[13:04] <facubatista> jam, we initiated a conversation in IRC, so for that to not be forgotten, I wrote this comment: https://github.com/canonical/operator/pull/209#issuecomment-609983367
[13:04] <Chipaca> Dmitrii-Sh: huzzah for sane tests
[13:05] <facubatista> jam, I kind of was expecting to continue the conversation there
[13:05] <jam> facubatista, hence why I pinged, but we'll chat after standup, I guess, since I can't chat live very well right now.
[13:05] <jam> I did intend to discuss it
[13:05] <jam> just ran out of time before meetings.
[13:05] <facubatista> jam, ah, perfect
[13:28] <jam> facubatista, if I understand you correctly, you're happy with the behavior, but you feel it is more obvious to pass a boolean rather than having a stream that isn't None indicating that you want the new behavior?
[13:31] <facubatista> jam, it's more about which part is deciding what... if you call setuplogging and say debug=True, is fine to that setup function to decide a level and a stream; it's weird that the stream is decided outside, and that according to that stream debug is implied (this opens a lot of questions, what if the external caller want that stream but in info, etc)
[13:31] <Chipaca> facubatista: stand up
[14:18] <jam> facubatista, so if it feels cleaner to you, go back to a boolean, and make the decisions internally again?
[14:20] <jam> I definitely prefer the env var to be evaluated in main(), but I can live with passing debug as a bool and having that decide to add a debug level log handler.
[14:22] <facubatista> jam, it feels cleaner to me to go back to the external caller saying "I want logs in debug mode" (with a bool), and the setup code internally deciding what "debug mode" means, for us here is DEBUG level and also send logs to stderr
[14:22] <facubatista> jam, the env var is perfect to be evaluated in main, yes
[14:22] <facubatista> (the main code may decide "go to debug mode" for several reasons in the future)
[14:23] <facubatista> so... who may help me splitting this schema in N charms? https://is.gd/WqBWkK
[14:23] <facubatista> to explain it...
[14:24] <facubatista> 1) everything is behind an apache, and two domains go to it
[14:24] <facubatista> 2) if that domain is blog.t.c.a, the apache just serve some static files (which are prepared before)
[14:25] <facubatista> 3) if that domain is comentarios.t.c.a, apache just proxies the request to a gunicorn serving other project
[14:26] <facubatista> so, I attempted to split that structure in charms... AFAIU, I should have two units?
[14:27] <facubatista> one with Apache serving local files... but I need a charm for the "blog" part, can I "mix it" with Apache?
[14:27] <Chipaca> facubatista: so. For docs. Get a new category on the discourse juju (charm-docs perhaps?)
[14:27] <facubatista> other with the comments system, exposing a port, for which I'll add a relation to the first unit, for apache to talk
[14:29] <Chipaca> facubatista: we probably need to talk with somebody to get the category set up fwiw
[14:29] <facubatista> is this structure correct?
[14:31] <facubatista> Chipaca, we already have https://discourse.juju.is/c/docs/charming-docs
[14:31] <facubatista> "charming-docs"
[14:33] <facubatista> Chipaca, do we want a different section? reuse that one? for sure we could reuse a lot of text fromt there, or we'll start something from the scratch?
[14:36] <Chipaca> facubatista: 1 sec
[14:39] <Chipaca> facubatista: I think we need a separate category
[14:39] <Chipaca> maybe ops-charms?
[14:39] <Chipaca> ops-charms-docs?
[14:39] <Chipaca> docops
[14:39] <facubatista> Chipaca, and start everything from scratch?
[14:40] <Chipaca> facubatista: we are
[14:40] <facubatista> "ops" is too obscure
[14:40] <Chipaca> starting from scratch i mean
[14:40] <facubatista> Yeap, but a lot from those texts are reusable, they tell a story, they talk about juju commands, etc
[14:40] <facubatista> which hooks exist and what they mean
[14:41] <facubatista> we could start from current structure, discuss if we want it verbatim or which changes we should do, then start to fill the titles
[14:47] <Chipaca> facubatista: I'd rather start with a blank slate, in a separate category, and point to the ones that apply, than making things confusing to newcomers by having things that are all about reactive or layers or w/e
[14:49] <facubatista> Chipaca, I agree; my point is that let's do not grow doc structure organically, let's plan it, and we can use current structure as a source for that planning
[14:50] <Chipaca> er
[14:50] <Chipaca> facubatista: i don't understand what you mean
[14:50] <Chipaca> maybe i'm missing something
[14:50] <Chipaca> facubatista: you needed a place to write _a_ doc
[14:51] <Chipaca> so let's make that place
[14:51] <Chipaca> it is still empty, missing all kinds of things, that yes they need planning and such
[14:51] <facubatista> Chipaca, yes; I'm also talking about what we want in a month
[14:51] <facubatista> or a year
[14:51] <facubatista> but yes, writing that one doc unblocks me
[14:51] <Chipaca> facubatista: so for now, write a doc there. It'll be weird, and disconnected from everything, but it's a place to write them
[14:52] <facubatista> eso
[14:52] <Chipaca> exactly
[14:52] <Chipaca> facubatista: and it's a place to write them that won't further confuse things, and will let us move forward better once other things line up
[14:52] <facubatista> we need a category, then... operator-charms-docs?
[14:53] <Chipaca> charm-operator-docs, or chods for short
[14:53]  * Chipaca hides
[14:55] <mthaddon> Chipaca: surely you mean "cods" :)
[14:55] <Chipaca> I dunno, there's something fishy in that one
[14:55] <mthaddon> I set them up, you knock 'em down...
[14:57] <Chipaca> mthaddon: :-D
[14:57] <facubatista> we can go with "ops-charm-docs" (which is just a token that will be used in the URLs), and "Operator Charms Docs" as the general title (which is what users will see)
[14:57] <Chipaca> facubatista: sgtm
[15:00] <facubatista> jam, you're admin in that Discourse, may you could create this new category for us? under general "Docs"? thanks!!
[15:05] <jam> facubatista, I have the edit rights to be able to create a category (once I finally found the page that has a new category button), do we care about badge colors/etc ? or just leave it at defaults for now
[15:09] <Chipaca> fwiw I don't mind (especially as you can change these later)
[15:10] <jam> https://discourse.juju.is/c/docs/ops-charm-docs
[15:15] <facubatista> jam, thanks!!
[15:15] <facubatista> jam, we should fix https://discourse.juju.is/t/about-the-operator-charm-docs-category/2893
[15:22] <Chipaca> jam: but not now. go away, now :-p
[15:23]  * jam runs away
[15:26]  * facubatista -> lunch
[16:18]  * facubatista is back
[16:25] <Dmitrii-Sh> jam:  ty for `self._framework = framework.Framework(":memory:", self._charm_dir, self._meta, self._model)` in the harness code
[16:25] <Dmitrii-Sh> makes things so much simpler in writing independent test cases with components that have state
[17:12]  * Chipaca steps away for a while
[19:36] <Dmitrii-Sh> Made some progress on splitting out logic in the cockroachdb-operator PR
[19:36] <Dmitrii-Sh> https://github.com/canonical/cockroachdb-operator/pull/1/commits/e6741a9a01432f19d445914a77ff3a65050f0bcd
[19:36] <Dmitrii-Sh> There are a couple of points to discuss related to injecting dependencies and https://github.com/canonical/operator/pull/196 needs to be merged to uncomment important lines in 3 test cases.
[19:37] <Dmitrii-Sh> otherwise, I managed to cover the logic I had to test manually previously so that's good in my view
[19:37] <Dmitrii-Sh>  *logging out for today"
[20:02] <Chipaca> Dmitrii-Sh: awesome, thank you, and good night
[20:02] <Dmitrii-Sh> Chipaca: cheers o/
[20:07] <Chipaca> facubatista: ping?
[20:16] <facubatista> Chipaca, pong
[20:17] <Chipaca> facubatista: pm
[21:31]  * facubatista eods, and eows! see you all on Monday!
[21:31] <niemeyer> facubatista: Have a good rest
[21:32] <facubatista> niemeyer, thanks!
[21:32] <facubatista> same for you
[21:32] <niemeyer> Thanks o/
[21:33] <Chipaca> facubatista: see you tuesday :D
[21:33] <facubatista> yes
[21:33]  * facubatista reboots for a long due update
[21:39] <Chipaca> I too disappear, but only until tomorrow
[21:39] <Chipaca> 👋