[EINVAL] values.scaleGPU: Not a list issue

[danb35]

This reflect badly on TrueNAS Scale

It only reflects badly on SCALE among those who can't tell the difference between SCALE itself, and an app catalog created by a third party who has no affiliation with the makers of SCALE.

 

[SecCon]

What's interesting to me is that it worked for Sonarr. It didn't work for Radarr or Prowlarr. Not sure why.

I think that was addressed on the Discord so if you look , perhaps you might find out why .

 

[FrostyCat]

What's interesting to me is that it worked for Sonarr. It didn't work for Radarr or Prowlarr. Not sure why.

Because they didn't move Sonarr to PG, but they did Radarr and Prowlarr. For what reason, who knows, I've heard it all, better backups, Sqlite instability, etc, it's probably all BS and done by the ear.

I tested Sonarr with the built-in backup/restore function and that worked too, much easier than messing around with PVCs.

 

[Rudi Pittman]

Scale, as TrueNAS, might not be responsible for this crap, yet we use, or try to use, it within the SCOPE of a TrueNAS Scale installation. I had only come so far as to run ONE app, Uptime-Kuma, and when shit hit the fan a few days ago. I looked for an explanation in several available resources, and found none. I am bit active on Discord and a few statements cought my eye, like



and



This reflect badly on TrueNAS Scale, whether you guys assume any responsibility for it or not. If a few simple things like a web site pinging app, in my opinion, do not work, and upgrades of said things do not work, why should I use the App functionality in TrueNAS Scale at all?

Now I face some sort of cleaning up and restoration to get anything working again. it seems to me I may have to reinstall TrueNAS Scale entirely, since no one will make me execute a text wall of cli shit.

*cough* In the interest of full disclosure.....you were quoting ME...errr both times too. *ducks*

 

[SecCon]

@Rudi Pittman nice to make your acquaintance Mr Pittman.

 

[Rudi Pittman]

@Rudi Pittman nice to make your acquaintance Mr Pittman.

What's that song? "it's a small world after all...." ^..^

 

[jolness1]

i am having the same problem since the last update home assistant just wont update saying ([EINVAL] values.scaleGPU: Not a list) and cannot simply reinstall. any suggestions?

Heavybullets Migration Script for TrueCharts | DaSnipe HomeLab Documentation

Credit

docs.dasnipe.com

There is this but not sure if it will work on home assistant. I need to try it with plex, this is the 2nd or 3rd time I have had to reinstall to upgrade and I am 99% sure the settings will not persist and I don't want to deal with all of the configuration issues again and resending all the invites etc etc etc.

 

[Rudi Pittman]

Heavybullets Migration Script for TrueCharts | DaSnipe HomeLab Documentation

Credit

docs.dasnipe.com

There is this but not sure if it will work on home assistant. I need to try it with plex, this is the 2nd or 3rd time I have had to reinstall to upgrade and I am 99% sure the settings will not persist and I don't want to deal with all of the configuration issues again and resending all the invites etc etc etc.

I mentioned this before but rather than use that migration tool which still requires you to redo the container setup yet still tie you to truecharts you can use heavyscript --mount to mount the PVC to a folder and copy that to a folder by appname....then mount that folder in a regular docker container as /config. I've confirmed this works fine with plex. You can also shell into the container and manually copy /config to mounted storage.

 

[Daisuke]

cannot simply reinstall. any suggestions?

Re-install is the only fix. Why you cannot re-install, because you have to redo all app settings? Most apps migrated to use PotgresSQL will definitely require a re-install.

 

[Sine]

Migration is the word... away from TC.

I have upgraded (read: reinstalled) what was not migratable, the rest is on 'official' stuff now.

There's a lot more blue in my system now than there's yellow.

 

[li_chang]

I have upgraded (read: reinstalled) what was not migratable, the rest is on 'official' stuff now.

There's a lot more blue in my system now than there's yellow.

That's the main reason I stopped using truecharts apps because of frequent changes regarding train/app setting... launch my own docker apps now and I just don't like their arrogant attitude...

 

[Zandr Milewski]

It only reflects badly on SCALE among those who can't tell the difference between SCALE itself, and an app catalog created by a third party who has no affiliation with the makers of SCALE.

It's been a while since I did a fresh install, but weren't the TrueCharts catalogs enabled by default? That makes it look at least endorsed by iX, and as such I do think it reflects badly on SCALE. iX has been increasingly vocal that it's a separate project, for obvious reasons.

 

