[05:29] * facubatista pushed https://github.com/canonical/charmcraft/pull/4 [05:29] PR charmcraft#4: First version of the build command [05:29] now, to sleep [08:22] 's morgens! [08:40] morning Chipaca. I'am about 60% through lib.use. want me to submit what I have so far? [08:40] jam: if it's all good news i can wait :-) if it's things i need to address, i could use the headstart [08:41] Chipaca, I think it mostly breaks down as "we're missing the high level pointers for other people to follow" [08:41] which leads to "why is the code structured this way" [08:42] Chipaca, that, and how much do you want me to dig through the peps to make sure we're using loaders/finders etc as requested for 3.5+ [08:42] jam: digging through the peps sounds valuable [08:43] mmm... ananas [09:01] Chipaca, joining? [09:01] jam: i don't seem to have usb … somehow [09:01] i guess a reboot is in order [09:01] i'll be there as soon as i can [09:28] Chipaca, I'll take some time to look over the doc and the issue during this hour [09:28] since its allocated for the conversation [09:28] jam: sounds fair to me [09:36] Chipaca, review submitted [09:44] jam: thanks! [11:07] jam: hah, just realised i've been spamming you with messages instead of batching them up into a comment review thing [11:07] Chipaca, its ok. I'll ignore them all until you tell me to :) [11:08] jam: i've gotten to the bottom of it, and now am writing a missing test and rewriting the 'expected' one to be explicit [11:08] jam: feel free to unignore at this time [11:09] * Chipaca looks for more words that exist both with and without a starting B [11:12] Muy buenos días a todos! [11:13] * Chipaca wonders on which side of the 'too evil' line using 3↑↑↑3 as an example value is [11:14] hey operator team, how do we deal with ConfigMaps in the framework? [11:14] hello pjds! where, specifically? [11:15] (I may not have enought context) [11:15] hey facubatista, i want to generate and attach a ConfigMap to my pod [11:15] just trying to see how I can achieve this [11:16] pjds: I don't think we have anything special for that [11:16] pjds, https://juju.is/docs/k8s-charms-tutorial [11:16] pjds, ultimately you'll set the config section as part of the pod spec [11:16] there isn't anything that the Operator wraps around that, so for right now you just pass the config section in. [11:17] great thank you for pointing me in the right direction [11:17] ok cool [11:39] facubatista: > enums are normally compared by equality [11:39] facubatista: the documentation for enum mentions identity directly [11:40] actually i should answer in the PR [11:40] :) [11:40] * Chipaca goes [11:58] * Chipaca gets lunch [11:58] jam, Chipaca, may I get a review of my build branch? let's see if we can nail that today, thanks! [11:59] facubatista, yeah, I'm looking at it now [11:59] jam, thanks [11:59] jam, note travis is unhappy, but only for python 3.5 [12:01] wow, we need to support Xenial until 2024 :o [12:02] facubatista, releasing now without Xenial support would limit adoption. We don't have to release new versions of operator that still support Xenial once we have one for them to use. [12:03] eg, 1.0 should probably support Xenial, but 2.0 doesn't need to even if it releases is 2023 [12:07] jam, nice; probably we should extend ourselves until Xenial end of standard support (april 2021) [12:10] Xenial has a python 3.5.2 from oct 2019; python 3.5 itself is in "security maintenance mode", with planned end of life on 2020-09-13 [12:11] *anyway* /me backs to fight 3.5 [12:34] facubatista, just checking out your branch and trying to ./run_tests I get a traceback [12:34] https://paste.ubuntu.com/p/mp73VcVbXC/ [12:34] (different pytest version?) [12:36] jam, maybe! are you using pytest == 5.4.1 ? [12:36] pip3 install --user pytest says I already have 3.3.2 installed [12:37] install --upgrade got me to 5.4.2 [12:37] jam, you should use a venv [12:38] facubatista, is that a venv, a virtualenv a venv that isn't the other venv ? [12:39] jam, what? [12:40] facubatista, there is 'virtualenv' 'pyvenv' 'python3 -m venv' [12:41] jam, I use 'fades' 95% of the times, but if I have to create a virtualenv by hand, I use 'virtualenv' [12:41] facubatista, notes that I've seen so far says virtualenv was python2 while venv is python3 [12:42] but there doesn't seem to be clear messaging there [12:42] https://stackoverflow.com/questions/41573587/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrappe [12:43] has a lot of the confusion [12:44] jam, with my rule above I don't have problems :) [12:45] note that if you want to try fades, r9 is being released these days, you should use that (I have a .deb already prepared) [12:45] facubatista, but how does a 'virtualenv' get found when ./run_tests just calls "python3" which means I need to somehow put the virtualenv's python3 for *this* project first in PATH? [12:47] jam, you first do `virtualenv --python3=python env` to create a venv there in your project directory, then `source env/bin/activate` to "jump into the venv", then you do ./run_tests [12:47] jam, sorry, after jumping into the venv and before run_tests, `pip install -r requirements-dev.tx` [12:47] to install the requirements, of course [12:48] though requirements.txt exists but is empty and pip complains if you try to use it... [12:48] jam, requirements.txt is only for "using" the tool, for "developing" you need the -dev alternative (see my pip install command above) [12:49] facubatista, I understand that, but if it doesn't do anything but cause complaints, I wouldn't recommend having the other file [12:49] jam, that's another discussion, isn't it? [12:56] jam, Chipaca, there I pushed another revision of my build branch; it should support py3.5 ok (and also refactored a little the "link" helper [12:56] ) [13:36] Hey everyone, does anyone have experience with using actions with the python operator framework in a k8s charm? I created a Dockerfile with python3 installed but when I execute an action I get the following error: https://paste.ubuntu.com/p/hwmNQgmmV4/ What additional dependencies need to be installed besides python3? [13:50] DominikF, the only other dependency for the operator framework is pyyaml [13:51] jam: in that case `apt install python3 && apt install pyyaml` should be enough? [13:52] DominikF, I would guess it is python3-yaml [13:52] (and I'd use apt install python3 python3-yaml) [13:53] jam: ack, thanks, I'll let you know if I keep having issues [14:07] facubatista, non-build PRs have been reviewed [14:11] facubatista: can you show me how to make the setup.py with 'import ' fail? [14:11] Chipaca, I'll try :) [14:13] facubatista: meanwhile I'll be reading https://packaging.python.org/guides/single-sourcing-package-version/ [14:14] facubatista: ah [14:15] facubatista: [14:15] Warning [14:15] Although this technique is common, beware that it will fail if sample/__init__.py imports packages from install_requires dependencies, which will very likely not be installed yet when setup.py is run. [14:15] facubatista: ^ about my suggested approach [14:15] so it works iff charmcraft/__init__.py doesn't import anything non-stdlib [14:15] * Chipaca adds more negation pairs in there for extra fun [14:16] Chipaca, what about __init__ importing stuff from the project itself? [14:17] facubatista: basically setup.py will be run before installing any of the requirements so if it tries to import any of those it'll fail [14:17] facubatista: from that document, option 7: Keep the version number in the tags of a version control system (Git, Mercurial, etc) instead of in the code, and automatically extract it from there using setuptools_scm. [14:17] that's https://pypi.org/project/setuptools-scm/ [14:18] Chipaca, which will not work if you run the project from a tarball [14:19] facubatista: f the normal methods for detecting the version (SCM version, sdist metadata) fail, and the parent directory name starts with parentdir_prefix_version, then this prefix is stripped and the rest of the parent directory name is matched with tag_regex to get a version string. If this parameter is unset (the default), then this fallback is not used. [14:19] This is intended to cover GitHub’s “release tarballs”, which extract into directories named projectname-tag/ (in which case parentdir_prefix_version can be set e.g. to projectname-). [14:19] facubatista: quisió [14:19] facubatista: i only mention it because you liked the git describe approach :) [14:21] Chipaca, I found that setuptools-scm thingie when I explored the version alternatives, it looked a good idea... then I started to read it's README, stuff like [14:21] The preferred way to configure setuptools_scm is to author settings in a tool.setuptools_scm section of pyproject.toml. [14:22] * Chipaca sets toml on fire and runs away [14:22] and starts to talk about stuff that we do not have [14:22] and then I decided that I would not change the whole project structure just to use an extra dependency just to get a version number, specially if we still didn't decide what we want in that regard [14:23] facubatista: I want the pig, and the piglets, *and* the sausages [14:23] facubatista: what's so hard to understand [14:24] nice, now my branch fails with [14:24] AttributeError: module 'setuptools' has no attribute 'find_namespace_packages' [14:27] * Chipaca hugs facubatista [14:27] facubatista: that's from #10 [14:27] PR #10: Code spacing is a useful organizational aid [14:27] no, charmcraft#10 [14:27] PR charmcraft#10: Fix pip installation [14:27] Chipaca, yes, I know [14:28] facubatista: but setuptools has had find_namespace_packages since 3.4 or something [14:28] Chipaca, remember I wanted it to be simpler? [14:28] * Chipaca hugs facubatista more [14:29] facubatista: where is it failing like this? [14:30] Issue operator#271 closed: Relation.role should be 'peer' not 'peers' [14:30] PR operator#299 closed: charm: make role an enum, with 'peer' instead of 'peers' [14:31] ooh, #298 [14:31] PR #298: ops.framework: Remove default target for Framework.observe [14:31] facubatista: could you take a poke at it? while i continue to review your build pr :-p [14:31] PR operator#300 closed: charm: use magic strings a little less [14:31] Chipaca, after I unblock charmcraft [14:31] PR operator#301 closed: charm: role is 'peer', not 'peers' [14:32] Chipaca, [14:32] facubatista: k [14:32] (Pdb) pp setuptools [14:32] [14:32] (Pdb) pp setuptools.__version__ [14:32] '39.0.1' [14:32] (Pdb) pp setuptools.find_namespace_packages [14:32] *** AttributeError: module 'setuptools' has no attribute 'find_namespace_packages' [14:32] facubatista: what python version? [14:33] facubatista: i have setuptools 45 here fwiw [14:33] 45.2.0 [14:34] Chipaca, ah, wonderful [14:35] Chipaca, see, https://setuptools.readthedocs.io/en/latest/setuptools.html#find-namespace-packages [14:35] Chipaca, it DOES NOT say "available since vX.Y" [14:35] facubatista: yeah [14:35] facubatista: was about to say that much :) [14:35] Chipaca, that is a mistake we must not commit [14:35] facubatista: indeebly [14:50] Chipaca, I added install_requires=['setuptools>=45'], in setup.py [14:50] Chipaca, but we'd need to really test that [14:50] Chipaca, if I build a tarball, and try to install from that tarball, it fails with [14:50] AttributeError: module 'setuptools' has no attribute 'find_namespace_packages' [14:51] (I'd expect with something like "setuptools doesn't match") [14:51] ah, let's try fades on it [14:52] AttributeError: module 'setuptools' has no attribute 'find_namespace_packages' [14:53] Chipaca, I'm tempted to go back to my simpler way of doing it, and in any case fight this in the second release (when we know everything else already works) [14:53] facubatista: +1 [14:54] facubatista, feedback on 'charm build'. I'm going to go have dinner, I'll try to be back around for responses. [14:54] jam: thank you! [14:57] jam, thanks! [14:58] Chipaca, now this works as expected: [14:58] $ fades -d file:///home/facundo/canonical/charmcraft/ -m charmcraft version [14:58] Version: 0.0.1 [14:59] facubatista: hu to the zah [15:02] Chipaca, so, I pushed charmcraft#8 [15:02] PR charmcraft#8: Have a version in the project, show it in the command and on startup [15:03] Chipaca, I simplied setup.py, in general (grab __version__ from charmcraft.__init__, and better packaging, but also removed requirements.txt stuff (as it is empty! if we start to have stuff there in the future we put it back) [15:04] Chipaca, let me know if you want to take a look at it or I just land it [15:06] * facubatista brb [15:18] facubatista: charmcraft#8 is GTG [15:18] PR charmcraft#8: Have a version in the project, show it in the command and on startup [15:53] * facubatista is back [15:57] ok, the only missing branch is the build one [15:57] Chipaca, I'll address jam comments there and then attack your branch, as jam would probably be almost gone [15:59] facubatista: ok [16:16] Issue operator#122 closed: Interface class repository [16:16] PR operator#244 closed: ops library support [16:19] jam, ooohhh, we do not HAVE to put stuff under src? I thought we had, this is great! [16:19] facubatista: we do not [16:19] great, so I will stop creating the src/ dir inside the build [16:21] yeah that bit is weird, i hadn't noticed it [16:21] facubatista: this is so close :-D [16:22] facubatista: the comment on '--quiet' feels off [16:23] Chipaca, which comment where? [16:23] facubatista: should i push a pr for that? [16:23] ah, my branch [16:23] -q, --quiet shh! [16:23] ^^ that one :) [16:23] ah [16:23] Chipaca, no, just tell me what to put there [16:24] facubatista: depending on exactly what it does (i haven't checked), it could be 'suppress the usual output' or 'only print errors' [16:24] Chipaca, it puts the logger in WARNING level, so no normal info will be seen [16:26] jam, I will address all specific comments on each conversation, but from your general comment: [16:26] 1. you're right! src not needed, will remove that [16:27] facubatista: "only show warnings and errors, not progress"? something like that [16:27] 2. regarding symlink in build and then expand in the file: let's land current behaviour now, please open an issue in the project with what you think would be a better alternative [16:30] Chipaca, like it; for -v I put "be more verbose and show debug information", what do you think? [16:35] facubatista: sgtm [16:55] facubatista: don't forget a review on 298 please [16:55] i'm going for a run, and then we'll be having dinner -- ttfn but ttyl [16:55] Chipaca, no worries [17:08] facubatista, Chipaca sgtm for build [17:09] jam, question regarding HOOKs [17:09] sure [17:10] jam, you mentioned TWO issues in your parragraph, right? first, why I'm handling only some hooks, and not others; second, what about symlink chains -- right? [17:10] that sounds correct [17:13] jam, so, 1. I think you're right, I'm not checking "all the other stuff under hooks"... so I propose this behaviour: let's "respect" everything the user has under hooks, and also verify that the "mandatory" ones are present, else create them [17:13] what do you think? [17:14] facubatista, I like it. We should think about how we want to handle 'helper' files. Should we only include hooks that we know about or should we bring everything in the 'hooks' dir. [17:14] jam, I'd bring everything [17:14] facubatista, I agree [17:15] jam, great [17:16] jam, 2. that symlink chain works for now, as the zip is putting just the content; but let's talk about this in the future when we revisit this "why all links?" -- what do you think? [17:16] facubatista, yeah, creating hooks/install => ../src/charm.py will end up expanded (if I understand the code correctly), but we can address that when we address symlinks generally [17:17] jam, great [17:44] jam, all addressed, sorry for the delay [17:45] Chipaca, bb in 15' and do that review [18:09] jam, please let me know when you have news on my branch, thanks! [18:09] Chipaca, you need to change two small details in operator#298 [18:09] PR #298: ops.framework: Remove default target for Framework.observe [18:20] * facubatista bb ~30' [18:49] facubatista, reviewed [18:49] Chipaca, https://github.com/canonical/charmcraft/pull/4 needs your sign off, IIRC [18:49] PR charmcraft#4: First version of the build command [19:07] jam, thanks! [19:07] Chipaca, regarding charmcraft, shouldn't we have a snap? [20:13] facubatista: at some point, yes! the name is already reserved [20:14] jam: i've been poking at it irl and giving facundo feedback from there, which he's been integrating. I'll take another pass now :-) [20:14] facubatista: how's things? [20:21] Chipaca, I think I need your re-review in https://github.com/canonical/charmcraft/pull/4 [20:21] PR charmcraft#4: First version of the build command [20:21] facubatista: yep [20:21] facubatista: doing that [20:36] facubatista: niiice [20:38] Chipaca, ? [20:39] facubatista: src and lib and requirements handling improved [20:46] facubatista: it's good :-) [20:58] Chipaca, do I owe you changes in that branch? [21:10] facubatista: other than the typo, no :) [21:11] i don't think so [21:11] Chipaca, would you approve it? [21:11] facubatista: i think we can call it a wrap [21:11] (the typo is already fixed) [21:11] facubatista: yeah i saw [21:11] facubatista: i need a re-review on #298 tho [21:11] PR #298: ops.framework: Remove default target for Framework.observe [21:53] facubatista: charmraft#4 is green [21:55] facubatista: also charmcraft#4 [21:55] PR charmcraft#4: First version of the build command [21:58] facubatista: i really need a re-review on #298 tho :) [21:58] PR #298: ops.framework: Remove default target for Framework.observe [22:08] Chipaca, yes [22:16] Chipaca, approved, but please bring the message checking back [22:16] (I put in a comment the syntax to do that while still using assertRaises [22:16] ) [22:21] facubatista: I thought the `msg` arg to assertRaises did that automagically [22:25] facubatista: but assertRaisesRegexp does what i want \o/ [22:25] Regex* [22:29] hi, i'm adding unit tests to a charm i'm working on, but it's blowing up while the hardness is initializing. here's the transcript: https://pastebin.canonical.com/p/n78cRHhV57/ [22:29] is this a bug in my charm, the psql interface, the framework, or something else? [22:30] and here's my __init__: https://git.launchpad.net/charm-k8s-mattermost/tree/src/charm.py#n44 [22:30] s/hardness/harness/ d'oh [22:34] hmm [22:34] there's something strange, but i need facubatista's eyes on it maybe [22:34] just pushing the tests branch now [22:35] pjdc: you're doing [22:35] self.framework.observe(self.db.on.database_relation_joined, self._on_database_relation_joined) [22:35] which seems weird to me [22:35] but maybe i'm missing something :) [22:35] https://git.launchpad.net/~pjdc/charm-k8s-mattermost/+git/charm-k8s-mattermost/tree/tests/unit/test_charm.py?h=s3-wip [22:36] Chipaca: fwiw, the charm does work, only the tests are new [22:36] pjdc: because i'd expect that line to look more like self.framework.observe(self.on.db_relation_joined, self._on_database_relation_joined) [22:36] self.db is a pgsql.PostgreSQLClient(self, 'db') [22:36] yep [22:36] pretty sure this is copy and paste from the interface README, but lemme check [22:37] :) [22:37] yeah, looks the same to me https://git.launchpad.net/~stub/interface-pgsql/+git/operator/tree/README.md [22:37] Chipaca, it makes sense to me, IIUC it's doing the same than in my fake charm with an interface: https://paste.ubuntu.com/p/Ns2sMzrJk9/ [22:38] see line 24 there [22:38] facubatista: right, but the _relation_joined event is "ours" [22:38] facubatista: it's not a custom interface-provided one [22:38] but, as mentioned, the charm does work, so it seems the harness is adding a new expectation [22:39] pjdc: wouldn't be surprising :) but it also might be pointing at something deeper [22:39] unfortunately it's beyond my expertise still; you'd have to check with j_am but he's away until Sunday [22:39] I'm for sure too tired to debug that [22:39] pjdc: could you file an issue with just the info you've given it, so he gets to go through that when he gets in? [22:40] s/given it/given us/ [22:40] sure thing [22:40] pjdc, let's see if tomorrow I could give you a hand [22:40] pjdc: thanks! [22:40] facubatista: if you can, it'll be in an issue :-D [22:40] this is my last working day this week, but i'm on call so i should be able to c heck in [22:40] will file that issue now [22:40] pjdc, ah, so we're not making lose you a day [22:41] pjdc: thanks! sorry it's not as expedient as I'd like it to be (we'll get there! but not there yet) [22:41] *making you lose a day [22:41] no worries [22:42] Chipaca, we can call it a day, and do the releases tomorrow? [22:42] facubatista: let's land everything today, and tag and release tomorrow [22:43] facubatista: i just need to wait for #298 to be green and I'm done :-D [22:43] PR #298: ops.framework: Remove default target for Framework.observe [22:43] charmcraft is pristine [22:44] * facubatista opens a bottle of wine [22:44] facubatista: we'll want to work on the README a bit tomorrow also (on both sides) [22:44] but i'm happy with that level of changes :-) [22:44] Chipaca, +1 [22:44] * facubatista eods, then [22:46] facubatista: chin chín [22:47] * Chipaca would so have a fernet right now [22:49] Issue operator#302 opened: AttributeError: 'MattermostCharmEvents' object has no attribute 'db_relation_joined' [22:51] pjdc: thanks! [22:52] * Chipaca tries to get from jetpackdanger to pjdc and falls down a rabbithole of RPN and rum [22:52] woo, 0.6 is code complete [22:53] and on master [22:53] * Chipaca dances [22:53] Issue operator#297 closed: Remove default target for Framework.observe [22:53] PR operator#298 closed: ops.framework: Remove default target for Framework.observe [22:53] the joke is that my middle names are jetpack and danger [22:54] I don't judge. A very good friend has database-breaking middle names too. [22:56] anyway, EOD for me! wish me luck with that Zzz thing [23:16] oh, i figured it out. the metadata.yaml i passed to the constructor didn't include the DB relation [23:20] actually it seems i can just remove meta and it, i assume, reads metadata.yaml from the charm itself. at any rate, the tests still pass