| slyon | schopin: Yeah.. I have been considering pygobject as well before. Up to now I've been trying to avoid that added dependency and defined minimal internal data structures via ctypes (like GError in the cli_get_set tests). | 07:21 |
|---|---|---|
| slyon | But we're using many glib data structures in libnetplan and considering the consolidation of C/Python parsers it might be really helpful to be able to access all those, in order to simplify the integration. src:pygobject is already in Ubuntu "main" so that shouldn't be a problem. | 07:24 |
| slyon | Considering the size... python3-gi adds ~200kB (where netplan.io + libnetplan0 are ~150kB), so that's quite heavy... but should probably not bloat the initramfs too much, I guess. | 07:25 |
| slyon | So if you think this is the best/cleanest approach, especially considering the consolidation of parsers as well, I'd say: go for it! | 07:25 |
| schopin | slyon: where are the sources for our NM netplan plugin? I found this https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/556/ but is there a standalone repo somewhere? | 07:52 |
| slyon | schopin: yeah, that was the (old) upstream RFC that was rejected. The "official" upstream (i.e. what is being shipped in the network-manager/20/stable snap would be this patch: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snap-patch/networkmanager/0002-nm-netplan-keyfile.patch?h=snap-20 | 07:57 |
| slyon | There is also a repo somewhere on my personal github that should (currently) be equivalent to that patch. let me find the link. | 07:58 |
| slyon | https://github.com/slyon/NetworkManager/commits/slyon/backend-1.22.10 | 07:59 |
| schopin | My current plans are to first move all the globals into a single netplan_state structure. This'll allow me to pass a pointer to this structure in any new API that I need to design, instead of relying on global state, whereas the old API can still use a global instance of this structure | 08:00 |
| schopin | thanks for the link :) | 08:00 |
| slyon | ack. sounds good. We just need to make sure not to break the ABI as well. But IIRC non of our consumers (NetworkManager snap & netplan.io python CLI) are accessing the globals directly. So we should be fine moving them into a struct (also long as keeping the old globals around, not to change the memory layout) | 08:12 |
| schopin | That's the thing : we cannot keep the old globals around. | 08:13 |
| schopin | Well, not netdefs_ordered. | 08:13 |
| schopin | Unless we want to duplicate the list, which seems like an error waiting to happen. | 08:14 |
| schopin | But if we don't have any consumer code accessing those globals directly, why would we want to keep them around? | 08:15 |
| schopin | also, do we need to consider the Python CLI as a proper consumer of the ABI? It seems reasonable to me to expect a lockstep upgrade of both libnetplan and netplan.io as they're from the same source package. | 08:50 |
| slyon | hmm... I mean that's fine going forward, bumping the soversion of the library. But I wonder how we could support the stable/LTS series, I guess we'd need lots of backporting then.. | 08:54 |
| slyon | libnetplan and the netplan.io python CLI can be upgraded independently right now. And that was how we discovered an ABI breakage in the 0.102 release. We could update the packaging of netplan in Ubuntu, though, to fix that situation and make them only upgrade in parallel. | 08:56 |
| slyon | But it's a bit trickier for the NetworkManager snap, especially as it currently still vendorizes it's own copy of libnetplan that might then be incompatible with the one installed in the Ubuntu Core20 base system | 08:57 |
| slyon | I think we would at least need to keep the globals around and fill them with NULL, so that the memory layout doesn't change. Appending any new data structures to the end. But I guess I need to think a bit more about how we can keep this backwards compatible to the stable series. | 08:59 |
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!