astro / skyflake Goto Github PK

Hello @astro !
Also cc @spacekitteh

I am a member of HacDC, an american hackerspace inspired by the CCC. I had seen @astro's NixCon talk regarding microvm.nix, and i am searching for how to run the skyflake code in my company's lab - also in the hackerspace soon if possible.

As the talk ends, @astro says 'One does not simply do a major-version upgrade of Ceph'. This is similar to my experience, and Ceph seems to be a large and cumbersome dependency for this code.

Since i had no luck launching Ceph locally on my 3 nodes, i am choosing to use [SeaweedFS]; the commands to run a HA cluster are super simple and i accomplished them in less than an hour. My seaweed systemd config is here:
https://base.bingo/code/build/src/branch/mesh/nixos/process.nix#L31
[SeaweedFS]: https://github.com/seaweedfs/seaweedfs

Can you help me remake skyflake to run on the much simpler seaweedFS, and drop ceph as a dependency?

I looked around the nix modules, and my guess is the host nodes only need shared volumes for the nix store and the garbage collection roots. Are these volumes also shared inside the microVMs, or only used during the original vm builds? There should also be persistent VM storage, and that is a secondary concern.

I plan to spend some more days on this though I'm in a hurry to be back to application programming; i could use as much help as possible. Your approach seems much more dependable than kubernetes and i think reducing your dependency on Ceph can make your program much more accessible.

Glad for your help!
Callie

So, I'm converting my existing Ceph cluster to use Skyflake. One issue that is stopping me from using it to deploy OSDs with, however, is that I require full disk encryption for each OSD.

I deployed my OSDs via ceph-volume create, with the --dmcrypt flag. This sets up each OSD to be encrypted via LUKS. At boot, ceph-volume activate grabs the LUKS keys from a Ceph monitor, passes them to dm-crypt, and then proceeds as normal in activating the OSDs.

Existing OSDs can be easily converted to use ceph-volume; so is it possible to change the OSD management logic to use ceph-volume instead? I suspect it would greatly simplify the implementation.

None of the ceph-mds daemons manage to successfully start, and so no ceph filesystems can be mounted.

otherwise they might grow indefinitely. On a test machine they already occupied 13 GB.