No issue on this from my side it'd be a nice simplification 👍

Fifo has been stale for quite a while now. I would like to get it up and running on current erlang/smartos/ect. In the past 4 years things have changed some and I think Fifo could be simplified. In the beginning Fifo was designed for cloud providers, but with no providers using Fifo anymore there are several parts that could be removed/simplified that in turn could make maintenance easier. Some of these would clearly break compatibility with current versions, but AFAIK I am the only production user so unless somebody else speaks up... I would like to use this issue as a public forum for discussion on if/why the listed items should not be removed/simplified.

Chunter

• Remove KVM support in favor of Bhyve. There is no reason to use KVM anymore.
• Remove S3 support
• Remove VPN support (just put WG (or anything else you want) inside your zone if you want )

Howl

• Kill completely in favor of server side static page rendering

Sniffle

• Remove S3 support
• Remove Ability to create/restore backups
• Remove Dataset management/caching in favor of having hosts have imgadm configured to look at a ds server. When asked to create a VM Chunter would check if the ds is installed on the host, if not ask imgadm to install it, sleep for a few seconds, repeat.
• Remove IP address management in favor of IPv6. With IPv6 we would only need to track a vlan and a network prefix for that network.
• Remove Organizations. If we are not targeting cloud providers we don't really need orgs.
• Remove ZDoor snapshot support. Just use a delegated dataset and manage snapshots using builtin tooling.
• Stack/Clusters. Cool idea but I doubt anybody is using this.

Snarl

• Remove Orgs
• Remove Yubikey support
• I think that we should at least discuss IP based auth similar to how Tailscale does auth. It has to potential to greatly simplify things to just check if the user is coming from 100.123.. and then map that IP to a user.

ZLogin/Docker

• Remove Docker support. Docker using LX zones has too many oddities to be useful. Some docker images use security features or system calls that LX does not support. A better approach would be to have a Boot to Docker type image for bhyve based on some skinny Linux distro like Apline, that would look at the zone metadata for a docker image id and then boot that. We would sacrifice a small bit of performance but would get 100% compatibility.

Cerberus

• Fifo.Cloud has a nice Elixir based server side rendered UI. Perhaps we could talk to Heinz about a buyout to open source the code for that, giving us a big head start. The code for that is much easier to wrap one's head around than the JS/SPA/WhateverHipsterLibraryOfTheDay that we currently have. It also is a great starting point for a revised Rest API. I think we could explore the idea of not having a webui in favor of only a TUI.

FreeBSD

• Kill. The FreeBSD community doesn't seem to be interested.

Fifo Python Client

• Kill. It is a paint to work with. I have "FCloud" which is a Haskell based TUI for Fifo.Cloud I would be happy to open source that. I would also be willing to rewrite in something more mainline like Rust. Basically I want a single executable that users can run and not the Python hell of a million files/deps.

Configuration: SmartOS build: 20200603T203505Z, FIFO v.0.9.3p4 & Chunter v.0.9.3p20

Issue: It seems that each time a new KVM VM is created, Chunter (or rather vmadm) makes a snapshot with name <dataset_image_UUID>@ undefined. This snapshot has a related clone which is actually the root disk of the created VM. Second time when a new VM is created from same dataset image, the snapshot creation fails due to already existing with same name.

Chunter's logs (with debugging enabled) shows:

2020-08-12 09:40:34.540 [debug] <0.2102.0>@vmadm:wait_for_text:206 [vmadm] Command failed: cannot create snapshot 'zones/b8a4ba09-ef63-4ee0-adaf-72cc677d863d@undefined': dataset already exists

My work around is to manually rename the existing snapshot <dataset_image_UUID>@ undefined to <dataset_image_UUID>@vm_name, but that's not an elegant fix at all.

Depends on patches in wiggle: wiggle!2

This fixes the build for Erlang 22. Still needs testing in operation.

Depends on this PR to cowboy_oauth: Project-FiFo/cowboy_oauth!1

This gets things building again

linking this pr Project-FiFo/forks/bcrypt!1 if you want to merge that in to the fork so we don't have to use the github copy

Newer SmartOS versions require the 'xnet' library to be explicitly declared to the linker. While this might not be needed on plain Solaris this is good form non the less (since bcrypt uses symbols from the net library).

@kevinmeziere patched up again and rebased it off of master instead of dev-0.9.4

I think you may have it on your smartos too, but you only would trigger it/the linker when building the full package with gmake smartos. Just doing a plain rebar3 compile will build ok with the unpatched bcrypt. The person who made the PR for the bcrypt library was also using smartos so I don't think it matters. I am using gcc9 for what it's worth but it looks like this was a gcc7 issue from the branch name.

Where there issues with this on omini? On smartos this did not need to be updated.

1.3.1 seems to work ok.

  {erlware_commons, "~>1.3.1"},

should have a branch

  {fifo_lager, ".*", {git, "https://gitlab.com/Project-FiFo/FiFo/fifo_lager.git"}, {branch, "master"}},

This brings the build in order for Erlang 22. There are some upstream third party dependencies (bcrypt, bitcask) which have not been released, which we may want to merge into the Fifo forks first so we have copies of them saved.

We could do something like this using CMake: https://gitlab.com/Project-FiFo/forks/erlang-rocksdb/-/blob/master/deps/rocksdb/CMakeLists.txt#L254 to check for thread_local support. I'm concerned about diverging much or any of the rocksdb source code from upstream though. How does the rocksdb code here get maintained, it seems like a good place to use a gitsubmodule here instead of what looks like the rocksdb code is copied over from time to time.

It would be much better if this checked for a flag or version or something but I could not find any documentation on when it was introduced. Right not this is not backwards compatible with datasets before late 2019.

@kevinmeziere here I am trying to get Fifo to build from source and finding your trail of bread crumbs everywhere lol... thanks for these patches. I started working on getting it running on OmniOS a week ago and the only way forward was to build from source. I plan to use OmniOS as my "bootstrapping" / control server(s) so I can install one OmniOS the "normal" way and have all the SmartOS slaves also netboot off of that.

Kevin Meziere (9813b706) at 01 May 06:50

Kevin Meziere (a084ecc2) at 01 May 06:34