[danb35]

weren't the TrueCharts catalogs enabled by default?

No, that's never been the case. You've always had to add them manually.

 

[corin.corvus]

I never reinstalled a app. Do i loose the Data in the app?

 

[brianaker]

The solution is to upgrade your apps.

GitHub - Heavybullets8/TT-Migration: PVC Migration script for Truenas SCALE

PVC Migration script for Truenas SCALE. Contribute to Heavybullets8/TT-Migration development by creating an account on GitHub.

github.com

 

[gbysec]

I can't count how many times I've had to nuke my whole install, either some instability of scale at the beginning (much better now though), or some breaking changes in TrueCharts....

There are 2 feature requests I keep thinking about:

• Auto-upgrades (lmao now that we see how TrueCharts considers their community's time with stupid migration issues.... a breaking GPU value in my chart for an app that doesn't need one ? great thanks....)
• More realistic: at least a damn export/import backup system for apps. Give me some kind of way to nuke/reinstall things, we all have that issue, it takes time to configure volumes properly, hostnames, secrets, env vars... I don't expect the import/reinstall to be hands-free, but at least fill some of the fields back ? Show me the ones that don't match anymore ?

 

[sammael]

@gbysec I would literally pay cash if there was a "take snapshot of app" button and "roll back" button that would let me pick to what state I want to roll back single app along with all it's data instead of trying to downgrade it or having to take snapshots manually or having to use external scripts.

I just spent a week migrating 40+ docker containers from a vm into (mostly truecharts) apps on 2 Scales, and while I wanted to cry at times and had to rebuild several containers multiple times, it all works now. The whole app system in scale to me looks made by someone who doesn't really use it, is very comfortable with cli and made it "just so it works enough", which makes it at times painfully hard to set up for layman user like myself regardless of if it's official/truecharts or docker container(those are actually easiest to set up, if Scale natively supported docker compose I would never use anything else.).

I've survived the last 2 truecharts breaking changes without data loss, just wish I could get the time it took me to re-create the apps back. So far heavy_script manages the auto updates just great. Fingers crossed it stays that way.

