=== oscar12 is now known as oscar0 [08:30] Can I ask, does anyone know how to set version number in a charm developed with the operator framework? The version number for the charm should be visible when typing "juju status". [08:36] I'm looking for a way to set the version number in a charm developed using operator so that it is visible when typing "juju status" [08:47] oscar0: jam and Chipaca may be able to give you a more authoritative answer. Here is a hack. How about setting the version string as the message passed to ActiveStatus() . [08:48] oscar0: is the "version" file picked up automatically by juju for a default status message or something? [08:49] we have an issue about creating a "version" file in the charm, but I thought that was just for the store [08:49] thanks bthomas and Chipaca. I will try those things today. === oscar0 is now known as oscar0|afk [11:02] the "version" file approach does not work. [11:03] App Version Status Scale Charm Store Rev OS Notesmycharm active 5 mycharm local 0 ubuntu [11:03] the second field is where it would be good to have a version number, but I don't know how to set it there :) === oscar0|afk is now known as oscar0 [11:16] oscar0: did you try the ActiveStatus("your version here") approach? [11:18] Chipaca: I will try it now [11:19] Chipaca: Is this the way you suggest to use it: [11:20] self.unit.status = ActiveStatus('version') [11:21] oscar0: do you want to set it there, or do you want to set the application version? [11:21] application :) [11:21] self.app.status? [11:21] oscar0: self.unit.set_workload_version(...) might actually be what you want [11:21] Chipaca: I will try it [11:21] oscar0: FWIW set_workload_version takes a string [11:22] oscar0: and that will be shown in 'juju status' automatically [11:22] sweet, trying it out right now [11:22] oscar0: i probably should have realised this was what you wanted earlier, sorry for the runaround :) [11:23] no problem :) [11:26] it worked, thanks Chipaca! [11:26] \o/ [11:26] love this channel! :) [11:27] but what is the actual purpose of the 'version' file? is it only relevant for the charm store? [11:30] bthomas, oscar0 : I think you are looking for Unit.set_workload_version() [11:31] ah, chipaca already found that for you [11:32] yep! [11:49] oscar0: the version file is something we're wanting to add so that the store can show it to the user as they browse that [11:49] oscar0: 'charm upload' did that automatically, 'charmcraft build' does not yet [11:50] or is it 'charm push' [11:50] * Chipaca gets confused with snapcraft too much [11:51] Chipaca: okay, I understand [11:51] thanks! [11:51] oscar0: np! happy charming [11:52] I understood the requirement as displaying Charm version in status not Version of application deployed by Charm. jam thanks for clarifying. [11:54] Chipaca, I thought 'upload' was the new 'push' [11:55] jam: that's what they want you to believe, man [11:55] 'version' is a way to encode the VCS version of the charm, so that people who work with stores and offline charms can know that it is actually the same charm [11:55] Its the "back link to the source" [12:04] fwiw we have charmcraft#37 and charmcraft#159 [12:04] Issue charmcraft#37: Populate the 'version' file as part of 'charmcraft build' [12:04] Issue charmcraft#159: Snapcraft-style version metadata handling [15:08] Issue operator#390 closed: Only one role allowed [15:18] have i mentioned before how slow the unit tests are on windows [15:58] Chipaca, that's because it is all python startup overhead and not bash, right? Is it plausible to cut down the set of things that need to be run on Windows? [15:59] jam: i think it's just exec overhead on windows, but i'm not sure [15:59] jam: this is without the everything-is-python-now change [15:59] but there's a .bat that calls bash, for fake_script [16:00] the alternative is to call subprocess.run with shell=True which is just as slow and more insecure [16:00] (granted in tests the latter shouldn't be an issue) [16:01] ie fake_script('foo', ...) creates the regular foo bash script, and a foo.bat that does bash.exe foo %* [16:41] hello hello [16:42] so I was using self.framework.model.unit.is_leader() , and someone told me now it's better to use self.model.unit.is_leader() ? Are we getting rid of the "framework" in all calls? [16:42] what about self.framework.model.unit.status , should I switch to self.model.unit.status as well ? [16:46] crodriguez: it's only better in that it's shorter :) [16:46] crodriguez: it's the same [16:47] crodriguez: actually i would write self.unit.is_leader() directly [16:47] alright, so from what I see in the docs, anytime I'm calling model I can drop the framework ahead of it [16:47] crodriguez: crodriguez: CharmBase has app, unit, meta, and charm_dir all proxied to the appropriate places [16:47] ok cool, thank you [16:48] wrt status, self.unit.status and self.app.status, as appropriate 🙂 [16:50] crodriguez: fwiw 'self.model' won't work unless you've done that yourself :) [16:50] anyhoo. i'm off [16:53] @Chipaca, where do you get bash from on Windows? [19:43] jam: it comes with git [19:44] jam: https://gitforwindows.org/ [19:44] Chipaca, what are you doing back? go away :) [19:44] jam: just got back from walking the dog and buying dinner [19:44] cheers [19:44] (boys are with their mum)