Moving Application Pool

TrueNAS General
1

Hi,

Newbie here, I have two pools (A & B). Can I move my application (currently in Pool A) to Pool B ? If so, how? Many thx

And retain everything (i.e. Radarr, Plex etc.) :slight_smile:

Richard

2

On the apps tab and on the top right corner klick on settings and choose pool.
Keep in mind that apps, that use a databases might need manual intervention and require you to manually save a database dump that needs to be imported after the pool change.

1 Like
3

tyvm

4

If you’re using TrueCharts apps and SCALE Dragonfish (24.04), I believe this will no longer work. But on Cobia it should just be as simple as choosing a different pool.

5

@Dan Is that (IYO) a bug or by design?

6

By design, I think–not that this result was intended, but that it’s an unavoidable consequence of other decisions. As best I understand (with the caution that that probably isn’t very well), under Cobia and prior, TC apps used PVCs[1] for storage, which were inside the ix-applications dataset. Therefore, if you moved that dataset, you moved everything in it, and it’s all good.

In Dragonfish, this is no longer supported as an app storage method. TC’s new method is to have you install OpenEBS, give it another dataset on the apps pool[2] to work with, and it in turn handles your app storage. But since that’s outside the ix-applications dataset, it doesn’t get moved when you choose a different pool. I’d guess you could manually move that dataset, but haven’t tried any kind of testing on that question.

  1. For which they received some criticism; I don’t know enough to know whether that criticism was warranted or not ↩︎

  2. I’m not sure why it’s required that the storage be on the same pool as the apps themselves, but that’s what their docs say. ↩︎

7

The Problem for truecharts was that, in previous versions of truenas, iX was providing the open-eps implementation truecharts used to provide the pvc storage. iX never used it and therefore iX decided to remove it with dragonfish. Truecharts then implemented their own version with their openebs app to still provide pvc storage for their apps. But, as you said, it’s not supported to still use the ix-application dataset to store their version of pvc and you need to create a new dataset outset ix-application. the rest afaik is as you said dan.

2 Likes
8

A quick recap on this last thing then:

  1. ixSystems create K3S functionality including ability to have PVCs.

  2. ixSystems creates functionality to allow 3rd parties to create K3S charts and a catalogue for them and integrate into SCALE. TrueCharts takes advantage of that and (to provide the best technical experience) takes advantage of PVCs.

  3. ixSystems removes the PVC functionality from K3S because they don’t use it themselves.

This is at best short-sighted thinking. I do understand that ixSystems might feel the need to remove functionality from TrueNAS, (because supporting it is a cost), but…

  1. ixSystems needs to think wider about removing functionality they provide just because they themselves don’t use it - for example their users might be using it!!!

  2. Nevertheless, even if they decide to cease supporting it in the explicit knowledge that the functionality is used by their users, IMPO they need to provide much much much more notice for doing this that it suddenly disappearing in the newest major release.

That said, I can also imagine occasional situations where the need to remove functionality is identified at a late stage in a release’s development, but this should be the exception rather than the rule.

This is not the first time I have questioned the reasonableness of unilateral decisions to change functionality made without consultation or advance notice. Would @kris like to respond to this?

2 Likes
9

I should add that I have never personally really liked the idea of PVCs for storage - I personally prefer to have my storage explicitly defined externally to the container so that it is visible and I can apply suitable storage management policies for snapshots, backup replication etc. to it.

1 Like
10

I never liked them either as they made so many things harder. But, in Kubernetes, that additional abstraction layer could be seen as an advantage in some cases. Scale didn’t really use the abstraction layer flexibility though as far as I know.

PVC caused a lot of issues for many people as they didn’t realize if they delete the pod, they delete the data, in migrations, backups, etc.

1 Like
11

Exactly.

12

Was it deprecated in Cobia? Or was the rug just pulled out in Dragonfish?

Remembering Cobia did the same thing to nspawn containers (thankfully restored in Dragonfish)

Yes, IX say not to use unsupported stuff, but if something is seeing heavy community use I think IX needs to get better at deprecating it across a cycle, even if it was never official.

Docker was an example of being handled well I guess.

13

Ditto. Seems like a good way to lose data.