| meena | turova: what do your logs say? | 08:33 |
|---|---|---|
| turova | meena it looks like it loads a network-config file from the mounted cloudinit drive that has correct values, but those never get to their destination | 12:50 |
| turova | it reads from /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg, finds that it has no interfaces to rename (maybe because I already did that) and then just writes the blank config over | 12:52 |
| meena | iiiiiinteresting. | 13:28 |
| turova | it supposedly works with the premade proxmox OS templates, so I guess I'll just pull one of those down and see what the differences are when I have some time | 13:41 |
| meena | *nod *nod *nod | 14:06 |
| * meena has never worked with proxmox | 14:06 | |
| otubo | Odd_Bloke: Hi! I've already signed the CLA, can you take a quick look at https://github.com/canonical/cloud-init/pull/70 whenever you have time? Should I update the branch? | 15:29 |
| robjo | no assigned reviewer yet for https://github.com/canonical/cloud-init/pull/162 can we please get some eyes on this? thanks | 16:23 |
| blackboxsw | robjo: I'll give first pass today | 16:24 |
| blackboxsw | thanks | 16:24 |
| meena | robjo: i have read your email to the list… and i like it. | 16:26 |
| meena | robjo: do you think you could outline what a refactoring would look like in my document? | 16:27 |
| robjo | meena: I think the step before such an outline is to get conceptual agreement, i.e. rharper blackboxsw, smoser and others would have to agree that this rather large change is the way forward w.r.t. network config writing | 16:29 |
| meena | robjo: i meant… in words. | 16:29 |
| robjo | Well it would basically the same as what I stated in e-mail. I thought about whether I wanted to comment in the doc or via e-mail and then decided to go with the e-mail approach | 16:30 |
| meena | robjo: aye. | 16:33 |
| meena | robjo: so, my main issue re writing network config is that right now, a lot of code for reading and *directly* manipulating (Ephemeral*) network only works on linux. | 16:34 |
| meena | so Goneri created a cool patch for FreeBSD, but it only works for DataSources that don't rely on the network. | 16:34 |
| robjo | I get that. The question for me becomes do we want to add another way of handling it on the side YOUR_FAVORITE_BSD rendereror are we better of to stick this stuff with the distro implementation | 16:37 |
| Goneri | yes, we should have a method in distros/freebsd.py to set-up a temporary network. | 16:38 |
| robjo | based on the way things look ATM I think there is a good argument to be made that the network config rendering belongs with the distribution implementation in some way, i.e. the distro implementation knows how it should render the network config rather than the network config is generic and considers distribution needs as a side effect | 16:38 |
| Goneri | on BSD, Yes. On Linux, it's different. | 16:40 |
| Goneri | this is the reason why the NetBSD and OpenBSD PR come with their own net renderer too. | 16:40 |
| robjo | The temporary network setup, while it works, is not linux generic either. It depends on the dhcp-client package which is no longer supported in SUSE | 16:40 |
| meena | i believe i did mention that somewhere… | 16:41 |
| meena | but it might have just been IRC, so: lost in noise | 16:41 |
| Goneri | Naive question, I'm under the impression the Ephemeral network thing is just here to handle some corner-cases. Is it really the case? | 16:42 |
| robjo | A generic way for the temporary network setup is to have Python code in cloud-init that sends a basic dhcp4 and or dhcp6 request | 16:42 |
| robjo | smoser: was exploring that at som epoint | 16:42 |
| robjo | this would make the temporary network setup generic and should really be the first step | 16:43 |
| meena | i've looked at dhcp implementations in python at one point, and i didn't like what i saw. | 16:50 |
| meena | it would be cool if the OS had standard network library, which exposed dhcp that we could wrap in ctypes and call | 16:51 |
| Goneri | well, we should port NetworkManager on the BSD :-) | 16:54 |
| blackboxsw | otubo: thanks! I think you probably need to use util.del_file() https://github.com/canonical/cloud-init/pull/70/files#r365882842 and I just added a couple of minor nits in review as well. | 16:55 |
| blackboxsw | otubo: other than the nits, it looks good to go | 16:55 |
| blackboxsw | and we can merge that today when you get a chance to resolve or respond/reject comments. | 16:56 |
| meena | Goneri: when i suggested we port netplan, you were against it! | 16:56 |
| Goneri | I was joking in both cases, the real solution being systemd-networkd :-) | 16:59 |
| smoser | meena: python-scapy was the only thing that I thought could relaly get us there. | 17:26 |
| meena | smoser: scapy looks powerful… dangerously so. | 18:21 |
| smoser | meena: well.. doing a dhcp client really *should* be easy. | 18:26 |
| smoser | but, almost hilariously, all example dhcp clients in python assume there is already an ip address on the interface. | 18:26 |
| smoser | from memory... they do not use raw sockets and would need to to actually do a dhcp request on a nic that did not have an ip yet. | 18:27 |
| meena | soooooo, that's why it needs libpcap? | 18:29 |
| meena | okay, so, how do we get buy-in? i think maybe i'll be able to attend tomorrow's meeting and try to "sell" robjo's idea? | 20:11 |
| robjo | Well the ISC reference implementation for DHCP is Mozilla Public License 2.0 thus we cannot subsume it and wrap a Python interface around it. I am afraid if we are going to be independent of any external tool for the temporary network setup someone has to sit down and write the code in Python and send a PR | 20:19 |
| robjo | That would resolve the issue on *BSD for the temporary network setup, and would resolve the issue on SUSE w.r.t. depending on an unsupported package | 20:20 |
| robjo | After that the second step is to decide on the renderer approach | 20:21 |
| robjo | From my perspective there is buy in for step 1 already | 20:21 |
| rharper | replacing the EphemeralDHCP with a scapy (or something else) aka- cloud-init-dhclient is definitely something we're interested in; it allows us to drop the dhclient package from newer images, and sounds like it can be more portable to non-linux distros as well | 20:25 |
| rharper | for renderers and net module refactoring; I'm certainly on board with the goal of enhacing cross platform and cross distro support for the cloudinit.net module and additional renderers (and robjo distro variant support within a renderer class) | 20:27 |
| meena | i feel like a giant but should be coming out of rharper any second now | 20:47 |
| meena | gon… damn. | 21:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!