/srv/irclogs.ubuntu.com/2016/12/15/#cloud-init.txt

=== shardy_afk is now known as shardy
=== shardy is now known as shardy_lunch
=== shardy_lunch is now known as shardy
powersjmagicalChicken: you around?16:12
=== rangerpbzzzz is now known as rangerpb
magicalChickenpowersj: yeah, I'm just running really late toda17:05
powersjmagicalChicken: no worries I sent you mail about the merge17:20
magicalChickenpowersj: 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 version17:35
magicalChickenthat's probably the cleanest way to do it17:35
powersjmagicalChicken: ok thanks - is there something I should (or shouldn't) be doing to prevent this?17:38
magicalChickenpowersj: I don't really know what happened before, I think the issue may have been merging rather than rebasing, but I'm not sure17:42
magicalChickenwhat 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 older17:42
powersjok my bad, gotta do rebase next time17:44
magicalChickeni think i messed up pulling in from your branch a couple times as well, it was just confusing overall17:46
jgrimmpowersj, would you be able to verification-done-xenial on https://bugs.launchpad.net/cloud-init/+bug/1644043?19:14
powersjjgrimm: ah yes! that was only a unit test change too, but let me pull it down and take a look anyway19:15
jgrimmpowersj, thanks, part of getting it out of -proposed19:15
jgrimmpowersj, also yakkety verification for https://bugs.launchpad.net/cloud-init/+bug/163535019:20
magicalChickenpowersj: I finished cherry-picking the commits from your repo into the rebase, and ran a few tests. It looks like everything's good to go19:23
powersjjgrimm: looking19:25
powersjmagicalChicken: thank you very much for doing that19:25
powersjjgrimm: done19:36
jgrimmpowersj, thanks sir19:36
=== rangerpb is now known as rangerpbzzzz
aixtoolshi 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
aixtoolsthis will relate to alias addresses, and the routine cloudinit.netinfo.netdev_info()22:35
aixtoolsI am assuming that aliases are parsed on linux as separate devices, e.g.,22:36
aixtoolseth0, eth0:0 eth0:1, etc..22:36
aixtoolsI 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 aliases22:37
aixtoolse.g.,22:38
aixtoolsen0: 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.25522:38
aixtools        inet6 fe80::f8d1:83ff:fe60:3304/6422:38
aixtools        inet 192.168.90.72 netmask 0xffffff00 broadcast 192.168.90.25522:38
aixtoolsany comments, suggestions?22:38
aixtoolsthe inet6 addresses can be skipped over (initially).22:39
rharperaixtools: cloud-init will be moving to that format, the eni rendering for debian will start using additional stanzas instead of : for alias interfaces22:42
rharperand 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 thing22:43
aixtoolseni (as in how I might write enX, as I thought linux used ethX22:43
aixtoolswell, 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
rharpersorry, 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
rharperaixtools: right, that's a reasonable per-distro abstraction I think22:45
aixtools(it was messy looking to try and code it "within" imho.)22:45
rharperthe aix output doesn't look too different than 'ip a' output;22:46
aixtoolsi guess what it comes down to is: what is the "dev" that is returned suppossed to look like.22:46
rharperah, likely a dictionary, lemme look22:46
rharperso, 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 output22:48
rharperhttp://paste.ubuntu.com/23635846/22:48
rharperthat formatting is then dumped in a table like that during boot22:49
rharperso, you need a dictionary with keys 'up22:49
rharperup, addr, mask, hwaddr, addr6, scope622:49
rharperwhich I think you can parse out from your output from above22:50
aixtoolshow does that look (now) when you have aliases, and multiple ipv6?22:50
rharperthe dev name includes :0 :122:50
rharperit only shows the first one22:50
aixtoolsas is (at least for ipv4, the inet aka addr is overwriting the earlier one22:50
rharperAFAICT, the netinfo is not meant to be exhaustive22:50
rharperjust minimally informative during boot22:50
rharperyeah22:51
aixtoolswe, it is hard for me to know where/when the info is used.22:51
aixtoolsquestion: re: eth022:51
rharperit's only used within that single file22:51
aixtoolsis eth0, the "real" address, and eth0:0 the first alias? eth0:1 the second alias, etc?22:52
rharpereth0 is the base device, the first atlias will be :1 and up22:52
rharpereth0: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
rharpersorry, my typo22:54
aixtoolswell, 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.522:54
aixtools    eth0:0 first NIC alias: 192.168.1.622:54
aixtoolsfrom http://askubuntu.com/questions/585468/how-do-i-add-an-additional-ip-address-to-an-interface-in-ubuntu-1422:55
aixtoolsso, it would seem from that that :0 is used, and it is the first alias.22:55
aixtoolsso, i guess for AIX (and later ip a) processes an additional "new device" discovery will be needed.22:56
rharperright, 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 dictionary22:57
aixtoolsanyway, 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
aixtoolsnods. I hope I understand better how the "devname" in the dictionary are (and when) are created.22:58
rharperthe names are created when the network configuration is applied, netinfo is only extracting existing data from the OS network config22:59
aixtoolsre: ipv6 - guessing...22:59
aixtools inet6 ::1%1/12822:59
aixtoolsand22:59
aixtools inet6 fe80::f8d1:83ff:fe60:3304/6423:02
aixtoolsi am thinking the /128 and /64 are giving the scope - somewhat.23:02
aixtoolsperhaps better is: f* and ::*23:02
aixtoolsmoment23:02
rharperthe mask is useful23:02
aixtoolsf* 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
jgrimmo/23:08
powersjtake care!23:08
aixtoolsanyway, 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!