[11:59] <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?
[12:19] <meena> i always just rebase
[12:20] <meena> i don't know enough what magic Update Branch does, and i feel a rebase that i control is cleaner
[12:23] <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:24] <meena> minimal: so, your choice, you can try and see if the button is satisfactory to you
[13:43] <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'
[14:07] <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:27] <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.
[15:06] <minimal> meena:, smoser:, Odd_Bloke: ok, was just cautious of a merge in case it affected/messed up commit history.
[15:08] <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:46] <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:47] <minimal> s/@Odd_Bloke/Odd_Bloke:/
[15:52] <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:55] <minimal> tirex: are you using v1 or v2 network config?
[15:57] <tirex> v2
[16:03] <minimal> ok, as an example:
[16:04] <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:05] <minimal> might need to quote the ::1 bit, i.e. '::1'
[16:29] <tirex> minimal: this configuration will generate me a interface like this:
[16:30] <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:31] <minimal> tirex: did you swap the "to:" and "via:" values?
[16:32] <minimal> "via" == "gw" (the gateway), whereas your /e/n/i file has them swapped around
[16:32] <tirex> yes
[16:38] <minimal> is this Debian or Alpine?
[16:39] <tirex> debian 10
[16:39] <minimal> is there a problem with the route command not working?
[16:53] <minimal> tirex: is there something that you want "ip route" for that the usual "route" command cannot do?
[17:04] <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:06] <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:12] <tirex> I tried different combination with `route` and neither worked like the ʻip route` shown above
[17:13] <tirex> even when I type command from command line instead of cloud-init
[17:16] <minimal> does this work manually? "route add -A inet6 abcd:4f8:1c17:6da6::/64 gw ::1"
[17:21] <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:25] <Odd_Bloke> minimal: #626 landed, thank you!
[17:31] <minimal> @Odd_Bloke, thanks!
[17:33] <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:35] <minimal> same question applies for the short-form and long-form hostname entries as well
=== MAbeeTT_ is now known as MAbeeTT
[17:53] <tirex> minimal: sadly, this isn't work manually: `SIOCADDRT: Invalid argument`
[17:55] <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:56] <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".
[18:10] <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:31] <smoser> Odd_Bloke: i think 659 is probalby more than i have time to think about right now. sorry.
[18:40] <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.
[19:23] <meena> how do y'all feel about exceptions based flow-control…?
[19:47] <Odd_Bloke> smoser: Ack, no worries; just wanted to make sure you had the opportunity. :)
[20:05] <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:06] <Odd_Bloke> plujon: Can you pastebin /var/log/cloud-init.log somewhere for us?
[20:07] <plujon> Odd_Bloke: That file is 10+ MB.  Shall I paste only since the most recent boot?
[20:08] <plujon> https://cloudinit.readthedocs.io/en/latest/topics/faq.html#faq has some useful looking commands...
[20:12] <plujon> Oh dear; I just blew away the old server ssh identity.  Ugh.
[20:13] <plujon> https://cloudinit.readthedocs.io/en/latest/topics/faq.html#how-can-i-re-run-datasource-detection-and-cloud-init # ran these commands, :-(
[20:14] <Odd_Bloke> Ah, yeah, you don't want to do that on anything but an ephemeral system.
[20:18] <plujon> Odd_Bloke: http://ix.io/2DAM grep 2020-11-09 /var/log/cloud-init.log
[20:19] <plujon> Oh, wait, that file was also recreated.
[20:20] <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:21] <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:27] <meena> how do i tell side_effect that… no Exception is raised?
[20:31] <plujon> Ah, ssh keys restored.
[20:34] <plujon> Odd_Bloke: Would logs be more useful if I were to reboot..?  I suspect not...
[20:40] <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:42] <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:44] <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:45] <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:50] <plujon> Odd_Bloke: Thanks; I'll try DO...
[20:52] <Odd_Bloke> plujon: Cool, thanks!  Let us know how you get on. :)
[20:56] <plujon> Will do, thanks.
[20:56] <plujon> FTR, is cloud-init kind of like chef or puppet?
[21:03] <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:05] <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:07] <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:14] <meena> falcojr: ^^^^^
[21:16] <meena> with #655 merged, i'll have all current(ly known) FreeBSD bugs and feature requests fixed, and can get back to refactoring
[21:17] <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:18] <meena> (or read about sheep, https://uncpress.org/book/9781469634661/the-herds-shot-round-the-world/ )
[22:26] <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