| === paride6 is now known as paride | ||
| blackboxsw | ok so the azure 1 min timeout during ssh-import-id in my SRU testing is really my fault, I'm definitely not setting up IPv6 properly per their preview feature. I'm going to try going through the full howto they've documented there verbatim to see if I can't get that ipv6 timeout to resolve https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/virtual-network/virtual-network-ipv4-ipv6-dual-stack-cli.md. | 16:03 |
|---|---|---|
| blackboxsw | This is *not* a regression in this SRU because the ipv6 timeout exists on the current released cloud-init too. | 16:03 |
| mattia | hello everyone | 16:31 |
| mattia | trying to understand cloud-init reasoning when writing 50-cloud-init.cfg | 16:32 |
| mattia | for in interfaces.d | 16:32 |
| blackboxsw | if a service honors a parts directory (like /etc/network/interfaces does via /etc/network/interfaces.d) cloud-init wants to use the parts directory (/etc/network/interfaces.d in this case) because it allows cloud-init to avoid getting clobbered of something else writing custom config that cloud-init is unaware of. | 16:38 |
| blackboxsw | the config parts directory also allows other programs or users to extend network configuration (maybe for NICs that cloud-init isn't in charge of) in separate config files without having to be worried about cloud-init overwriting their separate config | 16:39 |
| blackboxsw | if other vendors or platforms want to override specific config setup provided by cloud-init they would also have the ability to provide a /etc/network/intefarces.d/51-override-cloud-init.cfg if needed. | 16:41 |
| blackboxsw | hope that helps (if I understood the question) | 16:41 |
| mattia | good: that's what I was thinking :) | 16:45 |
| mattia | now the real problem: I have a problem with debian images writing "static" entries to that file | 16:45 |
| mattia | running openstack | 16:46 |
| mattia | if I understood correctly cloud-init just writes down the JSON it gets from the datasource, correct? | 16:46 |
| Xat` | hello guys, how can I use multiple userdata ? | 17:02 |
| blackboxsw | Xat`: you can try adding multiple text/cloud-config mime parts: https://cloudinit.readthedocs.io/en/latest/topics/format.html#mime-multi-part-archive | 17:09 |
| blackboxsw | or multiple include-file directives https://cloudinit.readthedocs.io/en/latest/topics/format.html#include-file | 17:10 |
| blackboxsw | Odd_Bloke: I confirmed following the dual stack load balancer setup with cloud-init doesn't have the IPv6 timeout issue. https://paste.ubuntu.com/p/zVd3mhJbWc/ | 17:10 |
| Odd_Bloke | mattia: If the data source provides network configuration then cloud-init will use it, yes. | 17:10 |
| Odd_Bloke | blackboxsw: OK, nice. Gonna push up refreshed SRU validation logs? | 17:10 |
| blackboxsw | so it's a problem with my manual setup of dual-stack on a vm in azure, not with cloud-init proper | 17:11 |
| Xat` | blackboxsw: I could also use 'scripts/per-instance' | 17:11 |
| blackboxsw | Odd_Bloke: I need to change up the manual test approach for azure advanced networking setup. I'm hoping to avoid having to setup a load balancer and two vms in azure to test ipv6... but it might be unavoidable :// | 17:12 |
| Xat` | executing scripts only at first boot is fine. "Any scripts in the ``scripts/per-boot`` directory on the datasource will be run | 17:12 |
| Xat` | every time the system boots." | 17:12 |
| Xat` | where is this directory located ? | 17:12 |
| blackboxsw | Xat`: on first boot only, then use the scripts/per-instance directory | 17:13 |
| blackboxsw | Xat`: generally it's in /var/lib/cloud/scripts/per-* | 17:13 |
| Odd_Bloke | blackboxsw: Yeah, needing to set up a load balancer seems like overkill. Would reaching out to an Azure person for assistance perhaps make sense? | 17:13 |
| blackboxsw | there is a per-once directory too if you are creating your own image | 17:13 |
| Xat` | alright !! nice | 17:13 |
| mattia | Odd_Bloke, network information can be also obtained by the dhcp instead of the metadata server? | 17:14 |
| mattia | we are very puzzled: we have this odd "static interface" only with Debian (ubuntu works fine) and only when started in tenants that share the network but do not own it | 17:15 |
| mattia | i.e. all tenants except the admin one | 17:16 |
| Odd_Bloke | mattia: So you'll want to think about this in two phases: cloud-init writes out networking configuration, and then the network provider (ifupdown/netplan/...) acts on the written configuration. | 17:25 |
| Odd_Bloke | cloud-init could write out network configuration to DHCP on an interface (indeed, by default it will write out such configuration for the first interface), and then the second phase will configure the network device based on the DHCP response. | 17:26 |
| Odd_Bloke | Or it could write out a static interface configuration, and then the second phase won't DHCP and so will just use the written configuration. | 17:27 |
| Odd_Bloke | So DHCP isn't an _alternative_ to the cloud-init network configuration, it would be configured _by_ the cloud-init network configuration. | 17:27 |
| Odd_Bloke | So there are a couple of obvious differences between Debian and Ubuntu that I would investigate: cloud-init version, and network provider. | 17:28 |
| Odd_Bloke | What versions of cloud-init are you using across the two distros? | 17:28 |
| Odd_Bloke | And examining /var/log/cloud-init.log might also give you some clues. | 17:29 |
| mattia | I have this "stages.py[INFO]: Applying network configuration from ds bringup=True: {'version': 1, 'config': [{'type': 'physical', 'mtu': 1500, 'subnets': [{'type': 'static', ..." | 17:40 |
| mattia | while on a VM started in the admin tenant I have this: | 17:41 |
| blackboxsw | Odd_Bloke: yeah I've just sent an email to some Azure contacts about ipv6 setup for a single vm | 17:41 |
| mattia | applying net config names for {'version': 1, 'config': [{'type': 'physical', 'mtu': 1500, 'subnets': [{'type': 'dhcp4'}], | 17:45 |
| mattia | same image and same network, the only difference we can see is the tenant | 17:45 |
| Odd_Bloke | mattia: What does `cloud-init query -a` on each one produce? | 17:52 |
| Odd_Bloke | (I'm wondering if the cloud is simply presenting different network config.) | 17:52 |
| usrdev | question - when using a no cloud image cloud image, what would cause the boot-up process to get stuck with standing up the network interface(s) ? | 18:13 |
| usrdev | i noticed hitting enter on console, it proceeds to grab a DHCP assigned IP. but i do not know why i would need to wait or for this to happen. | 18:14 |
| mattia | Odd_Bloke, 'query' does not seem to be a valid option on 18.3 | 18:33 |
| mattia | It does return a lot of information on 19.2 (Ubuntu) | 18:34 |
| mattia | from I see on Ubuntu the network_json does not mention whether the configuration is static or dhcp | 18:39 |
| mattia | *from what I see | 18:39 |
| Odd_Bloke | mattia: Can you pastebin the network config? | 19:02 |
| Odd_Bloke | (The JSON, I mean.) | 19:03 |
| Odd_Bloke | usrdev: What distro (and version) are you running? | 19:03 |
| usrdev | @Odd_Bloke: debian 10 | 18.3 (cloud-init) | 19:11 |
| Odd_Bloke | usrdev: So I expect it's network-online.target that's blocking boot, and it will be doing that because there's a network interface that it is waiting for. | 19:15 |
| usrdev | you'd be correct, watching it boot up that is exactly where it hangs up. this is, after it renames the interface from i believe ens18 to eth0, then stalls there for a bit and proceeds. | 19:16 |
| usrdev | why would it be stalling? | 19:16 |
| Odd_Bloke | usrdev: Can you pastebin `systemd-analyze critical-chain`? | 19:19 |
| usrdev | https://www.irccloud.com/pastebin/2xAYWYid/ | 19:20 |
| Odd_Bloke | Hmm, I guess I was hoping something would jump out at me from that. :p | 19:25 |
| Odd_Bloke | usrdev: Could you file a bug using the link in the topic and attach the tarball produced by `cloud-init collect-logs` to it? | 19:25 |
| usrdev | Odd_Bloke: prior to doing so, let me ask this. i am using proxmox. and i am using the generic-cloud image of debian. that shouldn't be the issue right? | 19:39 |
| Odd_Bloke | I don't have enough Debian cloud knowledge to answer that with confidence, I'm afraid. | 19:46 |
| usrdev | i'll ask in their channel -- thanks for your help with this bit though! ;) | 19:50 |
| Odd_Bloke | :) | 20:00 |
| Odd_Bloke | Happy to help! | 20:00 |
| Odd_Bloke | blackboxsw: https://github.com/canonical/cloud-init/pull/180 is the first of maybe two PRs to fix the doc builds. | 20:00 |
| Odd_Bloke | This moves the configuration from the web interface into the repo. | 20:00 |
| Odd_Bloke | I don't think it will _actually_ fix the missing docs, but I want to be sure that the base configuration is good before I try messing with it. | 20:01 |
| Odd_Bloke | (I also don't know how I would test this anywhere but master, without a bunch of RTD setup hassle.) | 20:01 |
| meena | Odd_Bloke: taking a break from removing six? | 20:13 |
| Odd_Bloke | meena: Yeah, I was just doing that while long running tasks were happening. | 20:14 |
| Odd_Bloke | It's a nice-to-have, but I don't think it will really gain us a huge amount in the short term. | 20:15 |
| Odd_Bloke | requests still uses six, so we'll still be importing it at some point and it'll still be in the dependency tree. | 20:16 |
| Odd_Bloke | But it does mean as other projects also drop support for Py2 and remove six, we'll eventually be rid of it. | 20:16 |
| Odd_Bloke | blackboxsw: I haven't done Softlayer SRU verification before, I don't think. How do I get credentials set up for launch-softlayer to work? And what account do you use for your testing? | 20:53 |
| blackboxsw | Odd_Bloke: I think I had to run 'slcli config setup' | 20:59 |
| blackboxsw | Odd_Bloke: ultimately I have a ~/.softlayer config file with | 21:00 |
| blackboxsw | an api_key and SL163.... | 21:00 |
| blackboxsw | an api_key and username = SL163.... | 21:00 |
| blackboxsw | which is my personal canonical funded account | 21:01 |
| Odd_Bloke | Cool, thanks! | 21:03 |
| Odd_Bloke | blackboxsw: https://github.com/canonical/cloud-init/pull/180 is blocking me fixing the docs, FYI, so it would be good to get eyes on it today. :) | 21:28 |
| blackboxsw | merged Odd_Bloke | 21:45 |
| blackboxsw | I'm going through yet another iteration on minimal ipv6 azure | 21:45 |
| Odd_Bloke | TFTM! | 21:45 |
| Odd_Bloke | OK, well, that's completely broken doc builds. | 21:48 |
| Odd_Bloke | Good times. | 21:48 |
| Odd_Bloke | Oh, no, that's a temporary unrelated issue: https://stackoverflow.com/questions/59846065/read-the-docs-build-fails-with-cannot-import-name-packagefinder-from-pip-in | 21:50 |
| Odd_Bloke | Thank goodness. | 21:50 |
| blackboxsw | Odd_Bloke: approved gce sru test, https://github.com/cloud-init/ubuntu-sru/pull/81 minor additional PR put up for tooling | 21:53 |
| Odd_Bloke | blackboxsw: And https://github.com/canonical/cloud-init/pull/181 is the actual doc fix, I think. | 22:07 |
| Odd_Bloke | blackboxsw: Yep, I think I merged that tooling PR earlier. :) | 22:07 |
| blackboxsw | Thanks Odd_Bloke for the fix. confirmed docs are working now | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!