Also @truecharts please stop sending me (not me personally, but that's all the replies I see from yous on reddit or in here) to discord, I've got anxiety and panic attacks triggered by talking to people in real time (yeah my life is a hoot) so I can't do that :P

 

[Wolfspyre]

Hah. It could be worse. I got a life-time ban for daring to defend myself here after receiving a series of personal attacks there.

That said, I think some precision is due here:

The TrueCharts team clearly includes engineering talent that is providing free work toward fulfilling a big community need. The scale of the demand is such that there will be some percentage of pushy, unreasonable users that bombard them on a daily basis. And I can say from first-hand experience that fielding that kind of input can be annoying and demoralizing. So, there is a strong temptation to make a lot of rules, etc. to control how much time is spent on support.

Also, it should be pointed out that it is now a decent sized team over there. Not everyone has the same attitude. I can personally say that there are some very helpful, patient people on their team.

Furthermore, I'm excited to see how the TrueNAS Community apps develop. But, so far, TrueCharts has done a better job (than the official apps) of including the bells and whistles many users need. For specific examples: app-level VPN support, app-level ingress configuration, faster version updates.

The problems, imo, are fixable:

1. They should partner with or promote from within someone who better understands basic business / customer service.

I can already hear the "this isn't a business! it's free! take it or leave it!" response. Sorry, that just doesn't logically work. Even a person who says, "here, let me help you with that" out of the blue has some level of responsibility. It's true that it's less responsibility than if someone paid for that help. But, when you offer any help, even when free, it's fair for the people who accept the help to assume that you are at least committed to doing the job right and being considerate of their interests.

"You fucked up by trusting us too much." is never reasonable or ethical, even when you aren't charging anything. Right now, that seems to be the project's motto. Anyone who has run a successful business or been involved with CX at a company will understand this and know how to fix the tone issue.

2. Doing the job "right" entails doing the work to anticipate the most obvious problems users are going to have and preparing solutions (upgrade scripts, upgrade tutorials, etc.) in advance.

Again, I can hear the response, "we dont have time to figure out everyone in the world's configuration." Nobody is asking for that. But, there are very obvious, predictable problems that have come up during upgrades/changes that zero effort was put in to beyond maybe a one sentence warning on some obscure twitter feed. Engineers should not be playing dumb about the difference between edge cases and predictable problems affecting 90% of users.

Not wanting to deal with those issues isn't some principled position. It's wanting to move forward with a project while neglecting a perhaps unpleasant but necessary aspect of it.

3. Scale down the scope of the project.

It looks impressive on the surface to list out 3 million apps. But, it would be better to have fewer apps with enough support that users can rely on them more and count on better solutions during upgrades.

I'm pretty sure that 90% of TrueCharts users are using the same 20 or so apps.

It's understandable, certainly.

I have run infra teams... where the role of the team is to support the platform that has been built for the developers.

it often happens that a developer doesn't understand just how complicated the "simple thing they want to do" really is under the covers... and that causes a disconnect in expectation.... and many people have a **VERY** hard time viewing things from a perspective not their own.


as evidenced by the myriad posts here of ' hey I'm having this error too! ' without groking that under the covers a major shift has occurred and some manual twiddling needs to occur.

The engineers steering TrueCharts are, from my perspective, a little too myopic, opinionated, and difficult to work with for this to be sustainable long-term.

The fundamental problem here: Kube is **COMPLICATED** **AS** **HELL**
it's ALSO a moving target..
and assembling it into a point-and-click seamless solution is ASTOUNDINGLY HARD,
to do so WELL requires
- a clear vision of what is in/out of scope
- a LOT of technical prowess
- a strong guiding opinion on cohesive strategy
- a good roadmap
- clear, proactive communication
- a LOT of runway.
- a LOT of hands for different tasks
- a competent community
- mature communication

This is a lot of work to take on for a group of "volunteers"...

imagine doing all this work and hearing nothing but people pissed off at you for your contributions... that experience *SUCKS*.

I've been there.

it's thankless and neverending and it breaks people.

IOW, I get it. and still, I fall into the same bucket of 'people who are on the development team of tc's shit-list for one reason or another'


so.... while I feel for them, sincerely.... I can't say this is surprising.

 

[truecharts]

While we are not active here anymore in general, I think the last message does warrant a response, primarily the feedback/key-points pointed out there:

- a clear vision of what is in/out of scope
- a strong guiding opinion on cohesive strategy

This has been a huge problem for us in the last 2 years, mostly caused by the insanely quickly shiftling (back and forth) level of support from iX-Systems, leading to us having extremely long and frequent debates about things as basic as platform support. Obviously that influences clearity of scope A LOT.

While we internally have a thorough view on what the platform scope will look like in the next 3 years, we indeed have not completely finished a scope guidelines yet. That's a very good point and we'll have an internal discussion on who is going to write it :)

- a LOT of technical prowess

While pretty obvious at first sight, this has been a huge problem for us... While rolling out a simple application using our common backend is simple, there are not many volunteers with enough depth in helm and kube to work on common itself.

- a good roadmap

We've decided not to do roadmaps anymore, not because we don't want to (we actually do), but because we don't have the money to guarantee the roadmap goals are actually made at-all.
That sounds pretty base, but even with one paid developer, we could say "roadmap is a priority if high priority bugs are fixed" and that way we could have somewhat of a pseudo guarantee of hitting roadmap goals.
But with current funding, we're 100% dependant on free-time of developers, who also often already prioritise some high-priority bugs over their personal lives.

To give somewhat of a roadmap, we've started flagging all our github issues using github "milestones" based on the year-quarter we hope to have them implemented in.

- clear, proactive communication

We spend a lot of time on writhing news posts already, but yes: This could be a lot better.
Sadly enough, this is one of the area's we don't have enough staff for.

- a LOT of runway.
- a LOT of hands for different tasks

Actually the number of full-time-hours required is not that high:
With essentially 2 FTE staff members, we could basically have everything covered and room to improve/refactor issues.

With less than that, we need to make choices, which mostly means we have the developers focus on development and the rest of the staff on support and docs. Which does, indeed, cause documentation delays at times.

- a competent community

We're very happy with the competent community we've build! :)

- mature communication

We've worked hard the last few months to improve on that front, with different staff members picking up different communication channels and dropping communication platforms we've no active interest in maintaining a presence (such as this forum)

 

[FrostyCat]

- clear, proactive communication
- mature communication


We've worked hard the last few months to improve on that front, with different staff members picking up different communication channels and dropping communication platforms we've no active interest in maintaining a presence (such as this forum)

You lost me here. Where can one find this mature communication?

You mean your Discord server where bullies run rampant? Where you mock and ban even paying supporters for asking legitimate questions or making suggestions?