=== shardy_afk is now known as shardy | ||
=== shardy is now known as shardy_lunch | ||
=== shardy_lunch is now known as shardy | ||
powersj | magicalChicken: you around? | 16:12 |
---|---|---|
=== rangerpbzzzz is now known as rangerpb | ||
magicalChicken | powersj: yeah, I'm just running really late toda | 17:05 |
powersj | magicalChicken: no worries I sent you mail about the merge | 17:20 |
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:35 |
powersj | magicalChicken: ok thanks - is there something I should (or shouldn't) be doing to prevent this? | 17:38 |
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:42 |
powersj | ok my bad, gotta do rebase next time | 17:44 |
magicalChicken | i think i messed up pulling in from your branch a couple times as well, it was just confusing overall | 17:46 |
jgrimm | powersj, would you be able to verification-done-xenial on https://bugs.launchpad.net/cloud-init/+bug/1644043? | 19:14 |
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:15 |
jgrimm | powersj, also yakkety verification for https://bugs.launchpad.net/cloud-init/+bug/1635350 | 19:20 |
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:23 |
powersj | jgrimm: looking | 19:25 |
powersj | magicalChicken: thank you very much for doing that | 19:25 |
powersj | jgrimm: done | 19:36 |
jgrimm | powersj, thanks sir | 19:36 |
=== rangerpb is now known as rangerpbzzzz | ||
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:34 |
aixtools | this will relate to alias addresses, and the routine cloudinit.netinfo.netdev_info() | 22:35 |
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:36 |
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:37 |
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:38 |
aixtools | the inet6 addresses can be skipped over (initially). | 22:39 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
rharper | eth0:0 AFAIK doesn't exist for linux devices and I don't think it can be used in place of 'eth0' | 22:53 |
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:54 |
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:55 |
aixtools | so, i guess for AIX (and later ip a) processes an additional "new device" discovery will be needed. | 22:56 |
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:57 |
aixtools | nods. I hope I understand better how the "devname" in the dictionary are (and when) are created. | 22:58 |
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 | 22:59 |
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:02 |
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:03 |
* rharper heads out for holiday | 23:08 | |
jgrimm | o/ | 23:08 |
powersj | take care! | 23:08 |
aixtools | anyway, took too long to figure out pastebin again. | 23:10 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!