Register for the iXsystems Community to get an ad-free experience and exclusive discounts in our eBay Store.

TrueNAS Scale Release Plan

ikke

Member
Joined
Apr 22, 2012
Messages
122
I agree with you about the trend. I personally moved further from docker couple of years ago, so I can't say from experience any more if they can be run simultaneously. Personally I only run one. Podman doesn't need daemon, so if one runs docker, it won't disturb if both are installed. And in my case, I'd just disable docker. So no conflict, I suppose.

I know I'm not good representative for business case for Ix. I just run small low power home NAS. Any extra service there is just hogging resources. No need to juggle containers around cluster in my home case. Such is done at work on proper clusters, similar environments like where SCALE is targeted to. I set my containers static way, automated by a ansible at home. Enough for my home automation and some utility services like nextcloud and such. VMs, kube, etcd.... are just resource hogs there.
 

ornias

Senior Member
Joined
Mar 6, 2020
Messages
473
To be fair, the "branch standard" solution for the container runtime behind Kubernetes these days (and definitely looking to the future) is not Docker. It's CRI-O (of which podman can work concurrently with) or Containerd. Most of the main k8s distributions have already migrated to a CRI native container runtime and as Docker-shim is going to be removed from k8s in a future release, going with the right implementation now may save dev work in the future.
True, In was mostly describing the "pick one to go with and stick with it till it's done" issue, than trying to explain the relationship between docker/others and orchestrators.

Under the hood SCALE is using k3s, which uses Docker with Containerd under the hood. The k3s project will potentially migrate away from Docker one day in line with other distributions(*), and already supports any CRI implementation today.
Thats interesting insight, thank you! :)

Personally, I can't wait for people to longer think or associate Docker with Kubernetes in anything but a historical sense.
Guess it's a bit like the cluster**** with swarm and swarm-mode, folks tend to have something in-their-mind and it's hard to change that thought patern.

Doesn't help the homelabbers much of course as that community often feels k8s is too much for their needs (personally I disagree k3s is almost perfect for that group!)
I'm currently spending quite some weeks learning to move from swarm-mode to k8s. The learning curve is higher imho, but I don't think it's "too much for my needs" as you don't have to use everything within k8s if you don't want to. A simple "take this docker, connect ports and attatch storage"-container is perfectly possible. Both things like healthchecks are a LOT more solid imho.

but I wonder how much $ Ix makes from the non-enterprise customer base anyway.
The thing is: most things they write for their enterprise customers are useable by their non-enterprise customers too.
The margins on the non-enterprise hardware are nice and while I agree that the revenue won't even be comparable to the enterprise customers, it's basically: Free extra revenue, Free extra testers, Free extra PR, Free source to look for new employees etc. All of which are have a significant value ;-)

Not that this should all matter much, as if someone is using SCALE as intended then they'll be using the helm based plugins and shouldn't care too much about the underlying container runtime. If someone is wanting to do significant manual CLI work/manual deployments then one could assume this may eventually cause issues and they'd be better off running it in a VM or elsewhere.
Precisely.

Also, @ikke, you can always install Podman manually and give it a go (it used to conflict with Docker but I've just checked and that seems to be resolved). I can understand why they wouldn't bundle it in given if they include it they'd have to support it for their Enterprise customers so the less moving parts you ship the easier that support becomes.
A VM might be cleaner though.... plain deb10 or something like it...

(* As a senior employee of SUSE, who recently announced their acquisition of Rancher/k3s this should not be taken as indicative of any product roadmap announcement but a comment on a general trend in the k8s upstream community)
Posts with disclaimers are the best posts :tongue:
 

Victor-Zorro

Newbie
Joined
Oct 30, 2020
Messages
3
I am really curious.....
Specially the KVM implementation.
Can I expect something like I can do with cockpit?
Or, will I be able to do pass-through of graphics for instance?
Will one be able to edit the xml?
Right now I run Truenass as a vm with passthrough of the sas controller and nvme.
But I might do it the other way around, run my Windows and Linux Machines on Truenas scale.

Looking forward...
 

Victor-Zorro

Newbie
Joined
Oct 30, 2020
Messages
3
I created a test vm. As I can see, it is better than cockpit. My guess is that it is more comparable with unraid. The kvm implementation allows also pass-through of hardware devices! Really excited!
 

silverback

Member
Joined
Jun 26, 2016
Messages
116
I am really curious.....
Specially the KVM implementation.
Can I expect something like I can do with cockpit?
Or, will I be able to do pass-through of graphics for instance?
Will one be able to edit the xml?
Right now I run Truenass as a vm with passthrough of the sas controller and nvme.
But I might do it the other way around, run my Windows and Linux Machines on Truenas scale.

Looking forward...
I currently run Windows 10 on a Scale machine w/ GPU passthrough. In order to accomplish this I had to build the windows VM on Debian and import it into Scale with “virsh” from a terminal. I haven’t yet been able to do it from Scale Alpha, it always errors out in various ways.
 

Victor-Zorro

Newbie
Joined
Oct 30, 2020
Messages
3
Ok, Still Curious. I can not test this currently because I am running scale as a vm. So it is impossible to try since I cannot passthrough the vt-d extensions to a vm... would be nice though. But I will try soon in a proper way.
My guess is that I will run scale as a base os. and create 2 nvme zfs file-systems. one for vm and one as a shared work-disk.
It will make my setup much more simple.
 
Top