[13:45] <punkgeek> How can I detect network configuration version in cloud init automatically? because I want to write a general script for Linux distros.
[13:51] <Odd_Bloke> punkgeek: What do you mean by "network configuration version"?  Could you perhaps describe your problem/requirement in a little more detail?
[13:56] <smoser> blackboxsw: i'm not really sure why there was a difference.  I think powersj might have some insight.  Or such knowledge may well be lost in the recesses of past brains.
[13:57] <smoser> but i think that at one point a jenkins had access to one but not the other or something.
[14:01] <punkgeek> Odd_Bloke: There are 2 kinds of network type which you can see in here:  https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v1.html    and  https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html
[14:02] <punkgeek> Some distoros such as ubuntu 16 use the first version but in ubuntu 18 use the second one (netplan)
[14:06] <punkgeek> I want to make a script that can detect the OS network type and config it automatically. For example if the Distro support netplan, Use the second network type
[14:09] <Odd_Bloke> punkgeek: Have you seen the `cloud-init devel net-convert` command?
[14:12] <punkgeek> Odd_Bloke: This python file? https://github.com/delphix/cloud-init/blob/master/cloudinit/cmd/devel/net_convert.py
[14:12] <punkgeek> I couldn't understand this python script
[14:13] <Odd_Bloke> punkgeek: I guess I'm still not sure I understand where this "script" will run, so I'm guessing at what you're trying to do a little.
[14:13] <smoser> punkgeek: "Some distoros such as ubuntu 16 use the first version but in ubuntu 18 use the second one (netplan)"
[14:13] <smoser> the point of cloud-init is that it can render either network config version into the correct system configuration format.
[14:14] <smoser> `cloud-init devel net-convert` will read either version 1 or version 2 network config
[14:14] <smoser> and write sysconfig (rhel, suse), ENI (old ubuntu), netplan (new ubuntu)
[14:15] <smoser> cloud-init *is* the general script
[14:16] <punkgeek> Aha, So how can I use cloud-init devel net-convert in the iso file?
[14:23] <punkgeek> I should use it by runcmd command?
[14:29] <punkgeek> Here is a shell script that I used to config static ip in different distros: https://github.com/autovmnet/tools/blob/master/vm_config.sh   But I want to do it by cloud-init iso
[14:30] <Odd_Bloke> punkgeek: When you say "cloud-init ISO", what do you mean?
[14:32] <punkgeek> Sorry i'm amature in cloud-init. Here is my cloud-init script example that i've convert it to iso file by using cloud-localds and then mount it on the vm   https://github.com/autovmnet/tools/blob/master/cloud-init.cfg
[14:35] <Odd_Bloke> punkgeek: OK, great; so if you run `cloud-localds`, you should see that it has a `--network-config` option.  If you use that to specify network configuration (in either v1 or v2 formats), then cloud-init will take care of rendering it appropriately for your target distro version.
[14:36] <Odd_Bloke> (And no worries, there's a lot of similarly named things, so I'm just making sure we're on the same page so I'm not giving you bad advice!)
[14:47] <punkgeek> Thank you, As I understand, in the cloud-localds option, I should create two config file, cloud-init.cfg and network.cfg then convert it to iso file like this:   cloud-localds --network-config=network.cfg new.iso cloud-init.cfg
[14:47] <punkgeek> Am I right?
[15:00] <Odd_Bloke> punkgeek: Yep, I believe that will do it.
[15:02] <punkgeek> How can I do it in a single file?
[15:04] <punkgeek> Odd_Bloke: And is there any way to enter both version configuration and then, system detect version automatically and use the currect one?
[15:18] <smoser> punkgeek: it doesn't matter which you pick
[15:18] <smoser> cloud-init will render either version to the correct result when configuring networking.
[15:18] <smoser> you declare it however you want.
[15:23] <punkgeek> smoser: Thank you, so is it correct to do sth like this?:  create a config.cfg which contain: https://paste.ubuntu.com/p/rXhfRXfWPz/   and then run cloud-localds --network-config=cloud.cfg new.iso
[15:23] <smoser> no
[15:25] <punkgeek> how should it be? Could you please give me an example to do it?
[15:26] <punkgeek> Should it seprate the network part and user part? or require anything else?
[15:26] <smoser> https://asciinema.org/a/145772
[15:33] <punkgeek> moser: what about this one? moser>
[15:33] <punkgeek> https://paste.ubuntu.com/p/NTRXsk3Rx6/
[15:35] <smoser> no.
[15:35] <smoser> thats not valid yaml
[15:35] <smoser> well.. it miht be valid yaml, but its not sensical.
[15:35] <smoser> you have 2 top level network kesy.
[15:35] <smoser> only put one of the two versions in .
[15:36] <smoser> i recommend following the demo and changing one thing at a time.
[15:36] <smoser> all the files for the demo are at https://gist.github.com/smoser/635897f845f7cb56c0a7ac3018a4f476
[15:38] <punkgeek> The point  what  I want to enter both network-config is that because my platform cannot detect the vm distors.
[15:40] <Odd_Bloke> punkgeek: cloud-init can detect the VM distro (because it runs within the VM), and it will convert your input to the appropriate format for that distro.
[15:41] <Odd_Bloke> So if it's running on xenial, it will convert v2->ENI, on bionic and later v2->netplan, etc.
[15:41] <punkgeek> Odd_Bloke: So is it ok to enter both version like this? https://paste.ubuntu.com/p/NTRXsk3Rx6/
[15:42] <Odd_Bloke> punkgeek: No.
[15:42] <Odd_Bloke> You specify your configuration once, and cloud-init converts that configuration to the appropriate format.
[15:43] <punkgeek> Odd_Bloke: sorry I couldn't understand, could you give me an example?
[15:43] <Odd_Bloke> (In this case, the second `network` key definition overrides the first, so you are actually only defining a v2 config.)
[15:44] <Odd_Bloke> punkgeek: https://paste.ubuntu.com/p/VSrFPTzFdz/ <-- that's all you need to specify, cloud-init will take care of converting it to the required format within the VM
[15:45] <punkgeek> Aha so if i enter this one and the distro does not support netplan such as ubuntu16.04, It will convert to the version one?
[15:46] <dking> I would like some help troubleshooting my network configuration. I see that my network-scripts were set as expected, but they don't seem to be applied. It seems like it fell back to DHCP for some reason. I'm looking through cloud-init.log now, but I'm not sure what I'm looking for yet.
[15:49] <dking> I see this in the logs: "No network config applied. Neither a new instance nor datasource network update on 'System boot' event"
[15:50] <Odd_Bloke> punkgeek: Correct!  (In fact it will convert it to ENI, which is the /etc/network/interfaces format used on xenial; v1 is only used internal to cloud-init.  But your broader understanding is correct.)
[15:56] <dking> I got the same when I ran "cloud-init clean -r". I'm new to debugging cloud-init issues, so any help would be appreciated.
[15:59] <smoser> dking: well, you can open a bug. but i'd first explain what you're tryhing to do and paste an entire cloud-init.log .
[15:59] <punkgeek> Odd_Bloke: Sorry but I've got this error:   https://paste.ubuntu.com/p/B8B6MTvrKP/
[16:00] <smoser> cloud-init collect-logs will collect a lot of information that people would probably ask you
[16:00] <smoser> punkgeek: drop the top level 'network'
[16:01] <smoser> i think newer versions of cloud-init will figure that out, but the bug you're seeing
[16:02] <smoser> the bug you're seeing is that cloud-init looks for a top level 'version' key in its network config, and you have no such key. (because you have a second level network key)
[16:02] <smoser> https://gist.github.com/smoser/635897f845f7cb56c0a7ac3018a4f476
[16:02] <smoser> those files are valid... if you start there you might have more success.
[16:02] <punkgeek> smoser: like that? https://paste.ubuntu.com/p/8VTMTqJhXR/
[16:03] <punkgeek> Aha sorry
[16:04] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1798117 intended to support your input
[16:04] <ubot5> Ubuntu bug 1798117 in juju "juju sends "network" top level key to user.network-config in lxd containers" [High,Fix released]
[16:04] <smoser> so i'd supsect that the guest that is there does not have that fix.
[16:12] <dking> smoser: I'm not convinced that it's a bug yet. I'm trying to just get an idea of why things didn't happen as I expected. Here's the cloud-init.log: http://sprunge.us/oqGOws  And here is some context: http://paste.openstack.org/show/794705/
[16:14] <dking> ...and I forgot to put it in there, but in case it helps, I'm using cloud-init version 18.5
[16:16] <meena> what is delphix and how do i run it myself?
[16:18] <smoser> dking: good job collecting info
[16:19] <smoser> you ahve 2 cloud-init runs in the log there
[16:19] <smoser> maybe try a 'cloud-init --logs clean'
[16:19] <smoser> just to reduce it to one boot
[16:20] <smoser> but i suspect that what is wrong is that the /etc/sycconfig is 'diry" in some way
[16:20] <smoser> not certain. but it surely looks good.
[16:20] <dking> Okay. I'll give that a try. That's probably from where I ran "cloud-init clean -r"
[16:20] <smoser> where did you get the image ?
[16:20] <dking> Okay, that may be. I had an issue when it first booted caused by the BIOS.
[16:20] <dking> It's generated by bifrost. This is part of a Kayobe deploy.
[16:22] <smoser> if we think that cloud-init rendered the correct sysyconfig network information
[16:22] <smoser> then there are a few things that might be wrong
[16:22] <dking> Okay, I ran that (actually "cloud-init clean --logs" as the other way gave an error), and now the logs are empty.
[16:23] <punkgeek> smoser: Sorry I have this error now; https://paste.ubuntu.com/p/KNhDJHPRQb/
[16:23] <smoser> a.) cloud-init rendered this network information *after* the system brought up networking (we try to ensure that 'cloud-init init-local' runs before system network bring up . but something might be broken there.
[16:23] <smoser> b.) udev rules might not be written correctly (they handle the device renaming... not exactly sure about that for sysconfig though)
[16:24] <smoser> c.) other confusing sysconfig data conflicting iwth cloud-init
[16:25] <smoser> punkgeek: you gave it invalid yaml
[16:25] <smoser> it can't load it.
[16:25] <smoser> you can test yaml loading using yaml-dump https://gist.github.com/smoser/280dbed3e9582c53c6035525f35814aa
[16:26] <smoser> sorry, though. i really ahve to get to actual work now.
[16:26] <dking> Yes, they appear to be correct to me, though I could have missed something. Is there any way to tell from the logs where things go wrong? The logs are cleaned now. What is the best way to cleanly run it again? Just reboot the machine, or something like "cloud-init init" ?
[16:31] <powersj> dking, sudo cloud-init --local; sudo cloud-init init; or a reboot as you suggested. https://cloudinit.readthedocs.io/en/latest/topics/faq.html#how-can-i-re-run-datasource-detection-and-cloud-init
[16:35] <dking> powersj: Thank you very much
[16:40] <dking> smoser: Here's the new log: http://sprunge.us/q5KrHr and here is further context, including the error I got when attempting to bring up the interface: http://paste.openstack.org/show/794706/
[16:43] <smoser> dking: init doesnt render networking
[16:43] <smoser> init --local
[16:44] <dking> OKay. I'll try that.
[16:45] <dking> smoser: Here's the new cloud-init.log: http://sprunge.us/Scz96q
[16:45] <smoser> do you maybe need some vlan spuport package in the image ?
[16:46] <smoser> i think that maas testing actually uses vlan and centos . so i think this is a supported path
[16:49] <punkgeek> I use this script but still does not works:( https://paste.ubuntu.com/p/xh25XGpYR7/
[16:52] <dking> I'm not sure. I've been using the same system to deploy servers for a while, but I did make some changes to configurations before this run, and it's happened on two different machines.
[16:56] <blackboxsw> falcojr: and Odd_Bloke https://github.com/canonical/cloud-init/pull/431  daily recipe fix for bionic
[16:57] <dking> If the image isn't built correctly, or if there's some problem outside of cloud-init, I'll just need to know enough to locate the bug in the other software. And I have been using VLANs before. I think, though, that we had to use a certain version of cloud-init as the older ones couldn't support them. I think it was around 18.2?
[17:03] <blackboxsw> falcojr: Odd_Bloke and https://github.com/canonical/cloud-init/pull/433 for xenial
[17:05] <dking> Is there any way to confirm from the cloud-init.log whether the issue I'm seeing in bringing up eht0.81 manually is actually the reason why the network isn't setup by cloud-init?
[17:16] <smoser> punkgeek: you'd have to post a cluod-init log at this point.
[17:17] <smoser> dking: there should be some system logs for sysconfig somewhere
[17:17] <smoser> but i'm not familiar enough to know
[17:19] <dking> smoser: I'll continue trying to resolve that. But what I meant was, is there some place in the cloud-init logs where it would show whether it even attempted to bring up that interface, or if it received an error?
[17:20] <blackboxsw> dking: I see in your log that "2020-06-12 16:44:41,585 - DataSourceConfigDrive.py[DEBUG]: network config provided via network_json"
[17:20] <blackboxsw> dking: and you can see cloud-init tries to render this network config in your logs
[17:21] <blackboxsw> 2020-06-12 16:44:41,598 - stages.py[INFO]: Applying network configuration from ds bringup=False: {'version': 1, 'config': [{'type': 'vlan', 'subnets': [{'dns_nameservers': ['8.8.8.8', '8.8.4.4'], 'netmask': '255.255.255.0', 'routes': [{'gateway': '10.8.1.3', 'netmask': '0.0.0.0', 'network': '0.0.0.0'}], 'type': 'static', 'address': '10.8.1.11', 'ipv4': True}], 'name': 'eth0.81', 'vlan_id': '81', 'mac_address':
[17:21] <blackboxsw> 'ac:1f:6b:d0:4d:94', 'vlan_link': 'eth0'}, {'mtu': '1500', 'type': 'physical', 'subnets': [], 'mac_address': 'ac:1f:6b:d0:4d:94', 'name': 'eth0'}, {'address': '8.8.8.8', 'type': 'nameserver'}, {'address': '8.8.4.4', 'type': 'nameserver'}]}
[17:21] <blackboxsw> 2020-06-12 16:44:41,598 - __init__.py[DEBUG]: Selected renderer 'sysconfig' from priority list: None
[17:21] <blackboxsw> saying that it is using the proper sysconfig renderer for the network config it writes. (which aligns with you saying the valid config appears to be in /etc/sysconfig)
[17:22] <blackboxsw> might want to check timestamps of 2020-06-12 16:44:41,598 versus you system logs that say when networking is brought up
[17:22] <blackboxsw> to see if that happening in cloud-init 'after' your network was already up (so the updated config wasn't read by your system)
[17:25] <blackboxsw> you might be able to look through output of `journalctl --utc -o short-precise -u systemd-networkd`   on your system maybe ?
[17:27]  * blackboxsw was just grasping at straws though.
[17:31] <punkgeek> smose: Here is the log  https://paste.ubuntu.com/p/mZM3XbVKcx/
[17:46] <Odd_Bloke> blackboxsw: Shouldn't those PRs be for the daily branch, as discussed?
[17:48] <blackboxsw> Odd_Bloke: ohh whoops, force of habit. I was thinking we'd do new-upstream-snapshot to refresh patches and then run fix-daily-branch script to do that. I forgot we can just fix daily only
[17:48] <blackboxsw> right right will fix them
[17:48] <Odd_Bloke> Nice, thanks!
[17:48] <blackboxsw> hrm. thinking it through though.
[17:49] <blackboxsw> so if we only fix ubuntu/daily/xenial we'll lose that next time we run cloud-init's "cherry-pick" as 'fix-daily-branch' does a git reset --hard origin/ubuntu/$release
[17:51] <blackboxsw> so somehow we might need to keep a log of quilt refreshes applied in ubuntu/daily/$release to 'fix' non-cpick quilt patches.
[17:51] <Odd_Bloke> I think fix-daily-branch should abort if it finds state other than what it expects.
[17:51] <blackboxsw> so we can re-apply them during the next "fix-daily-branch"
[17:52] <blackboxsw> yeah I think so, I can fold that into a PR I'm working on fix-daily-branch anyway as I ran into an issue with ubuntu/$releases which have no debian/patches/cpick*
[17:52] <blackboxsw> so an abort and we can sort on next cherry-pick
[17:52] <Odd_Bloke> I would suggest it'll be easier to review if you separate them out instead of folding it in.
[17:53] <Odd_Bloke> But other than that, sounds good!
[17:53] <blackboxsw> ok will do.
[17:53] <Odd_Bloke> Also worth noting that the current reset --hard behaviour will just break daily builds again in a way that we already know how to solve, so it's not necessarily the worst situation.
[17:58] <dking> blackboxsw: Thank you very much for the info. I am starting to wonder now if the problem might be NetworkManager. In the past, I think I've had trouble with it using VLANs.
[17:58] <smoser> dking: cloud-init doesn't attempt to bring up networking information
[17:58] <smoser> it just renders it and lets the OS bring it up
[17:58] <smoser> the goal is that your OS just thinks that was "statically configured" networking that was already there.
[17:59] <blackboxsw> Odd_Bloke: falcojr https://github.com/canonical/uss-tableflip/pull/54
[17:59] <blackboxsw> handle the no debian/patches/*cpick* case on existing ubuntu/xenial or ubuntu/bionic branches (since we had just performed a new-upstream-snapshot which dropped those cpicks)
[17:59] <dking> Yep. So, I suppose that if it got the scripts into the right place, then maybe the issue is with something else in the OS.
[18:00] <smoser> punkgeek: you'd need to give /var/log/cloud-init.log . not ust the console log.  but i suspect that the issue is that the nic name is not what you expected. ens192
[18:01] <punkgeek> smoser: can I use it like ens* ?
[18:25] <smoser> punkgeek: probably not reliably. you may be able to for systems that use netplan natively.
[18:25] <smoser> but really what you need to do is specify the mac addresses
[18:29] <smoser> mac addresses are something you can know from "outside".  they're properties of virtual hardware.  the names that a given OS chooses to give to that virtual hardware are not reliable
[18:30] <blackboxsw> Odd_Bloke: let's try that again https://github.com/canonical/cloud-init/pull/435 to fix ubuntu/daily/xenial builds
[18:31] <blackboxsw> and actually looks like I'll have to rework another patch :/ n/m Odd_Bloke    moving which into the subp module also broke another quilt patch
[18:31] <blackboxsw> as unit tests now fail
[18:31] <blackboxsw> after patches are applied
[18:31]  * blackboxsw moves it to wip
[18:34] <Odd_Bloke> blackboxsw: Ack, ping when you want eyes on it again.
[18:37] <dking> smoser and blackboxsw: Thanks for the help. It helped me to narrow things down. The problem does seem to be from using NetworkManager. If I switch to network-scripts, I can start the VLAN. Now, I just have to find a way to get DIB to build using network-scripts instead of NetworkManager.
=== mpontillo_ is now known as mpontillo
[19:34] <Odd_Bloke> Looks like Rick didn't get to my doc PR before the trails called to him, so if anyone wants to do a quick review: https://github.com/canonical/cloud-init/pull/430
[19:37] <smoser> dking, blackboxsw it probably would be good for cloud-init to document *somewhere* that network manager is not supported at this time.
[19:38] <smoser> and would be better if it noticed somehow that your system was using network manager and said unsupported
[19:38] <blackboxsw> +1 Odd_Bloke
[19:38] <smoser> or alternatively, actually DTRT and rendered network manager.
[19:39] <blackboxsw> smoser: I guess https://cloudinit.readthedocs.io/en/latest/topics/network-config.html#network-configuration-outputs is a bit misleading
[19:40] <blackboxsw> as we specifically call out NetworkManager for netplan backend
[19:41] <portdirect> how can I configure cloud-init to use Netplan when ifupdown is also present on the host?
[19:41] <blackboxsw> portdirect: by default in Ubuntu focal and later netplan is preferred over /etc/network/interfaces even if both ifupdown and netplan are present
[19:42] <strobelight> is there a doc that lists all the recognized keys and describes them?
[19:43] <blackboxsw> portdirect: on earlier releases of cloud-init you can set the renderer priority order to prefer netplan first
[19:44] <portdirect> blackboxsw: im not experiencing this, its prioritizing ifupdown over Netplan for me
[19:45] <portdirect> a simple apt-get purge ifupdown gets Netplan working, but this is not viable for my use case :(
[19:45] <blackboxsw> portdirect: by either:  1. providing the following config in /etc/cloud-config.d/90-override-renderer.cfg in your image: https://paste.ubuntu.com/p/ky7V4RvdXT/
[19:47] <portdirect> blackboxsw: trying that now
[19:47] <blackboxsw> portdirect: or 2 providing cloud-config to override this on VM boot (if you aren't creating your own images)  https://paste.ubuntu.com/p/f68TbMJRdb/
[19:48] <blackboxsw> strobelight: do you mean instance data keys?
[19:48] <blackboxsw> or network renderer keys?
[19:48] <blackboxsw> I'm missing the context of your question
[19:50] <blackboxsw> falcojr: sorry about https://github.com/canonical/cloud-init/pull/431   I should have closed it when Odd_Bloke reminded me we wanted to do this against ubuntu/daily/xenial|bionic only (as that is the whole reason we have those branches now; to avoid patch commit/refresh noise in ubuntu/xenial|bionic proper)(
[19:52] <blackboxsw> falcojr: https://github.com/canonical/cloud-init/pull/435 should have more context, but the short of it is that we expect to be dropped into a quilt patch apply failure cli where we need to run quilt push -f, resolve patch apply conflicts manually, quilt refresh to save those updated patches into debian/patches/*.patch
[19:54] <falcojr> gotcha
=== Odd_Bloke changed the topic of #cloud-init to: pull-requests https://git.io/JeVed | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting June 16 16:15 UTC | 20.1 (Feb 18) | 20.2 (Apr 28) | https://bugs.launchpad.net/cloud-init/+filebug
[20:02] <blackboxsw> falcojr: also added some more context for you on this ubuntu-advantage-tools pain https://github.com/canonical/cloud-init/pull/431
[20:03] <blackboxsw> https://github.com/canonical/cloud-init/pull/431#issuecomment-643460234 actually
[20:03] <Odd_Bloke> rharper: smoser: Your input on https://bugs.launchpad.net/cloud-init/+bug/1883122 would be really appreciated. :)
[20:03] <ubot5> Ubuntu bug 1883122 in cloud-init "`cloud-init status` should distinguish between "permanently disabled" and "disabled for this boot"" [Undecided,New]
[20:05] <blackboxsw> the reason we are in a bit of a pickle on ubuntu-advantage in upstream cloud-init is because the ua-tools project accepted backwards incompatibility of the ua-client CLI  and cloud-init also was allowed to design a new set of config directives without worrying about backwards compatibility of the old shell-based ua-tools CLI versus to new ua-tools python-based CLI. As a result we've carried a bit of a patch
[20:05] <blackboxsw> maintenance pain in ubuntu/xenial and ubuntu/bionic branches
[20:06]  * blackboxsw can't wait to release ubuntu-advantage-tools version 25.0  to xenial and bionic so we can drop the ubuntu-advantage revert stuff
[20:06] <portdirect> blackboxsw: that worked perfectly, thank you - though I put the over-ride in /etc/cloud/cloud.cfg.d/90-override-renderer.cfg
[20:06] <portdirect> cheers
[20:06] <blackboxsw> cool portdirect good to hear
[20:12] <dking> NetworkManager is probably fine for most people. I think it's the VLANs. And it may not even be just that. I'm wondering if there could be another solution, like adding a package.
[20:18] <falcojr> blackboxsw thanks for the extra context
[20:18] <rharper> Odd_Bloke: looking
[20:33] <blackboxsw> https://github.com/canonical/cloud-init/pull/435 and https://github.com/canonical/cloud-init/pull/436 up for daily build recipe fixes
[20:33] <blackboxsw> with happy instuctions :)
[21:40] <strobelight> @blackboxsw user-data and instance meta data. https://cloudinit.readthedocs.io/en/latest/topics/examples.html shows examples, but is that all-inclusive? https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html instance data seems to be vendor-specific, or deployment specific, for example "availability_zone" means nothing when deploying ubuntu on my virtualbox.
[22:12] <blackboxsw> strobelight: yes definitely each platform supports differing values for instance data. so your mileage varies depending on where you are deploying. https://cloudinit.readthedocs.io/en/latest/topics/instancedata.html is the best bet and running `cloud-init query --all` on your platform is the real content you can rely on.
[22:13] <blackboxsw> strobelight: also I put together a couple of sample runs on some platforrms a while back: https://hackmd.io/aAJFerDRRNaoL0Q_vDRYBg  it's a bit dated, but there ya go
[22:36] <strobelight> @blackboxsw thanks, I'll have a look