| smoser | can we please get the comment linter back. | 02:38 |
|---|---|---|
| smoser | s/comment/commit message/ | 02:38 |
| otubo | I want to set IPV6_AUTOCONF=NO on a link local ipv6 interface on a instance. Do I need to add a special support for it on the code, or just set it on the cloud-init configuration file? I'm not really sure after reading the code. | 11:18 |
| minimal | otubo: on a related vein I've wondered how to configure privext (IPv6 Privacy Extensions) on an interface | 11:20 |
| minimal | Folks, I believe there's an issue with MAC address handling for both v1 and v2 network config files - but I'm confused how then any of the testcases that specify MAC addresses then pass. Basically when I specify a MAC address if I don't quote the value it gets "mangled" (as seen in debug output) whereas when quoted it works as expected. | 11:24 |
| minimal | otubo: in tests/unittests/test_net.py there's a network config v1 example that specifies the following for a bridge (I assume same would work for a physical device): | 11:40 |
| minimal | ipv6_conf: | 11:40 |
| minimal | autoconf: 1 | 11:40 |
| minimal | disable_ipv6: 1 | 11:40 |
| minimal | use_tempaddr: 1 | 11:40 |
| minimal | forwarding: 1 | 11:40 |
| vijayendra | otubo, ping. This is vijayendra | 11:51 |
| otubo | vijayendra: pong | 11:54 |
| otubo | minimal: nice catch. Perhaps vijayendra could give this a try on his tests. | 11:55 |
| minimal | otubo: Looking further I don't see any sign of actual code using these settings... | 11:56 |
| vijayendra | otubo, minimal Probably I missed some info here. Joined late. Let me check in history | 11:56 |
| otubo | I have a thousand of meeting starting now, I'll probably join the office hours to ask this to maintainers | 11:57 |
| minimal | Odd_Bloke: any thoughts on the MAC address issue? | 11:58 |
| Odd_Bloke | smoser: Not particularly easily on GitHub, unfortunately, no: there's no structured place to put a commit message except at merge time. We have talked about using https://bors.tech/ which does have support for using the first portion of the PR description as the commit message (because it handles the squashing) but I don't know if it has commit message linting support. | 13:09 |
| Odd_Bloke | So I think we'd need to modify the linter to be able to parse out the commit message, and then run it as a GH action? (Or maybe a Travis job: as our project is public we can _probably_ just hit GitHub's API from over there instead.) | 13:11 |
| Odd_Bloke | minimal: Testing locally, it looks like MAC addresses that aren't all-digits are interpreted as strings as I would expect: https://paste.ubuntu.com/p/PKTvCJggvh/ | 13:11 |
| Odd_Bloke | (Apologies if these aren't in YAML and I've completely missed the point; my pot of coffee is still brewing. ;) | 13:12 |
| Odd_Bloke | So if you're referencing unit tests, most of them will be passing around Python dicts, which don't have this issue (because they don't pass through YAML parsing to get mangled). | 13:14 |
| minimal | Odd_Bloke: what I'm seeing in the logs is the following: | 13:50 |
| minimal | networking.py[DEBUG]: net: waiting for expected net devices: {41135085296} | 13:50 |
| minimal | where "41135085296" is mangled from 52:54:00:12:34:56 | 13:50 |
| minimal | I'm using NoCloud and have tested both v1 and v2 network config YAML files with the same behaviour | 13:51 |
| minimal | so I'd assumed that MAC addresses should always be quoted and was going to raise a PR to update docs and testcases accordingly - but some testcases fail it I quote their MAC addresses | 13:54 |
| Odd_Bloke | MAC addresses must always be strings; `52:54:00:12:34:56` is, I think, interpreted as a timestamp in YAML (41135085296 seconds since 1970) whereas `"52:54:00:12:34:56"` is a string. | 13:59 |
| minimal | due to this risk of misintepretation I'd expect the docs to mandate quotes around MAC addresses to avoid the issue completely | 14:00 |
| Odd_Bloke | Yeah, agreed; probably worth a `.. note::` or `.. warning::` in the network docs. | 14:02 |
| minimal | Odd_Bloke: the thing is I'd changed the docs in a PR as well as any YAML in testcases that specified MACs to quote then but multiple testcases then failed. | 14:03 |
| Odd_Bloke | Aha, right, I see the PR now, apologies. Let me take a look. | 14:03 |
| minimal | ah, that PR doesn't have the MAC changes, I pulled it from that PR when I spotted the test failures | 14:04 |
| Odd_Bloke | Oh, or maybe you've pulled that chang... yep. | 14:04 |
| Odd_Bloke | If you could pastebin the diff of that commit, I can see if I can see anything. :) | 14:04 |
| minimal | there were a lot of failures in tests/unittests/test_net.py as the expected results (the quoted MACs) didn't match the actual results (non-quoted MACs) | 14:05 |
| Odd_Bloke | minimal: Ah yeah, it looks like some of the tests are expecting the input YAML to successfully roundtrip back out to YAML. | 14:11 |
| Odd_Bloke | But because the quotes aren't _necessary_ for most MAC addresses, they aren't included in the dumped YAML. | 14:11 |
| Odd_Bloke | And so our input quotes disappear and we have a mismatch. | 14:11 |
| minimal | exactly | 14:13 |
| minimal | so to use a horrible phrase, "how do we square this circle"? ;-) | 14:13 |
| amansi26 | smoser:Hi smoser, I would to like to thanks for constantly reviewing my code and recommend changes to my PR https://github.com/canonical/cloud-init/pull/584 . I think we came a long way with it. I addressed all the comments on PR . It will be great if you can review the changes once you get some time. So that any new changes recommended. I will go and addressed them quickly. Thanks | 14:13 |
| Odd_Bloke | minimal: So I'm not particularly concerned about those test failures: they aren't indicating that you've actually broken anything, they're just somewhat brittle tests. So I would suggest that in a first pass, we could just not quote the specific MAC addresses in `test_net.py` that cause the failures. | 14:17 |
| Odd_Bloke | In terms of fixing those tests, the problem is that they expect the YAML input to be "normalised" as it were, and your change means that the input is no longer normalised. We could address that by round-tripping the input through a dump/load before using it as the basis of comparison. | 14:19 |
| minimal | Odd_Bloke: hmm, ok I can have another go at figuring out which ones can safely be quoted. Do you agree the docs should be updated to effectively mandate quotes around MACs? That would avoid this sort of confusion. Think of people using the likes of Ansible and Terraform to create network config files where their code shouldn't have to have the smarts to know when to add or not add quotes | 14:19 |
| Odd_Bloke | If they're using a (spec-compliant) YAML library to dump some sort of datastructure, they should be fine: this isn't a bug in our YAML handling code, it's a weird corner of the spec. But, yeah, there are plenty of cases where this could cause confusion/problems, so I agree the docs should be updated to help people avoid it. | 14:22 |
| minimal | Odd_Bloke: Ok I'll put something together in a PR for this. You mentioned you'd noticed PR 618 which I raised for the users and power_state quoting. | 14:24 |
| minimal | you'll be seeing more PRs from me in the near future as I've fixed "wakeonlan" to actually work for ENI and I've spotted an issue with static routes in ENI which I'm investigating as well. | 14:24 |
| Odd_Bloke | Great! | 14:39 |
| minimal | Odd_Bloke: I think as I'm using cloud-init in non-typical ways (mainly bootstrapping physical RPIs and x86_86 machines) that's why I'm spotting various little issues | 14:41 |
| Odd_Bloke | minimal: We certainly appreciate you feeding back what you're finding to us, both in terms of bugs filed and code. :) | 14:42 |
| meena | cool | 14:48 |
| Odd_Bloke | otubo: #586 landed. :) | 16:05 |
| otubo | Odd_Bloke: thanks a lot! | 16:06 |
| Odd_Bloke | Thanks for the PR! | 16:07 |
| * otubo waiting for office hours | 16:16 | |
| otubo | Odd_Bloke: do we have office hours today? | 16:19 |
| otubo | blackboxsw: ^ :-) | 16:20 |
| Odd_Bloke | otubo: I don't think we're going to have a Discourse post up today, but you can consider office hours officially open. :) | 16:24 |
| otubo | Odd_Bloke: I just have two quick questions :-) | 16:24 |
| otubo | Odd_Bloke: I want to set IPV6_AUTOCONF=NO on a link local ipv6 interface on a instance. Do I need to add a special support for it on the code, or just set it on the cloud-init configuration | 16:25 |
| otubo | file? I'm not really sure after reading the code. | 16:25 |
| otubo | Odd_Bloke: and here I'm talking about RHEL/Fedora/CentOS family with NetworkManager :-) | 16:26 |
| Odd_Bloke | otubo: What does your current configuration look like? | 16:32 |
| otubo | Odd_Bloke: I don't have one yet. I was going to start adding support for it, but reading the code I didn't know for sure I needed. | 16:34 |
| otubo | Odd_Bloke: earlier today minimal pointed to tests/unittests/test_net.py which specifies tests for bridges: | 16:35 |
| otubo | ipv6_conf: | 16:36 |
| otubo | autoconf: 1 | 16:36 |
| otubo | disable_ipv6: 1 | 16:36 |
| otubo | use_tempaddr: 1 | 16:36 |
| otubo | forwarding: 1 | 16:36 |
| otubo | (ah, sorry for the paste) | 16:36 |
| otubo | Wanted to confirm I can use this configurtion for phyisical interfaces too. | 16:36 |
| Odd_Bloke | otubo: I'm looking, having to familiarise myself with a lot of this code. | 16:42 |
| Odd_Bloke | otubo: I can't find anything in the code that reads those `ipv[46]_conf` keys, and the tests still pass if I remove them: I infer that they aren't used, but I can't be sure. | 16:49 |
| otubo | Odd_Bloke: ok, looks like I'm gonna have some fun tomorrow debugging this :-) | 16:51 |
| otubo | So I'll probably need to add some support for it. | 16:52 |
| Odd_Bloke | As for setting IPV6_AUTOCONF=no, it looks to me like it's unconditionally set to True for `ipv6_dhcpv6-stateless` and `ipc6_slaac`: https://github.com/canonical/cloud-init/blob/master/cloudinit/net/sysconfig.py#L411 and https://github.com/canonical/cloud-init/blob/master/cloudinit/net/sysconfig.py#L428 | 16:54 |
| Odd_Bloke | otubo: Yeah, it looks that way to me, at least. | 16:54 |
| Odd_Bloke | (If rharper is around, he may be able to help out a bit more.) | 16:54 |
| otubo | Odd_Bloke: would you think it's reasonable to override the default if user set "ipv6_autoconf: no" on configuration file? | 16:56 |
| rharper | Odd_Bloke: sorta; otubo I think it would be good to understand what IPV6_AUTOCONF means for sysconfig systems, and what NetworkManager does it it; it's just not clear to me documentation wise; I don't have a strong opinion on this. | 16:59 |
| rharper | otubo: I think there is some common definition w.r.t autoconf between eni and sysconfig; but I think we should collect what happens on distros to understand changes to the current default. | 17:01 |
| otubo | rharper: makes sense to me. | 17:01 |
| otubo | rharper: I don't have a particular vast background on this topic to argue that now. But I might have tomorrow after some research. I'll file a bug on Launchpad so we can discuss. | 17:02 |
| rharper | https://bugs.launchpad.net/cloud-init/+bug/1806014 | 17:04 |
| ubot5 | Ubuntu bug 1806014 in cloud-init "[Centos] IPV6_AUTOCONF=no when using dhcp6" [Medium,Fix released] | 17:04 |
| otubo | well that was quick | 17:05 |
| otubo | rharper: before reading it, just wanted to exaplain a little bit on the background of my issue: When an instance is deployed under IBM PowerVS, it needs an ipv6 link local to communicate with the RMC module on the hypervisor. | 17:06 |
| otubo | rharper: apparently this interface fluctuates in stability, and it's tested that using IPV6_AUTOCONF=NO solves the problem | 17:08 |
| otubo | rharper: I'm not the real expert here, probably vijayendra can give more details on this. | 17:09 |
| rharper | well, ideally we'd root cause the problem w.r.t the variance; vijayendra already talked with NM folks and they said you didn't tell us not to do AUTOCONF stuff and so nm is bringin the interface up and down; IIRC | 17:10 |
| rharper | <vijayendra> rharper, I did get in touch with nm developer but he doesn't seems to be in agreement with it. below is his explanation | 17:11 |
| rharper | <vijayendra> rharper, NetworkMAnager fails to get an IPv6 address and it fails the activation. | 17:11 |
| rharper | <vijayendra> Also, the logfile is filled with warnings and messages of the device repeatedly activating and deactivating. | 17:11 |
| rharper | <vijayendra> There is a cycle of NetworkManager trying to autoactivate the profile, and failing and retrying. Of course, | 17:11 |
| rharper | <vijayendra> the IP address thereby gets added and removed again. Fix either your configuration or your network (depending on your circumstances). | 17:12 |
| otubo | Interesting. | 17:13 |
| otubo | Yeah, I think we need to work through this a little better, because now I'm wondering why exactly the interface is behaving like that and why it's not acquiring ip. | 17:14 |
| rharper | for link local, ther'es no acquiring; you just have it ; link local on ivp6 is based on the device mac | 17:15 |
| otubo | rharper: for a reference, just found the BZ vijayendra mentioned https://bugzilla.redhat.com/show_bug.cgi?id=1888569 | 17:26 |
| ubot5 | Error: Error getting bugzilla.redhat.com bug #1888569: NotPermitted | 17:26 |
| vijayendra | rharper, otubo My understanding on this is if there is no entry about IPV6_AUTOCONF, it defaults to yes and this looks for ipv6 router and when no router this ipv6 fluctuation behaviour is found | 17:39 |
| vijayendra | so here in case no router, we need to explicitly say IPV6_AUTOCONF=no which sets ipv6.method to either manual or link-local otherwise with AUTOCONF yes this seems to "auto" which looks for ipv6 router | 17:41 |
| vijayendra | but going through the cloudinig sysconfig.py code, there isn't way to do so for static configuration | 17:42 |
| otubo | vijayendra: did you check on this? https://bugs.launchpad.net/cloud-init/+bug/1806014 | 17:48 |
| ubot5 | Ubuntu bug 1806014 in cloud-init "[Centos] IPV6_AUTOCONF=no when using dhcp6" [Medium,Fix released] | 17:48 |
| otubo | "When instructing cloud-init to use `type: dhcp6` for the subnet of a physical network interface, the end-result is that `/etc/sysconfig/network` contains `IPV6_AUTOCONF=no`." | 17:49 |
| otubo | vijayendra: ^^^ | 17:49 |
| vijayendra | otubo, sorry I missed to check that, checking now | 17:49 |
| meena | i made new bug: https://bugs.launchpad.net/cloud-init/+bug/1900753 | 17:58 |
| ubot5 | Ubuntu bug 1900753 in cloud-init "fix regression: remove dependency on dmidecode" [Undecided,New] | 17:58 |
| vijayendra | otubo, 1806014 is pretty fast. Thanks | 18:04 |
| otubo | vijayendra: does it solve your problem? | 18:05 |
| vijayendra | otubo, will have test with this new change. will update, | 18:06 |
| otubo | vijayendra: nice, thanks! Need to leave now | 18:06 |
| otubo | rharper: thanks for the pointer on that. Hopefully we won't have to touch cloud-init to make that work. | 18:06 |
| vijayendra | otubo, thanks | 18:08 |
| vijayendra | otubo, here looks like we are doing static configuration, for static configuration, this still may not work right? | 18:35 |
| rharper | otubo: vijayendra: yeah; I think there are two points here: 1) there currently isn't a way to disable Router Advertisements for ipv6 static only via network-config 2) why does NM bounce interface configuration/ip if one does not disable RA? ; (1) is a reasonable bug for cloud-init; the gap exists for openstack and network-config v1; netplan allows control over RA (2) is a separate issue with NM; as I don't think RA | 19:04 |
| rharper | should be related to a changing IP; expecially if your environment does not have any ipv6 routers doing advertisements | 19:04 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!