=== shardy_afk is now known as shardy === shardy is now known as shardy_lunch === shardy_lunch is now known as shardy [16:12] magicalChicken: you around? === rangerpbzzzz is now known as rangerpb [17:05] powersj: yeah, I'm just running really late toda [17:20] magicalChicken: no worries I sent you mail about the merge [17:35] powersj: I can go ahead and cherry-pick the commits made in your branch since the last time I merged and apply them onto the rebased version [17:35] that's probably the cleanest way to do it [17:38] magicalChicken: ok thanks - is there something I should (or shouldn't) be doing to prevent this? [17:42] powersj: I don't really know what happened before, I think the issue may have been merging rather than rebasing, but I'm not sure [17:42] what ended up happening with a lot of the conflicts in the cloud_tests is that a newer version of the code seemed to exist before the older [17:44] ok my bad, gotta do rebase next time [17:46] i think i messed up pulling in from your branch a couple times as well, it was just confusing overall [19:14] powersj, would you be able to verification-done-xenial on https://bugs.launchpad.net/cloud-init/+bug/1644043? [19:15] jgrimm: ah yes! that was only a unit test change too, but let me pull it down and take a look anyway [19:15] powersj, thanks, part of getting it out of -proposed [19:20] powersj, also yakkety verification for https://bugs.launchpad.net/cloud-init/+bug/1635350 [19:23] powersj: I finished cherry-picking the commits from your repo into the rebase, and ran a few tests. It looks like everything's good to go [19:25] jgrimm: looking [19:25] magicalChicken: thank you very much for doing that [19:36] jgrimm: done [19:36] powersj, thanks sir === rangerpb is now known as rangerpbzzzz [22:34] hi all, i was looking through netinfo.py - looking to port cloud-init-0.7.8 for AIX and see something that is probably not "close". [22:35] this will relate to alias addresses, and the routine cloudinit.netinfo.netdev_info() [22:36] I am assuming that aliases are parsed on linux as separate devices, e.g., [22:36] eth0, eth0:0 eth0:1, etc.. [22:37] I am wondering how I should processes this for AIX - in a compareable way, as for AIX the "device" en0 will have multiple inet (aka addr) lines - the first one is the real address, and the following ones are the aliases [22:38] e.g., [22:38] en0: flags=1e084863,480 [22:38] inet 192.168.129.72 netmask 0xffffff00 broadcast 192.168.129.255 [22:38] inet6 fe80::f8d1:83ff:fe60:3304/64 [22:38] inet 192.168.90.72 netmask 0xffffff00 broadcast 192.168.90.255 [22:38] any comments, suggestions? [22:39] the inet6 addresses can be skipped over (initially). [22:42] aixtools: cloud-init will be moving to that format, the eni rendering for debian will start using additional stanzas instead of : for alias interfaces [22:43] and we'll likely parse 'ip a' output to extract multiple ip's per device as well; so I think heading that direction is a good thing [22:43] eni (as in how I might write enX, as I thought linux used ethX [22:44] well, ip a is not something AIX will have soon (if ever) - so I guess my idea od moving it to distros/aix/netinfo.py is not a horrible idea. [22:44] sorry, eni -> /etc/network/interfaces a configuration file ;;; the linux kernel names ethernet device eth- ; however we now have "persistent" naming as well, which incorporates an encoding as to where it was found lom (LAN on MOtherboard) enp1s0 (ethernet on pci bus 1, slot 0) [22:45] aixtools: right, that's a reasonable per-distro abstraction I think [22:45] (it was messy looking to try and code it "within" imho.) [22:46] the aix output doesn't look too different than 'ip a' output; [22:46] i guess what it comes down to is: what is the "dev" that is returned suppossed to look like. [22:46] ah, likely a dictionary, lemme look [22:48] so, in netinfo.py the netdev_pformat shows you the fields it wants in the dev dictionary that the netdev_info creates for each device if found in ifconfig output [22:48] http://paste.ubuntu.com/23635846/ [22:49] that formatting is then dumped in a table like that during boot [22:49] so, you need a dictionary with keys 'up [22:49] up, addr, mask, hwaddr, addr6, scope6 [22:50] which I think you can parse out from your output from above [22:50] how does that look (now) when you have aliases, and multiple ipv6? [22:50] the dev name includes :0 :1 [22:50] it only shows the first one [22:50] as is (at least for ipv4, the inet aka addr is overwriting the earlier one [22:50] AFAICT, the netinfo is not meant to be exhaustive [22:50] just minimally informative during boot [22:51] yeah [22:51] we, it is hard for me to know where/when the info is used. [22:51] question: re: eth0 [22:51] it's only used within that single file [22:52] is eth0, the "real" address, and eth0:0 the first alias? eth0:1 the second alias, etc? [22:52] eth0 is the base device, the first atlias will be :1 and up [22:53] eth0:0 AFAIK doesn't exist for linux devices and I don't think it can be used in place of 'eth0' [22:54] [23:50] the dev name includes :0 :1 - why I asked... [22:54] sorry, my typo [22:54] well, in askubuntu... i see: You can use ifconfig command to configure a network interface and alias. For example: [22:54] eth0 NIC IP 192.168.1.5 [22:54] eth0:0 first NIC alias: 192.168.1.6 [22:55] from http://askubuntu.com/questions/585468/how-do-i-add-an-additional-ip-address-to-an-interface-in-ubuntu-14 [22:55] so, it would seem from that that :0 is used, and it is the first alias. [22:56] so, i guess for AIX (and later ip a) processes an additional "new device" discovery will be needed. [22:57] right, netinfo as is, only works for ifconfig; ideally that method would be refactored to have different network tool output collection (call ip a, or ifconfig, or $distro tool) and convert to a dictionary [22:57] anyway, for now - my goal shall be to create a new device - on the fly, for each additional ipv4 inet, aka tok[0] == "inet" [22:58] nods. I hope I understand better how the "devname" in the dictionary are (and when) are created. [22:59] the names are created when the network configuration is applied, netinfo is only extracting existing data from the OS network config [22:59] re: ipv6 - guessing... [22:59] inet6 ::1%1/128 [22:59] and [23:02] inet6 fe80::f8d1:83ff:fe60:3304/64 [23:02] i am thinking the /128 and /64 are giving the scope - somewhat. [23:02] perhaps better is: f* and ::* [23:02] moment [23:02] the mask is useful [23:03] f* as in fe80:: would always be scope link, ::1 is by definition scope host, and when not f* and not /128 scope is likely global. [23:08] * rharper heads out for holiday [23:08] o/ [23:08] take care! [23:10] anyway, took too long to figure out pastebin again.