| 10 Aug 2021 |
 David Arnold (blaggacao) | For example you can't meaningfully run tests for bastion.example.com and basyion.local wired together in the same network. | 04:15:39 |
| David Arnold (blaggacao) | * For example you can't meaningfully run tests for `bastion.example.com` and `bastion.local` wired together in the same network. | 04:15:47 |
| David Arnold (blaggacao) | * For example you can't meaningfully run tests for `bastion.example.com` and `bastion.local` wired together in the same network (without implementing that work around). | 04:16:23 |
| David Arnold (blaggacao) | What's worse, python identifier can't have dashes. So the set of legal hostnames is not RFC1035(?) compiant. Just for tests. | 04:17:13 |
| David Arnold (blaggacao) | * What's worse, python identifier can't have dashes. So the set of legal hostnames (= dns label) is not RFC1035(?) compliant. Just for tests. | 04:17:27 |
| David Arnold (blaggacao) | I find that pretty egocentric of the nixos test framework. | 04:17:52 |
| David Arnold (blaggacao) | * So there is an implementation error to say the least upstream in that `fqdn != hostname != node name` | 04:18:19 |
| David Arnold (blaggacao) | I think a pervasive solution would be machines["<fqdn>"] | 04:19:35 |
| David Arnold (blaggacao) | Good that I'm working on a refactor to the testing framework 😄 | 04:20:02 |
| David Arnold (blaggacao) | In reply to @blaggacao:matrix.org
I think a pervasive solution would be machines["<fqdn>"] We could map that to the co fig's fqdn, but at the same time expose node names as direct identifier's, e.g. machine2... | 04:22:33 |
| David Arnold (blaggacao) | * We could map that to the config's fqdn, but at the same time expose `node names` as direct identifier's, e.g. `machine2`... | 04:22:46 |
 @kraftnix:matrix.org | In reply to @blaggacao:matrix.org
What's worse, python identifier can't have dashes. So the set of legal hostnames (= dns label) is not RFC1035(?) compliant. Just for tests. this bit me not long ago and I renamed a few hosts to camelcase for now 😕 | 12:11:48 |
| @kraftnix:matrix.org | In reply to @blaggacao:matrix.org
We could map that to the config's fqdn, but at the same time expose node names as direct identifier's, e.g. machine2... i like this, you can "somewhat" maintain backwards compatibility by keeping node names as toplevel/direct identifiers but provide fqdns under a dict for when the usecase is required (this should also avoid any host that has `-` in the name causing devos profile tests to fail immediately). | 12:18:27 |
 @gtrunsec:matrix.org | Is there a reason to add an option of disabling TestsAllProfiles? Only customProfilesTest for each host. | 19:10:27 |
 @timdeh:matrix.org | If you have a WIP profile that breaks test? Or maybe some of your profiles use private information that cannot be pulled into test environment (just off top of my head) | 19:14:52 |
| @gtrunsec:matrix.org | In reply to @timdeh:matrix.org
If you have a WIP profile that breaks test? Or maybe some of your profiles use private information that cannot be pulled into test environment (just off top of my head) Not all of them, but the annoying point is that I need to keep all the machine’s private information or special arguments consistent. | 19:21:13 |
 princemachiavelli | How would I define a host that is a linux container (boot.isContainer) & then add that container to a profile/suite? It looks like the flk vm is more for adhoc testing of full virtual machines since it uses Qemu instead of LXC which expects it's own kernel. | 22:21:17 |
| @timdeh:matrix.org | princemachiavelli:
{ containers.my-coolcontainer = imports = [ ./path-to-host.nix ]; }
| 23:47:14 |
| @timdeh:matrix.org | * princemachiavelli:
{ containers.my-cool-container = imports = [ ./path-to-host.nix ]; }
| 23:47:25 |
| @timdeh:matrix.org | * princemachiavelli:
{ containers.my-cool-container = { imports = [ ./path-to-host.nix ]; }; }
| 23:47:41 |
| @timdeh:matrix.org | ^^^ this would be in a profile | 23:47:49 |
| @timdeh:matrix.org | or you could just define the container as a profile itself and just put your system config for it after my-cool-container = | 23:48:21 |
| @timdeh:matrix.org | * princemachiavelli:
{ containers.my-cool-container.config = { imports = [ ./path-to-host.nix ]; }; }
| 23:48:51 |
| @timdeh:matrix.org | * or you could just define the container as a profile itself and just put your system config for it after my-cool-container.config = | 23:49:00 |
| 11 Aug 2021 |
| David Arnold (blaggacao) | You can also use this pattern to creat your own 'variant': https://github.com/divnix/digga/blob/main/modules/bootstrap-iso.nix | 14:24:56 |
| David Arnold (blaggacao) | * princemachiavelli: You can also use this pattern to creat your own 'variant': https://github.com/divnix/digga/blob/main/modules/bootstrap-iso.nix | 14:25:08 |
| David Arnold (blaggacao) | or best check if this already fits your needs: https://github.com/nix-community/nixos-generators/blob/master/formats/lxc.nix | 14:26:04 |
| David Arnold (blaggacao) | (all nixos-generators come included: bud build HOST lxc) | 14:26:41 |
| David Arnold (blaggacao) | And if that doesn't work, I think the maintainer will be very happy about any contribution there. | 14:27:46 |
| 12 Aug 2021 |
| @timdeh:matrix.org | Small little though, but does anyone thing that programs.bcc.enable might be good for the core profile? I'm starting to dive into these tracing tools after ignoring them for some years now, and I have to say, they are quite impressive | 17:54:44 |
