| minimal | Hi folks. A merge vs rebase question - I have a PR that's out of date with Master, should I use the "Update branch" button in Github? - it will do a merge into the branch. Or should I manually do a rebase? | 11:59 |
|---|---|---|
| meena | i always just rebase | 12:19 |
| meena | i don't know enough what magic Update Branch does, and i feel a rebase that i control is cleaner | 12:20 |
| meena | plus, smoser has asked me a few times now to squash my own 302934 million commits and add the extra fluff that github has added there (like, Co-Authored-By: ) | 12:23 |
| meena | minimal: so, your choice, you can try and see if the button is satisfactory to you | 12:24 |
| smoser | meena: i dont think it really matters. since the project has decided "rebase and squash", it seems that it has made a decision to choose rebase over merge as a development decision (they do both have + and -). | 13:43 |
| smoser | i constantly am doing 'git fetch upstream && git rebase -i upstream/master && git push smoser HEAD' | 13:43 |
| smoser | but i think the button is fine. all it really does (i think) is just 'git merge && git commit' | 13:43 |
| tirex | Hello, I'm in the process of reading a cloud-init documentation and I'm wonder if it's possible to do network configuration of ipv6 with `post-up ip route add local ipv6/ipv6_prefix dev lo`. | 14:07 |
| tirex | you help me? | 14:07 |
| Odd_Bloke | Yeah, as we squash-merge all the commits, it doesn't matter whether you rebase or "Update branch"; the merge commit will be squashed away anyway. | 14:27 |
| minimal | meena:, smoser:, Odd_Bloke: ok, was just cautious of a merge in case it affected/messed up commit history. | 15:06 |
| Odd_Bloke | Yep, very reasonable; I would like to get to a point where we aren't squash-merging everything, but that's unlikely to get any of my time in the foreseeable future, unfortunately. | 15:08 |
| minimal | tirex: in the network-config YAML you can add static routes | 15:08 |
| minimal | @Odd_Bloke, for PR #626 everything done but it appears to be blocked on your last review - I closed off each of your individual comments but GitHub seems to think there's 1 change your requested still open. | 15:46 |
| minimal | s/@Odd_Bloke/Odd_Bloke:/ | 15:47 |
| tirex | minimal, but how? any examples with that? | 15:52 |
| Odd_Bloke | minimal: Cool, thanks! Re-reviewing that is second on my list today, I should get to it. :) | 15:52 |
| minimal | tirex: are you using v1 or v2 network config? | 15:55 |
| tirex | v2 | 15:57 |
| minimal | ok, as an example: | 16:03 |
| minimal | version: 2 | 16:04 |
| minimal | ethernets: | 16:04 |
| minimal | eth0: | 16:04 |
| minimal | routes: | 16:04 |
| minimal | - to: abcd:de12:3456::/64 | 16:04 |
| minimal | via: ::1 | 16:04 |
| minimal | Never tried it for lo interface but think that should work | 16:04 |
| minimal | might need to quote the ::1 bit, i.e. '::1' | 16:05 |
| tirex | minimal: this configuration will generate me a interface like this: | 16:29 |
| tirex | ```iface ens3 inet6 static | 16:30 |
| tirex | `iface ens3 inet6 static | 16:30 |
| tirex | address abcd:4f8:1c17:6da6::1/64 | 16:30 |
| tirex | gateway fe80::1 | 16:30 |
| tirex | post-up route add -A inet6 ::1/64 gw abcd:4f8:1c17:6da6::/64 || true | 16:30 |
| tirex | pre-down route del -A inet6 ::1/64 gw abcd:4f8:1c17:6da6::/64 || true` | 16:30 |
| tirex | but I need `post-up route ip add`, "ip" is important | 16:30 |
| minimal | tirex: did you swap the "to:" and "via:" values? | 16:31 |
| minimal | "via" == "gw" (the gateway), whereas your /e/n/i file has them swapped around | 16:32 |
| tirex | yes | 16:32 |
| minimal | is this Debian or Alpine? | 16:38 |
| tirex | debian 10 | 16:39 |
| minimal | is there a problem with the route command not working? | 16:39 |
| minimal | tirex: is there something that you want "ip route" for that the usual "route" command cannot do? | 16:53 |
| tirex | minimal: I want to apply `ip route add local ipv6/ipv6_prefix dev lo` but I don't know how to replace this with `route` | 17:04 |
| minimal | I don't understand, the generated /e/n/i above basically looks ok (once you correct the "to:" and "via:" in the network YAML) | 17:06 |
| tirex | I tried different combination with `route` and neither worked like the ʻip route` shown above | 17:12 |
| tirex | even when I type command from command line instead of cloud-init | 17:13 |
| minimal | does this work manually? "route add -A inet6 abcd:4f8:1c17:6da6::/64 gw ::1" | 17:16 |
| Odd_Bloke | smoser: rharper: Your thoughts on https://github.com/canonical/cloud-init/pull/659 would be much appreciated, as it's a new upgrade framework/approach. (It's a clean resubmission of https://github.com/canonical/cloud-init/pull/609, for context.) | 17:21 |
| Odd_Bloke | minimal: #626 landed, thank you! | 17:25 |
| minimal | @Odd_Bloke, thanks! | 17:31 |
| minimal | General question about the /etc/hosts templates in cloud-init - they all have FQDN forms of localhost/localhost4/localhost6 before the short form. This has the side effect that any time you run a "netstat" or "ss" you'll see the long-form name of the loopback IPs. Wondering whether to submit a PR to swap this around | 17:33 |
| minimal | same question applies for the short-form and long-form hostname entries as well | 17:35 |
| === MAbeeTT_ is now known as MAbeeTT | ||
| tirex | minimal: sadly, this isn't work manually: `SIOCADDRT: Invalid argument` | 17:53 |
| minimal | timex: yeah, was testing it here - seems to be an issue that the "route add" command is doing a dns lookup on the "::1/128" value. Looking at the Debian route source code currently | 17:55 |
| minimal | "ip" is a more modern tool that does the same as the older ifconfig/route/etc but currently the cloud-init eni.py uses only "route" and not "ip route". | 17:56 |
| minimal | timex: if you are just trying to blackhole some traffic then you could run the "ip route" command via either bootcmd or runcmd in your user-data instead | 18:10 |
| smoser | Odd_Bloke: i think 659 is probalby more than i have time to think about right now. sorry. | 18:31 |
| meena | i feel like the best way to fix resizefs, would be to fix growfs.c to exit with something other than 1 all the time. | 18:40 |
| meena | how do y'all feel about exceptions based flow-control…? | 19:23 |
| Odd_Bloke | smoser: Ack, no worries; just wanted to make sure you had the opportunity. :) | 19:47 |
| plujon | I have a digitalocean droplet running Ubuntu 20.04 LTS (just upgraded) that takes 2 minutes to set up the network after boot. I think something is amiss in its cloud-init. 'cloud-id' reports 'none' instead of 'digitalocean'. | 20:05 |
| Odd_Bloke | plujon: Can you pastebin /var/log/cloud-init.log somewhere for us? | 20:06 |
| plujon | Odd_Bloke: That file is 10+ MB. Shall I paste only since the most recent boot? | 20:07 |
| plujon | https://cloudinit.readthedocs.io/en/latest/topics/faq.html#faq has some useful looking commands... | 20:08 |
| plujon | Oh dear; I just blew away the old server ssh identity. Ugh. | 20:12 |
| plujon | https://cloudinit.readthedocs.io/en/latest/topics/faq.html#how-can-i-re-run-datasource-detection-and-cloud-init # ran these commands, :-( | 20:13 |
| Odd_Bloke | Ah, yeah, you don't want to do that on anything but an ephemeral system. | 20:14 |
| plujon | Odd_Bloke: http://ix.io/2DAM grep 2020-11-09 /var/log/cloud-init.log | 20:18 |
| plujon | Oh, wait, that file was also recreated. | 20:19 |
| Odd_Bloke | plujon: Hmm, less helpful than I was hoping; could you paste /var/log/cloud-init-output.log? | 20:20 |
| Odd_Bloke | plujon: Yeah `clean --logs` wipes away cloud-init's cached state and its logs. | 20:20 |
| plujon | http://ix.io/2DAO # /var/log/cloud-init-output.log | 20:21 |
| plujon | Looks like an interesting error in there: "Getting data from <class 'cloudinit.sources.DataSourceDigitalOcean.DataSourceDigitalOcean'> failed" | 20:21 |
| meena | how do i tell side_effect that… no Exception is raised? | 20:27 |
| plujon | Ah, ssh keys restored. | 20:31 |
| plujon | Odd_Bloke: Would logs be more useful if I were to reboot..? I suspect not... | 20:34 |
| Odd_Bloke | meena: In what context? | 20:40 |
| plujon | /etc/cloud/cloud.cfg.d/93-digitalocean-cloud-config.cfg was last modified in 2016 . Hmm. | 20:40 |
| Odd_Bloke | plujon: Yeah, I suspect you're running into problems because of something to do with that: cc_ubuntu_init_switch hasn't been shipped by cloud-init since 2017, for example. | 20:42 |
| Odd_Bloke | plujon: (As an aside: https://github.com/canonical/cloud-init/pull/661 :) | 20:42 |
| plujon | Are files in /etc/cloud/cloud.cfg.d supposed to be updated by digitalocean, or me, or something else? | 20:42 |
| Odd_Bloke | plujon: Those files are used to configure cloud-init's behaviour: the cloud-init package ships defaults, but those defaults can be overriden or modified by other files in there. | 20:44 |
| Odd_Bloke | In this case, DO must have some specific configuration in there, for whatever reason. | 20:44 |
| plujon | Odd_Bloke: Thanks; maybe I'll try copying a digitalocean cfg from another machine. It seems like DO writes the files at image creation time (and never again?). | 20:45 |
| Odd_Bloke | plujon: I'd suggest going to DO and asking them for assistance: I'm sure you won't be the first DO user to hit this, so hopefully they have specific, known-good advice for remediation. | 20:45 |
| plujon | Odd_Bloke: Thanks; I'll try DO... | 20:50 |
| Odd_Bloke | plujon: Cool, thanks! Let us know how you get on. :) | 20:52 |
| plujon | Will do, thanks. | 20:56 |
| plujon | FTR, is cloud-init kind of like chef or puppet? | 20:56 |
| meena | plujon: neither. | 21:03 |
| Odd_Bloke | plujon: It has some overlap in what it can do to individual systems, but it's ultimately very different: it's baked into (most) cloud images, and takes care of discovering and processing the cloud's metadata. | 21:03 |
| Odd_Bloke | You can specify to the cloud (via user-data) that cloud-init should perform some actions to the system when it's launched (https://cloudinit.readthedocs.io/en/latest/topics/modules.html is a list of the modules which you can specify config for), but it's substantially more limited (intentionally!) than config management systems. | 21:05 |
| meena | i have https://github.com/canonical/cloud-init/pull/655 now ready for actual review. | 21:07 |
| meena | Goneri: give it another test, if you have time / resources | 21:07 |
| meena | falcojr: ^^^^^ | 21:14 |
| meena | with #655 merged, i'll have all current(ly known) FreeBSD bugs and feature requests fixed, and can get back to refactoring | 21:16 |
| meena | and, this excursion was quite educational in terms of testing, so i hope to have #588 in shape soon! | 21:17 |
| meena | but, now, i sleep. | 21:17 |
| meena | (or read about sheep, https://uncpress.org/book/9781469634661/the-herds-shot-round-the-world/ ) | 21:18 |
| meena | falcojr: i will propose a patch to growfs, to use https://man.freebsd.org/sysexits but not tonight | 22:26 |
| meena | and even if i do, it'll be a while before that hits a -RELEASE | 22:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!