I am really disappointed with the decision of rebasing. Dockers in Corral really worked for me and I really liked Corral's UI -simple enough to understand what's going on but sophisticated enough to run complicated set-ups. I really don't want to revert back to 9.10 and/or get used to another UI but I guess I will have to unless I move away from freenas completely.
It would really help me feel better about all this if I understood the details behind the decision of rebasing to 9.10. Kris Moore mentions issues with MontageJS and Plan 9 filesystem code but not enough details is provided for me to be able to dig through and find out what exactly were the wrong decisions made in Corral and why IX decided to roll back.
Also, I really admired jkh and his communication in this forum with the community. It is a real loss that he moved away all of a sudden. Perhaps I am reading too much between the lines but in his last post he writes:
"Even though some folks have somewhat stubbornly refused to see FreeNAS as a genuinely open source project and instead one in which iXsystems calls all the shots and its users are just spectators, you collectively have more power and influence than I think you've ever realized. "
I wonder what's the story behind here? If I were to trust IX systems for their future releases (and I really would like to), I would like to understand a little bit of what's going on behind the scenes. It would be especially enlightening if someone could explain in some detail what the reasons are for rebasing to 9.10.
Thanks.
====
William Grzybowski gave some details that was helpful to me but it seems that his post disappeared. Luckily, I had it opened in my browser so here is a copy of it in case it helps others:
"First I would like to make it clear this is my personal opinion. Do not take it in anyway as official reasons.
It was not about anything the user can see, its all about what is under the hood.
The following image illustrates it pretty well:
In my vision thats exactly what happened.
Corral was very beautiful looking, from outside. The UI is quite beautiful, the CLI did what it was supposed to do, it has shiny dockers.
There are several things that did lead to this.
First point is the UI. Apparently writing full blown Rich Internet Applications is hard. As you did read in this first post the core of the UI was MontageJS, it does not matter anymore why it was chosen, but even the developers who helped write this framework did not like it. It was already expected to be replaced to something different but were stopped by someone so the product could actually be released. The whole UI was built without a single automation test and there are probably about 5 people in the world who really understand this framework. So how were we supposed to keep supporting this virtually dead javascript framework (to us at least) or completely swap it with something else and without automatic testing in place? its like getting a Muscle car, put the engine of a Ferrari _while_ its still running and expect everything to keep working perfectly. So yeah, not happening...
Even after this long period of development there were basic things that simply did not work in the GUI. One can't even replace a disk from GUI. It only works well in Chrome. It does not provide historical reporting stats. There is no documentation. Translation is not supported, it was not built with that in mind.
The backend architecture is over engineered. There was no such thing as "do not reinvent the wheel". For instance, did you know the DHCP protocol was rewritten in a python library and is leading to several compatibility issues? The well known, stable and worldwide used system logging (syslog-ng) was rewritten to a python log daemon (from scratch), making diagnosing debugging from a support perspective much harder? The core of the middleware was about to be rewritten from scratch using another language? Cython modules created without thread-safety in mind (e.g. smbconf) which can cause service corruption?
Several changes were made to FreeBSD which could not be upstreamed, making it very difficult to maintain. ZFS was modified to have a special aclmode making it incompatible with every other ZFS implementation (breaking replication for instance).
The whole middleware does not have a single functional test. Thats right, whole middleware was built without a testing harness. (Fix one thing, break another).
The system is bloated. Have you actually tried running a "top" in a stock system and check how many "auxiliary" services there are? Close to a dozen python services, eating up a lot of RAM.
There is no documentation for the new REST API. There is no compatibility whatsoever with the old REST API rendering multiple applications useless (specially for the enterprise side, e.g. Zabbix, vCenter, etc).
Several design decisions were made in the course of development that simply made a seamless migration from old codebase to Corral extremely hard and painful.
The list goes on, but I will stop here. I am probably getting too technical.
All of that (and more) made us realize it was going to be a lot more work to bring it to sanity then incorporate the features on the 9.10 codebase.
Also to give you an idea, the new experimental UI (which you can find in 9.10 nightlies) was written in about a week, works on every major browser (even mobile) and supports translation out of the box. That has shown us it does not need to be complicated. "
