| facundo__ | ¡Muy buenos días a todos! | 10:49 |
|---|---|---|
| bthomas | morning facundo__ | 10:49 |
| facundo__ | hola bthomas | 10:49 |
| bthomas | facundo__: Just going through your dbinterface example. I may have a couple of questions and comments regarding it later today. I will post on MM or request a 1:1, perhaps after standup. Hope that is ok. | 10:50 |
| facundo__ | bthomas, let's talk before, I will miss the standup (virtual meeting with kid's school) and later I'm complicated | 10:51 |
| facundo__ | bthomas, I have a meeting in 9', it should take an hour, later I'm free | 10:52 |
| bthomas | facundo__: ok I will send you a calendar invite now. Will check your schedule. | 10:52 |
| JoseMasson | good morning! | 11:59 |
| bthomas | morning | 12:30 |
| * bthomas -> lunch | 13:59 | |
| * bthomas -> back | 14:26 | |
| === mup_ is now known as mup | ||
| cory_fu | I opened https://discourse.charmhub.io/t/versioning-interface-protocol-apis/3956 for discussion because evolving interface protocols over time has been a repeated pain point for me, and I'd really like to see this handled well in the new framework (at least doing a good job of promoting a good standard and making it easy to implement). | 17:55 |
| jldev | cory_fu: the last conversation about relation epochs was targeted at Juju. The idea would be for metadata.yaml to include an epoch range for each relation, and to negotiate the epoch on add-relation. Juju would then communicate the epoch into each charm, so they could have unique code paths (probably different classes) | 18:25 |
| jldev | The advantage to having this functionality in Juju, over a lighterweight approach in the Framework, is Juju could prevent a charm-upgrade from breaking a currently working relation. | 18:27 |
| jldev | We're actively working on a relation "handler" pattern in the Framework. being able to specify a class which handles a relation and provides its own events, observable by the charm. This pattern could be extended to support epochs by allow the charm to specify a different class for each supported epoch. | 18:30 |
| cory_fu | Well, the relation would only "break" if one side dropped support for the older version. That approach also means that the charm author has to keep the metadata.yaml in sync with the version of the library they're using. | 18:30 |
| jldev | The current goal of the handler pattern is charm libraries - for example, Prometheus will be able to provide a library which handles its scrape-target relation - so each charm author doesn't need to learn the innerworkings of the relationship, and write their own code. | 18:31 |
| cory_fu | If interfaces are libraries, then it seems reasonable for them to manage any protocol changes, as long as they have the tools to do so. | 18:31 |
| jldev | cory_fu: That's exactly the point of epochs, is being able deprecate and drop support for older versions. | 18:32 |
| cory_fu | Ah, fair. | 18:32 |
| jldev | Even with an interface library, you may control the code on both ends, but you cannot guarantee they are in sync. So you still would want epochs to isolate breaking changes | 18:33 |
| jldev | There's more benefit of having epochs in metadata.yaml, like being able to issue deprecation notices to all charm authors consuming epoch 1 of your interface. But that's a consideration for down the road. | 18:35 |
| cory_fu | The "handler" pattern for interface libraries sounds pretty much like what we've been doing so far (e.g., https://github.com/charmed-kubernetes/interface-k8s-service), and that pattern is close enough to how "interface layers" in charms.reactive were intended to work (though they should have been proper libraries, rather than layers... like everything else) that I recently created a "compatibility shim" to try to make it so interface | 18:42 |
| cory_fu | libraries written for the Operator framework can be used directly in reactive charms to help encourage everyone to adopt the new framework as much as possible. | 18:42 |
| cory_fu | https://github.com/juju-solutions/ops-reactive-interface/tree/initial-impl is the shim, and basically just relies on some entry point definitions in the interface's setup.py | 18:44 |
| cory_fu | It's still in review (https://github.com/juju-solutions/ops-reactive-interface/pull/1) / consideration stage. I am worried about it being a bit of magic and potential fragility against changes to the framework, but I'm also willing to actively maintain it so that I don't have to maintain two copies of a bunch of interface libraries. | 18:45 |
| mup | PR juju-solutions/ops-reactive-interface#1: Helper for operator-framework focused interface libraries to be used in reactive charms <Created by johnsca> <https://github.com/juju-solutions/ops-reactive-interface/pull/1> | 18:45 |
| cory_fu | I'd really appreciate feedback on that. | 18:45 |
| cory_fu | And I'd also like it to become moot as quickly as possible as everyone updates their charms to the new framework. ;) | 18:46 |
| jldev | cory_fu: I had considered trying to work on something similar. But there's a lot of layers of the framework which would need to be repeated in Reactive for full compatibility. I'll take a look at what you've done when I have a few minutes. | 18:47 |
| cory_fu | It's basically just running a stripped down version of the actual Operator framework in the reactive charm, TBH. The Operator framework is a lot lighter weight than the reactive framework, so I don't think it'll add much overhead at all. | 18:49 |
| cory_fu | There are definite caveats, and I really don't want to restrict interface authors in ways that will prevent good designs going forward, but so far it doesn't seem like it should place too many restrictions. Haven't used it in anger, of course, but I plan to with the loadbalancer interface I'm working on. Dev that from the ops framework perspective first and foremost and then fix up any issues that reactive charms run into in the shim. | 18:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!