Is the plan for people to migrate a CORE deployment to SCALE ?
had a loo at Scale and really like what I saw, but it crashed a couple of times on me, so ye def not ready to run the house on, yet. But would def like to look at it when it is more stable.
The plan is that CORE users will have an option to migrate ton SCALE.... ZFS pools and data sharing migrates, but not jails or plugins.
The primary reason for migrating would be linux containers or KVM....
There will be an "alpha-grade" migration path soon... for adventurous souls with time and an inclination to find and resolve issues. More conservative users should wait for reports on actual experience.
Users who are happy with the CORE feature set are encouraged to remain there. It has a lot more bake time and stability. FreeNAS 11.3-U5 is still the most solid and tested version, but 12.0-U2.1 is getting closer.
but considering I had problems with TrueNAS core also on my VM, most of which/all of which seems to have disappeared once I increase the resources to the VM, all my problems with scale might have been self inflicted due to not assigning enough resources.
The plan is that CORE users will have an option to migrate ton SCALE.... ZFS pools and data sharing migrates, but not jails or plugins.
The primary reason for migrating would be linux containers or KVM....
There will be an "alpha-grade" migration path soon... for adventurous souls with time and an inclination to find and resolve issues. More conservative users should wait for reports on actual experience.
Users who are happy with the CORE feature set are encouraged to remain there. It has a lot more bake time and stability. FreeNAS 11.3-U5 is still the most solid and tested version, but 12.0-U2.1 is getting closer.
Wanted to provide a heads-up that we've started the internal test of the migration paths from CORE to SCALE. It works most of the time, but that isn't good enough.
There's a catch-22 that the people asking for migration are also unlikely to have a good backup of their data. At this stage, it is too unreliable to recommend or promote. There are many corner cases to test and resolve.
So until we get closer to RELEASE quality, I'd recommend that new pools be set-up and data migrated. We'll let you know when there is a process and version that is reliable enough to test.
that “most” in your first line would be my “ok wait rather”...
I got backups, but it’s a bl00dy slept to copy everything back and would rather just wait, but def going to be a early adopter when you tell me it’s safe...
after that native Docker, so that I can run KIND cluster for def labs.
but will say the simplicity of running plex a d unify controller in jails will be missed.
Previously iX clearly stated there won't be official LXC support, at most you can expect said scentence in the Dev-Notes to mean "we will enable it for CLI use".
Maybe @morganL can chime in here, because it was his previous statements about not-going-to-support LXC, that created this confusion ;-)
docker-compose is not supported though and might even be removed in the future (if iX moves to another container engine, as docker is just the k8s container engine and not something that is supported in itself).
If you really want to use docker-compose for the long run (not just temporarily or for testing), I suggest not using SCALE and looking into another Appliance or OS all together.
Docker isn't supported, "deploying docker containers" is supported and it's a "solution based on docker" thats two different things all together.
That does not mean "docker compose" which is actually not supported at all. It's not prohibited either, but definately not supported.
--- Docker isn't supported, "deploying docker containers" is supported and it's a "solution based on docker" ---
if Docker is present to run containers, then what is not supported.
this starting to smell like 1/2 the solution/feature is given, but just enough to make your lips water and then be stuck.
G
I think you don't work in IT and that is causing some information issues, let me try to explain:
- The IT community is moving away from actually using "docker" to run docker-containers for some time now. So "running docker containers" does not have anything to do with using the docker engine (or docker compose).
- iX opted to use docker for their k8s backend (hence: "based on docker"), that does not mean they support every part of the docker suite.
- You confuse "allowed" and "included" with "supported", supported means iX "guarantees" a progam to work and you can file bugreports for it. "docker-compose" is "included" and "allowed", but is not supported or guaranteed to be present in the future. Your data is also not guaranteed to be safe on update or restart when using "docker-compose".
You get what was promised: The ability to run docker-containers in a managed solution based on docker (k8s with docker as it's container engine)
TrueNAS SCALE is a K8S appliance with support for docker containers. Which are run on the k8s framework, which currently uses the docker container engine.
But:
I think the primary issue here is you confuse the engine (docker) with the deployment framework (in this case: Helm). iX just opted to pick Helm as their framework for deploying containers and not docker-compose.
hehehe, ahh ok, I just heard/was previously told docker will be supported, so ws contradictory to what I previously heard.
and ye I know the difference between running container and running container on docker.
To be honest: I don't like how they market it with the docker brandname while they only support k8s, which doesn't have to run docker. They just "happen" to have picked docker as their k8s engine. That shouldn't be used to push sales imho.
But that does explain where your wrong information comes from though... It's quite the nuance :)
hehehe, ahh ok, I just heard/was previously told docker will be supported, so ws contradictory to what I previously heard.
and ye I know the difference between running container and running container on docker.
When we first started SCALE we were considering Docker engine or Kubernetes. However, after starting the work, we realized that picking one would be more efficient. Kubernetes provided a lot more tools and was much more future-proof so we picked Kubernetes and then made sure there were the tools to run a Docker container easily.
When we first started SCALE we were considering Docker engine or Kubernetes. However, after starting the work, we relaized that picking one would be more efficient. Kubernetes provided a lot more tools and was much more future-proof so we picked Kubernetes and then made sure there were the tool to run a Docker container easily.
Agreed: Not all things that kubernetes supports (or uses), is always 100% compatible with how docker does things.
Supporting both (running on the same engine), might lead to dev time that needs to be put into all sorts of minor edgecases.
Also: There is some discussion in the dev community how long docker (as an engine) is going to keep going. Because Kubernetes is engine agnostic, it might in the future make it easier to make changes to the underlaying containerengine, without needing to deal with users getting impacted by it.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
