| 27 Jan 2023 |
 andrey | once I have that, I would hack that into the Docker's registry... and that can run as a single container anywhere | 13:16:28 |
 Sander Maijers | Harbor provides a lot of functionality that would seem important to the Talos Linux user base, e.g. signed images, access control, etc. Hacking anything that will not suffice by itself but just for bootstrapping, may be less interesting than a complete solution that solves both bootstrapping and the artifact registry requirement. | 13:36:22 |
| Sander Maijers | There's no place to store the images ... I don't fully get that. Can't they be baked into the root filesystem (i.e., the VM image) for a given release? | 13:37:29 |
| Sander Maijers | Would it be doable for Talos Linux to not just support image references but full URL's with various schemes, similar to Skopeo? https://github.com/containers/skopeo/blob/main/README.md | 13:38:13 |
| andrey | Harbor actually does nothing interesting from my point of view, it's bloated and useless compared to the troubles installing it | 13:40:14 |
| andrey | but that's my 2 cents | 13:40:20 |
| andrey | in the end Talos fetches only two images on its own, every other images is fetched by CRI/containerd, so we are limited to what it supports | 13:40:44 |
| Sander Maijers | Well the bloated part, I get. My idea has always been that the concept of container image registries is overblown. It's not essential and a fragile, critical component in practice now. I see that Harbor is even more complex, but on the other hand it does things for organizations that they want. | 13:41:46 |
| andrey | these policies should be in-cluster, not in the registry. otherwise all security depends on a single component which can be easily hacked | 13:42:39 |
| Sander Maijers | It is possible to disable image fetching in the first place, rather than proxying etc.? That's truly airgapped. | 13:42:42 |
| andrey | registry is just a storage | 13:42:47 |
| andrey | I don't see how you can disable image fetching in the first place. the only way is to pre-populate the image store with necessary images, so before fetching it will use existing cache | 13:43:36 |
| andrey | but still Kubernetes might be configured to fetch always | 13:43:45 |
| Sander Maijers | Yes, that is what I mean. But also a control that makes containerd offline. | 13:44:00 |
| andrey | that's not how I see it... | 13:44:44 |
| andrey | but certainly there are different scenarios | 13:45:00 |
| Sander Maijers | Maybe you have long seen this, but is this relevant in thinking about design of such a feature? https://github.com/containerd/containerd/blob/main/docs/transfer.md | 13:50:13 |
| andrey | this is containerd 1.7+, but still containerd provides CRI plugin, and kubelet interacts with CRI plugin | 13:50:51 |
| andrey | so in the end interface is defined by CRI | 13:51:01 |
|  Victor Prechtel joined the room. | 18:35:27 |
| Victor Prechtel changed their display name from _slack_taloscommunity_U04LZJPF16Y to Victor Prechtel. | 18:35:28 |
 Matti Suuronen | Anyone using mac mini (2014) in Sidero/Talos? I have not been able to PXE boot mine yet :/ | 19:53:49 |
 Andrew Rynhard | I haven’t heard of anyone doing this. | 20:20:23 |
 Michael Francis | You probably need to use an alternative bootloader to make it work | 20:22:45 |
| Michael Francis | I guess opencore, or the other one I can’t remember (clover?) | 20:22:59 |
 Matti Suuronen | I’m using refind already, and have a built a few versions of ipxe.efi. I can boot those, no problem, but ipxe drivers just fail to initialize the hw. But I will check out opencore/clover, thnx for the tip! | 21:11:55 |
| Michael Francis | Refind should work too I believe but haven't tried | 21:12:32 |
| Michael Francis | Although it might be some drivers you need aren't in the talos kernel who knows have you tried booting the iso normally? | 21:13:07 |
| Matti Suuronen | Talos iso boots ok. And I can boot linux etc through refind ok, so this would seem to be a prob with ipxe.org drivers | 21:15:30 |
| Michael Francis | I assume you e seen this https://forum.ipxe.org/showthread.php?tid=7323 | 23:29:11 |
