[16:12] <powersj> magicalChicken: you around?
[17:05] <magicalChicken> powersj: yeah, I'm just running really late toda
[17:20] <powersj> magicalChicken: no worries I sent you mail about the merge
[17:35] <magicalChicken> 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] <magicalChicken> that's probably the cleanest way to do it
[17:38] <powersj> magicalChicken: ok thanks - is there something I should (or shouldn't) be doing to prevent this?
[17:42] <magicalChicken> 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] <magicalChicken> 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] <powersj> ok my bad, gotta do rebase next time
[17:46] <magicalChicken> i think i messed up pulling in from your branch a couple times as well, it was just confusing overall
[19:14] <jgrimm> powersj, would you be able to verification-done-xenial on https://bugs.launchpad.net/cloud-init/+bug/1644043?
[19:15] <powersj> jgrimm: ah yes! that was only a unit test change too, but let me pull it down and take a look anyway
[19:15] <jgrimm> powersj, thanks, part of getting it out of -proposed
[19:20] <jgrimm> powersj, also yakkety verification for https://bugs.launchpad.net/cloud-init/+bug/1635350
[19:23] <magicalChicken> 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] <powersj> jgrimm: looking
[19:25] <powersj> magicalChicken: thank you very much for doing that
[19:36] <powersj> jgrimm: done
[19:36] <jgrimm> powersj, thanks sir
[22:34] <aixtools> 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] <aixtools> this will relate to alias addresses, and the routine cloudinit.netinfo.netdev_info()
[22:36] <aixtools> I am assuming that aliases are parsed on linux as separate devices, e.g.,
[22:36] <aixtools> eth0, eth0:0 eth0:1, etc..
[22:37] <aixtools> 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] <aixtools> e.g.,
[22:38] <aixtools> en0: flags=1e084863,480<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST,GROUPRT,64BIT,CHECKSUM_OFFLOAD(ACTIVE),CHAIN>
[22:38] <aixtools>         inet 192.168.129.72 netmask 0xffffff00 broadcast 192.168.129.255
[22:38] <aixtools>         inet6 fe80::f8d1:83ff:fe60:3304/64
[22:38] <aixtools>         inet 192.168.90.72 netmask 0xffffff00 broadcast 192.168.90.255
[22:38] <aixtools> any comments, suggestions?
[22:39] <aixtools> the inet6 addresses can be skipped over (initially).
[22:42] <rharper> 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] <rharper> 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] <aixtools> eni (as in how I might write enX, as I thought linux used ethX
[22:44] <aixtools> 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] <rharper> 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] <rharper> aixtools: right, that's a reasonable per-distro abstraction I think
[22:45] <aixtools> (it was messy looking to try and code it "within" imho.)
[22:46] <rharper> the aix output doesn't look too different than 'ip a' output;
[22:46] <aixtools> i guess what it comes down to is: what is the "dev" that is returned suppossed to look like.
[22:46] <rharper> ah, likely a dictionary, lemme look
[22:48] <rharper> 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] <rharper> http://paste.ubuntu.com/23635846/
[22:49] <rharper> that formatting is then dumped in a table like that during boot
[22:49] <rharper> so, you need a dictionary with keys 'up
[22:49] <rharper> up, addr, mask, hwaddr, addr6, scope6
[22:50] <rharper> which I think you can parse out from your output from above
[22:50] <aixtools> how does that look (now) when you have aliases, and multiple ipv6?
[22:50] <rharper> the dev name includes :0 :1
[22:50] <rharper> it only shows the first one
[22:50] <aixtools> as is (at least for ipv4, the inet aka addr is overwriting the earlier one
[22:50] <rharper> AFAICT, the netinfo is not meant to be exhaustive
[22:50] <rharper> just minimally informative during boot
[22:51] <rharper> yeah
[22:51] <aixtools> we, it is hard for me to know where/when the info is used.
[22:51] <aixtools> question: re: eth0
[22:51] <rharper> it's only used within that single file
[22:52] <aixtools> is eth0, the "real" address, and eth0:0 the first alias? eth0:1 the second alias, etc?
[22:52] <rharper> eth0 is the base device, the first atlias will be :1 and up
[22:53] <rharper> eth0:0 AFAIK doesn't exist for linux devices and I don't think it can be used in place of 'eth0'
[22:54] <aixtools> [23:50] <rharper> the dev name includes :0 :1 - why I asked...
[22:54] <rharper> sorry, my typo
[22:54] <aixtools> well, in askubuntu... i see: You can use ifconfig command to configure a network interface and alias. For example:
[22:54] <aixtools>     eth0 NIC IP 192.168.1.5
[22:54] <aixtools>     eth0:0 first NIC alias: 192.168.1.6
[22:55] <aixtools> from http://askubuntu.com/questions/585468/how-do-i-add-an-additional-ip-address-to-an-interface-in-ubuntu-14
[22:55] <aixtools> so, it would seem from that that :0 is used, and it is the first alias.
[22:56] <aixtools> so, i guess for AIX (and later ip a) processes an additional "new device" discovery will be needed.
[22:57] <rharper> 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] <aixtools> 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] <aixtools> nods. I hope I understand better how the "devname" in the dictionary are (and when) are created.
[22:59] <rharper> the names are created when the network configuration is applied, netinfo is only extracting existing data from the OS network config
[22:59] <aixtools> re: ipv6 - guessing...
[22:59] <aixtools>  inet6 ::1%1/128
[22:59] <aixtools> and
[23:02] <aixtools>  inet6 fe80::f8d1:83ff:fe60:3304/64
[23:02] <aixtools> i am thinking the /128 and /64 are giving the scope - somewhat.
[23:02] <aixtools> perhaps better is: f* and ::*
[23:02] <aixtools> moment
[23:02] <rharper> the mask is useful
[23:03] <aixtools> 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] <jgrimm> o/
[23:08] <powersj> take care!
[23:10] <aixtools> anyway, took too long to figure out pastebin again.