iXsystems, when are you going to stop pretending that CORE has (usable) plugins?

Status
Not open for further replies.
Joined
Jul 10, 2016
Messages
521
I feel your pain...

1671340615589.jpeg
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
I don't want to be bitter but seeing comments like https://github.com/iocage/iocage/issues/1289#issuecomment-1273455731 make me feel that we are fighting a rear guard holding action and sacrificing our time for a corp that is happy to take that free effort without telling us that the reward we expect (a functioning NAS with working jails) is being left to run into the ice burg while they chase a new shinny boat.
We have perfectly fine working jails. We don't have pre-packaged maintained and upgradeable plugins. Just install in standard jails and you are good.
 

Baenwort

Explorer
Joined
Feb 19, 2015
Messages
93
We have perfectly fine working jails. We don't have pre-packaged maintained and upgradeable plugins. Just install in standard jails and you are good.
That comment was saying that iX has stopped working on iocage and it is drifting without anyone to issue a new release. Without iocage being maintained we won't have standard jails forever...
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
That comment was saying that iX has stopped working on iocage and it is drifting without anyone to issue a new release. Without iocage being maintained we won't have standard jails forever...

Iocage and jails are solid and supported within TrueNAS. If you have any specific major issues, please document them.

The challenge we have is maintaining a wide range of plugins. The kubernetes/docker approach is better for pre-packaged Apps. The vast majority of application developers are embracing linux containers. There is a need to be technically and economically pragmatic to support both existing and new users.

We love jails; we are not arguing that linux containers are superior.....but they are more popular.
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
I guess I could start to create and publish some Ansible playbooks to set up application X in a jail. Hmmm ...
 

Baenwort

Explorer
Joined
Feb 19, 2015
Messages
93
Iocage and jails are solid and supported within TrueNAS. If you have any specific major issues, please document them.

The challenge we have is maintaining a wide range of plugins. The kubernetes/docker approach is better for pre-packaged Apps. The vast majority of application developers are embracing linux containers. There is a need to be technically and economically pragmatic to support both existing and new users.

We love jails; we are not arguing that linux containers are superior.....but they are more popular.

There are outstanding security pull requests and feature pull requests that haven't been moved on in two years: https://github.com/iocage/iocage/pulls I don't think you can say that it is solid and supported with no action after that much time.

It is also mentioned in the PR I linked in my first post a statement by a iX representative that they do not see Core as anything but a file server which implies that even self managed jails are on shaky ground.

I do think that putting some community members in the seat to approve community plug-in repo might really help as one of the biggest barriers right now is how slow iX has been in approving changes to community plugins.

The second thing that would take some effort from iX but would make plug-ins on CORE a lot better is to fix how long it takes for accepted changes to the community repo to be accessed in TrueNAS. Right now it only happens when there is a patch for TrueNAS and that isn't frequent enough to handle breaking issues in plug-ins.
 

danb35

Hall of Famer
Joined
Aug 16, 2011
Messages
15,458

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
There are outstanding security pull requests and feature pull requests that haven't been moved on in two years: https://github.com/iocage/iocage/pulls I don't think you can say that it is solid and supported with no action after that much time.

Let's discuss iocage first..... its a complex situation.

Iocage was developed by a FreeBSD developer who owns the repo
iXsystems liked the project and hired him to integrate it into FreeNAS/CORE - it worked well.
The developer later left for a more lucrative job in a big Linux company (Commercial success is critical for retaining talent)
The official iocage project stopped and is still owned by the developer.
TrueNAS uses a fork of the Iocage project and has maintained it it with any necessary bug fixes.
Changing from iocage to another jail manager is a major project which would be disruptive to existing CORE users.
The departure of the Iocage developer and the lack of community support for the project was one of the reasons for IX to decide that we should embrace Linux and the Container ecosystem. (If you can't beat them , join them.)

So, our recommendation is that we focus on any bugs in iocage that are really impacting CORE and its jail users. If there are impactful bugs, we intend to fix them. If there are any bugs, please identify them with their Jira ticket numbers and we can prioritize.
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
I do think that putting some community members in the seat to approve community plug-in repo might really help as one of the biggest barriers right now is how slow iX has been in approving changes to community plugins.

The second thing that would take some effort from iX but would make plug-ins on CORE a lot better is to fix how long it takes for accepted changes to the community repo to be accessed in TrueNAS. Right now it only happens when there is a patch for TrueNAS and that isn't frequent enough to handle breaking issues in plug-ins.

Now let's discuss the plugin repo process.

Its a fair criticism that we've been slow to approve Plugin repo changes .. we don't like to make changes we haven't tested.

We've had a discussion and are open to community members being engaged. Ideally, we'd like 2 or 3 community members to take ownership of this role and collaborate with us. It would require them to test and approve changes. A software development background is probably needed.

If anyone is interested in this role, please indicate your interest and contact @Kris Moore via the Discord channel. This enables faster response times.
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
Let's discuss iocage first..... its a complex situation.

Iocage was developed by a FreeBSD developer who owns the repo
iXsystems liked the project and hired him to integrate it into FreeNAS/CORE - it worked well.
The developer later left for a more lucrative job in a big Linux company (Commercial success is critical for retaining talent)
The official iocage project stopped and is still owned by the developer.
TrueNAS uses a fork of the Iocage project and has maintained it it with any necessary bug fixes.
Changing from iocage to another jail manager is a major project which would be disruptive to existing CORE users.
The departure of the Iocage developer and the lack of community support for the project was one of the reasons for IX to decide that we should embrace Linux and the Container ecosystem. (If you can't beat them , join them.)

So, our recommendation is that we focus on any bugs in iocage that are really impacting CORE and its jail users. If there are impactful bugs, we intend to fix them. If there are any bugs, please identify them with their Jira ticket numbers and we can prioritize.
Not precisely a bug but a major design flaw. We should somehow abandon automatic creation of bridge interfaces and refuse to create a bridged VNET jail unless the user manually created a bridge IF first. At least that's the simplest way to fix the problem. The problem is that you MUST NOT have a bridge member interface with an IP address.

All documented here:

BTW: could you transfer that issue to my user account with email address ...@punkt.de? Somehow your cloud migration picked the wrong one of two Atlassian accounts I own. Two different organisations ...

Kind regards,
Patrick
 

morganL

Captain Morgan
Administrator
Moderator
iXsystems
Joined
Mar 10, 2018
Messages
2,691
Not precisely a bug but a major design flaw. We should somehow abandon automatic creation of bridge interfaces and refuse to create a bridged VNET jail unless the user manually created a bridge IF first. At least that's the simplest way to fix the problem. The problem is that you MUST NOT have a bridge member interface with an IP address.
Ironically, we are being criticized for not automatically creating a bridge in the SCALE discussions.

What if we made it easy to remove the bridge?
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,740
The bridge is necessary. The IP address configuration must move from the member interface to the bridge if you create it automatically. MUST like in RFC MUST. And that opens quite a can of worms, don't you think?

I don't know if that IP address constraint is present in Linux, too. But in FreeBSD it is.

So I thought a simple implementation with a correct and consistent user experience might be to not automatically create the bridge interfaces. Might feel like a regression but correctness over convenience - especially when convenience breaks things.

The UI could tell the user "to connect a VNET jail to an interface you must create a vSwitch, first" and then guide to the correct setting. Name it e.g. vSwitch to not bother users with FreeBSD peculiarities they might not understand. Everyone who's been using hypervisors in production knows what a vSwitch is. I hope. :wink:
 
Last edited:
Status
Not open for further replies.
Top