| Chipaca | moin moin | 08:10 |
|---|---|---|
| niemeyer | Good morning | 08:11 |
| jam | morning | 08:30 |
| Chipaca | Dmitrii-Sh4: you around? | 08:46 |
| Dmitrii-Sh4 | Chipaca: + | 08:46 |
| === Dmitrii-Sh4 is now known as Dmitrii-Sh | ||
| Chipaca | Dmitrii-Sh: welcome! how was the break? | 08:47 |
| Dmitrii-Sh | Chipaca: mostly busy and isolated :^) | 08:48 |
| Chipaca | Dmitrii-Sh: :-) busy with what tho | 08:48 |
| Dmitrii-Sh | accounting & legal things | 08:49 |
| Chipaca | Dmitrii-Sh: aw :-( | 08:50 |
| Dmitrii-Sh | but there's significant progress there, I think I am almost done and I don't need to do much from my side anymore | 08:51 |
| Chipaca | looking at our pics on launchpad, there's a gameshow in the works, "how many years old is this photo" (or, "was this person legally allowed to drive at the time they took this photo") | 09:51 |
| jam | Chipaca, as I get older, my pictures look younger and younger | 09:54 |
| Chipaca | i'm just losing saturation | 09:54 |
| Chipaca | (ignoring the whole "is that a hairline" thing) | 09:55 |
| Chipaca | taking a break | 10:04 |
| Chipaca | what would be the right order to present our modules in the API docs? alphabetical? | 10:59 |
| facubatista | Muy buenos días a todos! | 11:44 |
| Chipaca | facubatista: buen día señor | 11:48 |
| facubatista | hola hola Chipaca | 11:48 |
| facubatista | Chipaca, shall I land that code, or we want to implement deprecation policies first? | 12:15 |
| facubatista | Chipaca, we should have releases and versions, before a deprecation policy | 12:15 |
| facubatista | Chipaca, do we have the PyPI name settled? Let's release 0.1 | 12:16 |
| facubatista | Chipaca, we need a versioning scheme, will we be using "semantic versioning"? | 12:18 |
| facubatista | https://semver.org/ | 12:18 |
| * facubatista uses a more firefox-like approach to versions in his projects, but snapd and snapcraft look like they use SemVer | 12:19 | |
| Chipaca | facubatista: what's the firefox-like approach? | 12:30 |
| Chipaca | I thought they were saying each release is probably incompatible :) | 12:31 |
| Chipaca | oh dang i was rushing through lunch because of the standup, forgetting i'm an hour ahead now :-D | 12:32 |
| * Chipaca finishes his drink and gets coffee | 12:32 | |
| Chipaca | facubatista: go ahead and land | 12:32 |
| facubatista | Chipaca, ack | 12:32 |
| facubatista | Chipaca, with firefox-like I mean basically melting together major and minor | 12:33 |
| facubatista | I currently have Firefox 74.0, for example | 12:34 |
| Chipaca | yeah | 12:34 |
| facubatista | I expect 74.1 being only patches, new release with lot of changes would be 75.0 | 12:34 |
| Chipaca | chrome does that also, right? | 12:34 |
| facubatista | no idea | 12:34 |
| Chipaca | k | 12:34 |
| Dmitrii-Sh | hmm, it seems like we still need to rely on leader-settings-changed (https://discourse.jujucharms.com/t/charm-hooks/1040#heading--leader-settings-changed) for doing things on leadership loss | 12:37 |
| Dmitrii-Sh | even though we don't use leader settings anymore and rely on peer app relation data | 12:37 |
| Dmitrii-Sh | jam: IIRC there was no code added to fire a -changed event for peer app relation data, do you remember? | 12:38 |
| jam | Dmitrii-Sh, so we fire -changed when the peer data changes, but you're asking for a -changed if who-the-leader-is changes ? | 12:40 |
| Dmitrii-Sh | jam: yes, potentially | 12:41 |
| jam | Dmitrii-Sh, so what specifically do you need to do if you lose leadership? | 12:41 |
| jam | I can understand a lack of symmetry, but given you are no longer the leader, a lot of things aren't accessible to you anymore. | 12:42 |
| Dmitrii-Sh | in a keepalived charm I need to change a vrrp instance priority | 12:42 |
| jam | Dmitrii-Sh, charm leadership should not be used for application leadership | 12:42 |
| Dmitrii-Sh | true, I guess I shouldn't re-implement the behavior of the existing charm in this case | 12:43 |
| Chipaca | facubatista: if we had a Makefile I'd add a target to it, but we don't, so I wonder what to do | 12:52 |
| Chipaca | facubatista: add a "make_docs" script? | 12:52 |
| facubatista | Chipaca, "build" isn't a better verb for docs? | 12:53 |
| facubatista | Chipaca, `build-docs`? | 12:53 |
| Chipaca | facubatista: we're in the building-stuff business, so no, an unqualified "build" is never a better verb for any single thing | 12:53 |
| Chipaca | hmm, my kernel now thinks I have 0 cpus online | 13:00 |
| Chipaca | I think I'll reboot now | 13:02 |
| Chipaca | before the hardware agrees | 13:02 |
| Chipaca | jam: standup? | 13:33 |
| jam | sorry, just finishing my other, will brt | 13:33 |
| jam | Chipaca, I have you listed as part of the Canonical group, which seems to have read/write/edit to the docs-wip. Can you check if you can get to https://discourse.jujucharms.com/c/docs/docs-wip ? | 14:27 |
| facubatista | something I forgot to mention: after https://github.com/canonical/operator/issues/194 I found that we have no tests for "marshaling the event code so we know that all types are simple", so I'll be proposing a PR for that | 14:28 |
| jam | facubatista, sgtm | 14:28 |
| Chipaca | jam: it looks like I can, ys | 14:35 |
| jam | Chipaca, great. I don't have any clue how that will interact with wanting to use Sphinx for a more natural documentation, so I'll wait to hear what we as a project want to do | 14:35 |
| jam | certainly some amount of API reference will be generated from the source tree, but maybe the bigger docs are just discourse posts? | 14:36 |
| Chipaca | that's the idea at the moment, yes | 14:36 |
| jam | (or maybe it is all Sphinx for Charmhub as separate from juju.is) | 14:36 |
| Chipaca | just apidocs from sphinx, "story" docs from discourse | 14:36 |
| Chipaca | keeps the barrier to enter low | 14:36 |
| jam | makes sense to me. | 14:36 |
| jam | the one bit that discourse makes clumsy is 'talking about the doc'. You miss having google-doc Comments, or github review inline comments. | 14:37 |
| jam | You can reply to the post, but it doesn't tell you where your comment is. | 14:37 |
| Chipaca | yep | 14:37 |
| * jam EOD | 14:42 | |
| * facubatista brb | 14:45 | |
| facubatista | reviews appreciated: https://github.com/canonical/operator/pull/195 | 14:45 |
| facubatista | (Test event marshalling, and improved its error message.) | 14:45 |
| * facubatista is back | 14:59 | |
| Chipaca | niemeyer: WRT having example repositories, some of the charms we're looking at will be perfectly functional and useful so having 'example' in the name feels wrong (and I'm not sure you were advocating for having example in the name) | 15:02 |
| Chipaca | niemeyer: would having e.g. canonical/charm-<foo> be reasonable? e.g. canonical/charm-haproxy | 15:03 |
| Chipaca | niemeyer: not sure canonical is the best org for this so if there's another you'd rather have it under, also speak up :) | 15:04 |
| niemeyer | Chipaca: Wasn't advocating for something in particular, no.. just something standardized and reviewed in an expectable location | 15:04 |
| Chipaca | niemeyer: it being in the same org as operator is good | 15:05 |
| Chipaca | niemeyer: and it being charm-<foo> seems reasonable to me | 15:05 |
| niemeyer | haproxy-operator? | 15:05 |
| Chipaca | oo, could be | 15:05 |
| Chipaca | i like that | 15:05 |
| Chipaca | niemeyer: what about the ones that get k8s in their name, how would those look? | 15:06 |
| Chipaca | haproxy-k8s-operator? | 15:06 |
| Chipaca | hakpr8xys | 15:06 |
| * Chipaca takes that last one back -- to use it for something else | 15:06 | |
| niemeyer | Do they need that in their names? | 15:06 |
| Chipaca | niemeyer: dunno, seems to be a pattern that exists | 15:06 |
| Chipaca | not sure if they're operator framework charms tho | 15:06 |
| Chipaca | niemeyer: there's mysql and mysql-k8s i think | 15:07 |
| Chipaca | that sort of thing | 15:07 |
| niemeyer | That first suggestion seems reasonable (foo-k8s-operator) | 15:07 |
| Chipaca | OK! We'll run with that and see how far we get | 15:07 |
| facubatista | Chipaca, but also we will have pure examples, not really functional charms | 15:10 |
| facubatista | "functional" in the sense of "people will use this in production because it provides a functionality for something" | 15:10 |
| niemeyer | Why? Isn't a functional charm a better example? | 15:11 |
| Chipaca | facubatista: yes, we'll have an incremental bit-by-bit example as part of a tutorial | 15:11 |
| Chipaca | facubatista: but that's not executable code, really | 15:12 |
| Chipaca | that is, not code you check out and run | 15:12 |
| Chipaca | niemeyer: it depends what the example is for | 15:13 |
| Chipaca | niemeyer: an example can be something for you to base your work on, in which case yes a fully worked out, working example is best | 15:14 |
| niemeyer | It seems fine to have a charm that is not *useful*, but it should be functional in the sense that it actually works | 15:14 |
| Chipaca | niemeyer: an example can be a learning tool, in which case a lot of the stuff you do for a production-ready one you omit | 15:14 |
| niemeyer | It probably needs to do something as well, whatever it is.. something that does nothing is not very interesting as an example or otherwise | 15:15 |
| Chipaca | also, when you use an example as a didactic tool for a tutorial, you build on it … the example changes throughout the tutorial | 15:15 |
| Chipaca | the tutorial isn't "read this code and be enlightened" | 15:15 |
| Chipaca | most people don't learn that way | 15:15 |
| facubatista | Chipaca, I've seen tutorials where they build the final code step by step, and each step is a commit of the final project | 15:16 |
| facubatista | niemeyer, "a charm that is not *useful*, but it should be functional in the sense that it actually works" <-- yes, exactly, this is what I meant | 15:16 |
| niemeyer | That's a bit problematic because if you want to change a step you need to break people's checkouts | 15:16 |
| facubatista | my point is don't know if to put a whole project for something that is not useful | 15:17 |
| niemeyer | One option might be a repository with directories named step-1, step-2, etc.. | 15:18 |
| niemeyer | But it's unclear whether there's much value on it by itself | 15:18 |
| niemeyer | Perhaps for testing purposes, ensuring the tutorial remains valid | 15:18 |
| niemeyer | But otherwise, the tutorial can live on its own | 15:18 |
| Chipaca | I'm going to go for a run before the clouds break down | 15:24 |
| Chipaca | brb | 15:24 |
| * facubatista brb | 15:29 | |
| * facubatista is back | 15:37 | |
| facubatista | currently, or launchpad builders, are doing anything windows-related? | 16:42 |
| Chipaca | I don't think so | 16:55 |
| Chipaca | but maybe wgrant knows more :) | 16:55 |
| facubatista | Chipaca, I just asked Colin, yes | 17:01 |
| * facubatista keeps improving the doc | 17:01 | |
| Chipaca | I'm EODing, mostly. Might pop back later tonight if my brain bubbles up some docs insight :) | 17:32 |
| Chipaca | 👋 | 17:32 |
| facubatista | unit-my-super-charm-8: 15:06:18 DEBUG unit.my-super-charm/8.upgrade-charm from ops.framework import Object, EventSource, EventBase, EventsBase, StoredState | 18:06 |
| facubatista | unit-my-super-charm-8: 15:06:18 DEBUG unit.my-super-charm/8.upgrade-charm ImportError: cannot import name 'EventsBase' | 18:06 |
| facubatista | je :( | 18:06 |
| * facubatista eods | 20:38 | |
| facubatista | see you all tomorrow! | 20:38 |
| niemeyer | Have a good evening, Facundo | 20:42 |
| facubatista | niemeyer, thanks! same for you | 20:42 |
| niemeyer | Thanks! | 20:45 |
| Dmitrii-Sh | https://trello.com/c/nPJqB61l - I added the information on the progress so far to this note. A bundle with the current charms is available here along with some instructions: https://github.com/dshcherb/bundle-cockroachdb-ha | 22:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!