kalipso/infrastructure
1
1
Fork 1
Code Issues 42 Pull Requests 2 Actions Projects 2 Releases Wiki Activity

Nextcloud improvements part 1 #81

Merged
kalipso merged 5 commits from nextcloud-issue-1 into master 2025-02-11 17:47:32 +01:00
Conversation 8 Commits 5 Files Changed 5 +32 -1
ahtlon commented 2025-01-28 12:22:08 +01:00
Collaborator
Copy Link

For now this fixes #67 and parts of #69 (nice)

For now this fixes #67 and parts of #69 (nice)
ahtlon added 2 commits 2025-01-28 12:22:08 +01:00
[nextcloud] add some attributes f7943d981b
Fix #67
All checks were successful
Check flake syntax / flake-check (push) Successful in 4m21s
Details
e94410ca54
ahtlon commented 2025-01-28 12:23:13 +01:00
Author
Collaborator
Copy Link

Warning: I have not tested e94410ca54 yet

Warning: I have not tested e94410ca54281a41b0d48cd82634d9560917cf03 yet
kalipso commented 2025-01-28 14:13:14 +01:00
Owner
Copy Link

Warning: I have not tested e94410ca54 yet

The problem is that nextcloud runs inside microvm. so its /data dir will actually be a tmpfs. We need to share the hosts /data. for example as its done with /var right now in host_builder.nix

          {
            source = "/var/lib/microvms/${hostName}/var";
            mountPoint = "/var";
            tag = "var";
            proto = "virtiofs";
            socket = "var.socket";
          }

I currently see to possible solutions: either we only put the nextclouds data on storage, or we put all microvms /var on storage. that way current and future vms would not bloat fannys root drive. But it would be important to make this configurable, maybe even on the host because microvms that run on hetzner need to mount the /var dir as it is right now (there is no /data dir).
Maybe for simplicity we just go with the first option for now and implement something more sophisticated later on.

