[08:00] PR operator#330 opened: test/test_main: move actions.yaml into the charm [08:18] morning all [08:19] wazaaaaaaaaaaaaaaaaaaap [08:21] MarkMaglana: snapcraft <3 charmcraft, and/or viceversa [08:21] * Chipaca having fun with that [08:22] heh. [08:26] morning Chipaca and MarkMaglana [08:43] Chipaca, operator#330 is an attempt to make it possible to deploy 'test_main' as a real charm [08:43] PR #330: test/test_main: move actions.yaml into the charm [08:44] also, turns out we weren't cleaning up our TMP garbage correctly. [09:03] yeah i'd been meaning to look into the tmp garbage but there was always something else [09:03] thank you [09:31] o/ I was trying to create a new charm with the operator framework, inspiring myself from charm-ceph-iscsi and other tutorials, with and without charmcraft. It seems like the behavior of the Operator has changed regarding actions. I've created the most simple hello-world example I could: https://github.com/AurelienLourot/charm-ops-with-action [09:32] without charmcraft [09:32] we're coming to the conclusion that I should create the actions/ folder myself to get this to work [09:32] but it seems like it wasn't need for charm-ceph-iscsi in the past (I had a chat with gnuoy about that) [09:33] Chipaca, should this work? i.e. are actions.yaml and an observe() supposed to be enough to create an action? [09:34] lourot: yes [09:34] lourot: in what way does this not work? [09:34] see the readme [09:34] AttributeError: 'CharmOpsWithAction' object has no attribute 'hello_action' [09:34] lourot: CharmOpsWithAction is your code [09:35] lourot: in has no 'hello_action' [09:35] oh [09:35] wow [09:35] lourot: it does have a 'on_hello_action' [09:35] lourot: that might be the thing you want? [09:35] it's just python ¯\_(ツ)_/¯ (but also :-D ) [09:36] sorry, I misread the exception, because yesterday I had an exception that self.on was missing hello_action and I was trying to reproduce it with a super simple example [09:36] so -> pebkac [09:36] thanks a lot! [09:36] lourot: no problem! i wish they were all this easy to help with :-) [10:00] Chipaca, ok so now I managed to reproduce the exception I had in mind: https://github.com/AurelienLourot/charm-ops-with-action [10:01] it seems that I end up in that state only if I use charmcraft [10:01] gnuoy, icey, fyi ^ [10:01] in the ops code I see that there is a loop iterating on actions and populating methods on CharmEvents [10:02] but somehow there must be a bit missing in my example [10:02] lourot: does charmcraft copy actions.yaml into the charm? [10:03] Chipaca, nope indeed. I see you have a PR for copying config.yaml but none yet for actions.yaml [10:03] lourot: yeah, i'll push one for actions.yaml in a bit [10:03] ah cool [10:03] thanks! [10:03] i've gotten as far as i'm going to get with snapcraft for now :) [10:03] lourot: sorry :) this comes from not having any real-world tests for its first release into the wild :) [10:04] the charms we did test didn't have config nor actions 😲 [10:04] anyhoo, will fix [10:04] grr [10:05] Chipaca, thanks! does it help you if I create an issue and point to my example? it'll help me at least to point to it for a related change I need to do [10:05] lourot: sure! [10:06] gnuoy, so I'll create a PR to ops-openstack with a try/catch around observe() for pause/resume - alternatively I could also not use charmcraft for now, what do you think? [10:06] Chipaca, I finally managed the magic invocation to do a bit of performance timing and see that we spend 90% of our test suite time in _simulate_event [10:10] of the 30s it takes for me to run 'test_main': it breaks down as: https://paste.ubuntu.com/p/RmHn6gSwyS/ [10:10] so install/start is most of the time. [10:30] lourot: want to try charmcraft from my branch (charmcraft#36)? [10:30] PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml [10:31] jam: is that because a lot of tests just run install? or is install beig silly [10:32] Chipaca, I haven't dug past the subprocess barrier yet. My guess is that install does all the 'setup' stuff like creating all the symlinks. I'd like to adjust that with counts as well (eg, we might call install 10x more than the next one) [10:35] Muy buenos días a todos! [10:35] facubatista: buen día! [10:36] hola Chipaca! [10:36] facubatista: lourot noticed we also don't ship actions.yaml in the .charm [10:36] so charmcraft#36 fixes that and config.yaml [10:36] PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml [10:36] facubatista: it feels bad enough to do a .4 tbh [10:36] .3? [10:36] that [10:37] .9¾ [10:38] Chipaca, what about #31 ? [10:38] PR #31: Remove DeadRelation in favor of empty relations [10:38] ugh [10:38] Chipaca, what about charmcraft#31 ? [10:38] PR charmcraft#31: Include config.yaml in built charm [10:38] facubatista: we're still waiting for the CLA [10:38] facubatista: i made a comment on it [10:43] Chipaca, pr46 approved [10:43] woo, approval from the future [10:43] 36 I mean [10:44] aw [11:20] Chipaca, yep, fetching coffee and I'll give it a try, thanks! [11:29] coffee sounds like a good idea [11:29] so does lunch [11:43] yay, it worked, thanks. commenting on the PR [11:51] Chipaca, charmcraft#36 has a comment from me, there are a couple more files to pull in [11:51] PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml [11:51] morning facubatista [11:51] hola jam [11:52] Chipaca, facubatista I'd say charmcraft#36 supersedes 31, and since it is done in a different way, doesn't have to worry too much about licensing. [11:52] PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml [12:16] jam, facubatista, actually, why aren't we copying everything into the charm? (a refactor for later perhaps) [12:17] Chipaca, I don't know why we wouldn't copy something that someone felt was worthy of including [12:17] Chipaca, what do you mean "everything"? [12:17] Chipaca, certainly things like 'files/' that we saw was content the *charm* expected to exist. The ones I mentioned are ones that *juju* will do something with [12:18] the current behaviour flies against what we've said all along, that the result of charmcraft build looks almost exactly like the charm it's built from [12:18] Chipaca, you'd put also the .gitignore inside? [12:19] facubatista: I would not, but putting it inside breaks less things than not putting something [12:19] ie our approach is backwards right now, we should be excluding things, not including them [12:19] again, it's a bigger change [12:19] Chipaca, you can always include things later; I'm worried about including by default something the user wouldn't want to leave his machine (as in a 'credentials.txt' file) [12:19] if charmcraft#36 is bad enough to trigger a point release, i'd go with that [12:20] PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml [12:20] and then later a refactor to change the approach [12:21] Chipaca, what we at least need to include is a way for the dev to say "also these files, please" [12:21] a kind of... manifest [12:22] jam: WRT 'revision', that one seems weird [12:22] jam: revision means something else in the new APIs [12:22] jam: what does it mean in juju? [12:23] Chipaca, IIRC, revision is meant to be populated by the store, and indicates an official number for the charm [12:23] yeah, but not inside the charm itself [12:23] 'juju deploy mysql-22' is a specific revision of the mysql charm [12:24] Chipaca, I do believe once we get the charm on disk, it has revision with 22 in it [12:24] because the charm's hash is used to sign it [12:24] hmm [12:24] i'll check with store people to see if this is true for charms in the new APIs [12:24] anyway it's not something that'd be there at build time so i'll skip it : [12:35] jam: how hard would it be (and how big would it be) to build a juju that _only_ knew how to do 'juju deploy'? [12:36] Chipaca, so presuming you already had bootstrapped a controller, and you just wanted something that can interact with the API to deploy ? [12:36] jam: yeah [12:36] jam: (wondering if we can do a strictly confined charmcraft that shipped its own juju just for the deploy bit, if and when we get around to that) [12:36] Chipaca, I believe we've prototyped a stripped down Juju, but I don't remember the exact numbers. [12:37] A lot of the overhead of the binary is from bootstrap, IIRC, since it needs to know all the different provider code. [12:37] otoh i hear snapd is working on snaps running snaps, so maybe that'll dtrt [12:38] jam: i was surprised at how big juju-the-binary was fwiw [12:38] anyway, just some idle thoughts [12:38] jam, facubatista, wdyt, should we do a charmcraft 0.1.3? [12:39] Chipaca, release often, etc, etc [12:39] Chipaca, iow, yes, please [12:39] ikr [12:39] facubatista: you ok with my argument on the pr wrt tests? [12:41] Chipaca, if you strict with checking "the wanted behaviour" you should add tests for all those files [12:41] Chipaca, yeah, juju is >100MB uncompressed, IIRC. [12:41] Chipaca, what about leaving that test as it is, and adding other one that reflects that we're including (if exists) whatever is in that CHARM_OPTIONAL? [12:42] ah, only 89MB, I think it was bigger at times. (I believe 'make install' supplies the 'strip' flags to go) [12:42] $ ls -sh /snap/juju/current/bin/juju [12:42] 120M /snap/juju/current/bin/juju [12:42] ¯\_(ツ)_/¯ [12:42] Chipaca, jujuc that only talks to the unit agent socket is only 8.5MB, so it can go down quite a bit. [12:43] Chipaca, hm. [12:43] $ ll /snap/juju/current/bin/juju -h [12:43] -rwxr-xr-x 1 root root 149M Apr 21 07:45 /snap/juju/current/bin/juju* [12:43] PR #21: Persist stored state before framework commit [12:43] but $ ll ~/dev/go/bin/juju -h [12:43] -rwxrwxr-x 1 jameinel jameinel 89M Jun 11 12:52 /home/jameinel/dev/go/bin/juju* [12:44] Chipaca, your "I don't like the 'charmcraft: error: invalid choice: thing" comment, is feedback for Lilyana, or shall we open an issue in the project about it? [12:45] jam: snap info juju | yq r - tracking [12:45] jam: maybe the snap is not stripping the binary? [12:46] it says 'not stripped' here :-\ [12:46] anyhoo [12:46] coffee [12:46] then meetings [12:52] Chipaca, https://bugs.launchpad.net/juju/+bug/1883703 [12:54] Chipaca, so 'go install' without the strip flags is 120MB and 'make go-install' with them is 89MB. [12:54] so it does seem like our snap build is broken. [12:54] I wonder if we switched to using the snap plugin to build, which doesn't run the extra magic strip flags. [12:55] i wonder if snapd-the-snap could also benefit from the extra magic strip flags =) [12:56] snapd in the snap says 'stripped' though ¯\_(ツ)_/¯ [12:56] Chipaca, https://github.com/juju/juju/blob/develop/snap/snapcraft.yaml looks like we have a 'juju-go' plugin because the snapcraft one doesn't allow us to do everything. [12:59] facubatista: you comng? [12:59] facubatista: i [13:00] yes [13:06] jam: now all you need to do is push everything onto the stack, and then treat it as a queue, right? [13:06] or was it the other way around [13:06] Chipaca, jam, we could do the standup right now, and have some minutes between that and the next meeting... [13:06] Chipaca, don't you put it all on the stack and then throw the stack in the circular file? [13:06] facubatista: works for me [13:07] jam: me? i put everything in the stack, and then kill the process [13:07] *cheff kiss* works every time [13:07] Chipaca, facubatista wfm [13:07] going in... [13:52] facundo__, jam, added a test to charmcraft#36, hope it's what we agreed on :) [13:52] PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml [13:59] Chipaca, I use simple 'patch' for that kind of patching, but it's fine for me [14:00] jam: how do i trigger that charmdir build-a-zip code from juju? [14:00] Chipaca, IIRC, 'juju deploy ./directory' will build and upload a .zip to the controller, but I don't know of a way to just get the .zip [14:01] Chipaca, coming to prep? [14:02] y === niemeyer_ is now known as niemeyer === joedborg_ is now known as joedborg [15:02] facundo__, jam, thanks [15:26] facundo__, jam, I'll be merging charmcraft#36 and releasing 0.1.3 in half an hour unles you holler to the contrary [15:26] PR charmcraft#36: 'charmcraft build' should pull in actions.yaml and config.yaml [15:28] Chipaca, go, go [15:28] thanks for the quick reaction/implementation today! (re: #36) [15:28] PR #36: Refactor how relation endpoint and storage events are handled [15:29] lourot: thank you for using our stuff, and reaching out when it didn't work, *and* testing the fix :-D [15:37] facundo__: should the release now also include the code of conduct? [15:37] as in, should i add it to the manifest [15:47] Chipaca, do we have it? === facundo__ is now known as facubatista [15:47] ah, yes [15:48] Chipaca, yes, any specific file must go in the MANIFEST to be included [15:54] facundo__: i guess what i'm asking is whether to include it or not :) [15:55] Chipaca, if we have other text in the README or something about "how to collaborate with the project", we should mention the CoC and include it === facundo__ is now known as facubatista [15:56] facubatista: we do not yet reference the one from t'other [15:59] facubatista, facundo__, i've just noticed that charmcraft is not including tests in the releases [15:59] in the wheel that seems alright, but not so much in the sdist [15:59] but i'd have to check other projects to know if this is normal/right/accepted practice [16:01] anyway this one'll go out like the previous [16:01] facundo__: charmcraft#38 plz [16:01] PR charmcraft#38: bump version for 0.1.3 [16:04] Chipaca, approved === ChanServ changed the topic of #smooth-operator to: general discussion of the operator framework || github.com/canonical/operator || ops 0.6.1 || charmcraft 0.1.3 [16:11] lourot: should work now [20:10] * facundo__ eods [20:32] yeah, eod sounds nice === karimsye_ is now known as karimsye