> Warning: I have not tested e94410ca54281a41b0d48cd82634d9560917cf03 yet The problem is that nextcloud runs inside microvm. so its /data dir will actually be a tmpfs. We need to share the hosts /data. for example as its done with /var right now in [host_builder.nix](https://git.dynamicdiscord.de/kalipso/infrastructure/src/commit/362d9cf488e0daff72450871c5801a5debbd39f6/machines/modules/host_builder.nix#L66-L72) ```nix { source = "/var/lib/microvms/${hostName}/var"; mountPoint = "/var"; tag = "var"; proto = "virtiofs"; socket = "var.socket"; } ``` I currently see to possible solutions: either we only put the nextclouds data on storage, or we put all microvms /var on storage. that way current and future vms would not bloat fannys root drive. But it would be important to make this configurable, maybe even on the host because microvms that run on hetzner need to mount the /var dir as it is right now (there is no /data dir). Maybe for simplicity we just go with the first option for now and implement something more sophisticated later on.
ahtlon commented 2025-01-29 10:49:05 +01:00
Author
Collaborator
Copy Link

What do you think about a wrapper module like options.malobeo.microvm.nextcloud that enables the necessary options like a (configurable) share?

What do you think about a wrapper module like `options.malobeo.microvm.nextcloud` that enables the necessary options like a (configurable) share?
ahtlon commented 2025-01-29 11:26:54 +01:00
Author
Collaborator
Copy Link

My idea is something like this edddfc5e3f but that doesn't work because of the imperative microvm workflow:

error:
       Failed assertions:
       - vm nextcloud: Fully-declarative VMs cannot also set a flake!
       - vm nextcloud: Fully-declarative VMs cannot set a updateFlake!
My idea is something like this edddfc5e3fb199865fe17a6c984855ece78f845f but that doesn't work because of the imperative microvm workflow: ``` error: Failed assertions: - vm nextcloud: Fully-declarative VMs cannot also set a flake! - vm nextcloud: Fully-declarative VMs cannot set a updateFlake! ```
kalipso commented 2025-01-29 14:03:40 +01:00
Owner
Copy Link

This is actually a bit more complicated than expected. As you mentioned we cannot mix up declarative/imperative microvms. From the host side we cannot change the microvm shares at all. So a working approach would be add a share like that to all microvms (or only nextcloud for now):

          {
            source = "/var/lib/microvms/data/${hostName}";
            mountPoint = "/data";
            tag = "data";
            proto = "virtiofs";
            socket = "var.socket";
          }

And then on the host side we could just mount storage (or an extra dataset for that usecase) on /var/lib/microvms/data if we want. That way we can deploy microvms to any host we want, no matter if they have additional storage or not, and if they do just mount the storage to the data dir.

Another, way more simple approach would be to just create a microvm dataset on the storage pool and mount that to /var/lib/microvms on fanny. that way just all microvms data will live on storage without any changes neccesary to our vm implementations.

This is actually a bit more complicated than expected. As you mentioned we cannot mix up declarative/imperative microvms. From the host side we cannot change the microvm shares at all. So a working approach would be add a share like that to all microvms (or only nextcloud for now): ```nix { source = "/var/lib/microvms/data/${hostName}"; mountPoint = "/data"; tag = "data"; proto = "virtiofs"; socket = "var.socket"; } ``` And then on the host side we could just mount storage (or an extra dataset for that usecase) on `/var/lib/microvms/data` if we want. That way we can deploy microvms to any host we want, no matter if they have additional storage or not, and if they do just mount the storage to the data dir. Another, way more simple approach would be to just create a microvm dataset on the storage pool and mount that to `/var/lib/microvms` on fanny. that way just all microvms data will live on storage without any changes neccesary to our vm implementations.
ahtlon added 1 commit 2025-02-06 15:40:46 +01:00
Add microvm data dirs
All checks were successful
Check flake syntax / flake-check (push) Successful in 4m17s
Details
67399b462d 
(untested because virtiofs mounts currently dont work)
kalipso added 2 commits 2025-02-06 17:37:32 +01:00
[disko] no encrypted swap when encryption disabled 46ed793529
[fanny] more ram and cores for vmVariantWithDisko
All checks were successful
Check flake syntax / flake-check (push) Successful in 4m13s
Details
9f62e03d95
kalipso commented 2025-02-06 17:40:21 +01:00
Owner
Copy Link

When setting malobeo.disks.encryption = false; (and setting reservation = 0G; but i think thats just cause my host has nearly no diskspace right now) iam able to run fanny with nix run .\#nixosConfigurations.fanny.config.system.build.vmWithDisko and it looks good. Sadly the microvms fail to boot (due to vmvariant issues i think) but iam confident the virtiofs mount should work without testing.

I think this can be merged.

When setting `malobeo.disks.encryption = false;` (and setting reservation = 0G; but i think thats just cause my host has nearly no diskspace right now) iam able to run fanny with `nix run .\#nixosConfigurations.fanny.config.system.build.vmWithDisko` and it looks good. Sadly the microvms fail to boot (due to vmvariant issues i think) but iam confident the virtiofs mount should work without testing. I think this can be merged.
kalipso requested review from kalipso 2025-02-06 17:40:43 +01:00
kalipso approved these changes 2025-02-06 17:44:03 +01:00
ahtlon commented 2025-02-07 19:18:37 +01:00
Author
Collaborator
Copy Link

I've tested the configuration but the data mount doesn't show up.
[malobeo@fanny:~]$ cat /nix/store/1wfvgdzxm3fxcxm6i8vlpdw012137rzv-durruti-virtiofsd-supervisord.conf

[eventlistener:notify]
command=/nix/store/vljpddad1x79pqyv1jp9sw3lbl9a7666-supervisord-event-handler
events=PROCESS_STATE

[program:virtiofsd-etc]
autorestart=true
command=/nix/store/c2p4mygvvxphk19adpf1g8kfq4rij9hs-virtiofsd-etc
stderr_syslog=true
stdout_syslog=true

[program:virtiofsd-store]
autorestart=true
command=/nix/store/922khrpdx65qx520k5q77xjv82c6al1j-virtiofsd-store
stderr_syslog=true
stdout_syslog=true

[program:virtiofsd-var]
autorestart=true
command=/nix/store/9li4di4yh1xwhqkg675x8zja5xdbws4n-virtiofsd-var
stderr_syslog=true
stdout_syslog=true

[supervisord]
nodaemon=true
I've tested the configuration but the data mount doesn't show up. `[malobeo@fanny:~]$ cat /nix/store/1wfvgdzxm3fxcxm6i8vlpdw012137rzv-durruti-virtiofsd-supervisord.conf` ``` [eventlistener:notify] command=/nix/store/vljpddad1x79pqyv1jp9sw3lbl9a7666-supervisord-event-handler events=PROCESS_STATE [program:virtiofsd-etc] autorestart=true command=/nix/store/c2p4mygvvxphk19adpf1g8kfq4rij9hs-virtiofsd-etc stderr_syslog=true stdout_syslog=true [program:virtiofsd-store] autorestart=true command=/nix/store/922khrpdx65qx520k5q77xjv82c6al1j-virtiofsd-store stderr_syslog=true stdout_syslog=true [program:virtiofsd-var] autorestart=true command=/nix/store/9li4di4yh1xwhqkg675x8zja5xdbws4n-virtiofsd-var stderr_syslog=true stdout_syslog=true [supervisord] nodaemon=true ```
kalipso merged commit 698cfcf383 into master 2025-02-11 17:47:32 +01:00
ahtlon deleted branch nextcloud-issue-1 2025-03-11 18:30:59 +01:00
Sign in to join this conversation.
Reviewers
No Reviewers
kalipso
Labels
Clear labels
Bug/Problem
Lokal
Migration
Module/Disks
Module/Initssh
Request
Service
Updates
nextcloud
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
ahtlon quinn kalipso
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kalipso/infrastructure#81
Delete Branch "nextcloud-issue-1"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?