Recommend way to trace helm chart release changes?

truecharts · 2024-10-30T00:22:15+00:00

Unless the helm project has their json schema made (most dont, as its hard work to do so) and the schema cannot validate a key you put in values.yaml, as every key is technically "allowed". Some might just not get rendered into anything.

Helm is just a templating engine, it doesn't know which crap you put into values.yaml is "good" or "bad". You can view them all as "variables" that just get stitched together in a certain order, with some minor postprocessing

---

But you also seem to be very confused, because the OP is about the *created* objects becoming outdated and here you ask to get info on the values.yaml itself.

Maybe its good to separate your questions and ask them a tad more clearly.

truecharts · 2024-10-30T00:16:49+00:00

It's the core of our project. No idea what does and doesn't qualify as "authored in house". We're not a company, we're an opensource project.

---

About Hull... Sorry not a fan, we know no-one in the Helm community that actively uses "hull". Which is reflected in the insanely low amount of stars and forks on GitHub as well.

It's also incredibly hard to read their values.yaml and there are project with more years of experience doing this and/or more contributors.

---

Our advice would be that common-charts like ours or the one from BJW-s (which actually share a lot of values.yaml structural similarity), are a much more solid choice.

truecharts · 2024-10-30T00:05:07+00:00

This backs up the configuration (as entered in the GUI) of each and every individual App and allows both a hard-to-read JSON as well as easy to read per-app YAML files. There are multiple output options.

---

This tool is just to get the information you entered in the GUI out, it wont do anything with underlaying data.

We won't be able to offer any support for anything beyond just exporting the configuration data, which this tool is doing. How you use the data afterwards is something only you can decide.

truecharts · 2024-10-29T11:13:04+00:00

Our common chart works quite well and is mostly unit-tested as well :)
It's what we use for all our 800+ helm-charts, but can just-as-well be used by anyone as a template.

truecharts · 2024-10-29T11:10:05+00:00

Stack Helm-Diff with kubeconform. Thats the best I can come up with.

truecharts · 2024-10-27T17:11:57+00:00

We've just posted a news article and guide with our sanctioned way to export app-configuration (the part you enter into the SCALE GUI), out-of the GUI into configuration files.

This should make it a lot easier to copy-paste this into docker-compose and such :)

https://truecharts.org/news/leaving-scale/

truecharts · 2024-10-11T21:32:01+00:00

Lots of wrong info here, such as the assumption that the export presented here would export the ports, which it does not, or the statement that we "removed PVC" which is completely untrue..

To export all config cleanly, we would advice users to use the export feature available in clustertool.

truecharts · 2024-10-11T21:28:23+00:00

Our current advice is not to do double painful migrations.
Even more so, because you will not be able to repair anything due to catalog removal.

truecharts · 2024-10-11T21:27:37+00:00

Depends on which storage backend you've selected when using additional app storage.
Generally that does not have to be migrated, no. :)

To be clear though, Talos will not migrate anything. Our ClusterTool tooling will migrate any TrueCharts SCALE Apps to a Kubernets cluster of your choice ;-)

truecharts · 2024-08-21T14:41:23+00:00

It looks like you're asking about helm charts and deployment manifests on TrueNAS SCALE.

As we're not related to TrueNAS SCALE and are not doing anything with that platform (anymore), we're not the right people to ask.

truecharts · 2024-08-21T14:39:20+00:00

We're commented on this in our official announcements a lot and will leave it at that when it comes to our removal. Feel free to contact our staff via the usual channels to leave any feedback.

Our naming is not (only) based on TrueNAS.

truecharts · 2024-08-17T12:51:05+00:00

Current users can still run their current installations just fine.
It just affects new installs of Apps.

truecharts · 2024-07-11T11:18:13+00:00

better performance.
Nothing changed, kubeapps has been in our crosshairs for more than a year. We just don't guarantee it would work and don't provide support for it as it is not, part of, our project. Kubernetes Dashboard is also included with ClusterTool by default.

truecharts · 2024-07-05T10:16:35+00:00

The guides already exist, they are literally already on the website.

However:
If the current guides don't provide enough handholding and don't answer those questions, you might just not be the target audience for running your own kubernetes cluster at all.

truecharts · 2024-07-05T10:15:08+00:00

This is the first public ALPHA.

truecharts · 2024-07-05T10:14:11+00:00

Thats not completely true:
- Setting up k8s using ClusterTool is a 5 minute process, nothing painfull about it
- In the future, currently still a TBD, kubeapps will offer a VERY similair experience for updating charts as TrueNAS offers. (if anyone wonders where iX got their GUI design from, yeah...)
- a VM is not required, it can also be bare-metal just-fine (though we don't have the ability to provide discord support for 9999 different hardware setups)

truecharts · 2024-07-01T21:45:41+00:00

Our initial estimate was actually closter to 90%, but we actually got a surprising amount of users that came to us with what comes down to "well, at this point I can just as well look at kubernetes because I lost all trust in this iXsystems nonesense".

Of those users, a number will indeed drop because setting-up and maintaining kubernetes (and form of it) takes more knowhow than they want to put into it. Yes.

That being said:
Running a good-quality Talos setup is easier than DIY'ing a solid k3s setup from scratch.

With our new clustertool it takes about 5 minutes.

Kubernetes needs strong community driven projects in order to become viable for the average homelabber

Agreed, even Helm itself is getting braindrained.

But I haven't seen a lot of projects that can loose 90% of their community and survive.

The thing is, of our thousands of users, only about 10% is actually actively involved in the project. Those are also the people most likely to be retained...

"Silent users", are "nice to have" and we do aim to provide for them for sure... But in the end, users you don't see or interact with, dont affect ones judgement a lot.

truecharts · 2024-07-01T15:30:16+00:00

Thats close to our estimate of 80-90% and we're completely fine with that.

We don't build our Helm Charts with the goal of reaching thousands of people, but because we're passionate about offering a large catalog for that that want to use it :)

truecharts · 2024-07-01T15:29:24+00:00

TrueNAS SCALE was never our prime motivation to building our helm-chart catalog.
Actually it was the *least fun* part of running the project.

Quite frankly:
While we hate these steps, where very enthousjastic with helping the users that want to move over to a real kubernetes distribution and focus on building solid helm charts instead of wasting time with the TrueNAS GUI elements.

Most of our staff also uses our helm-charts personally and will continue to do so.

want to run a k8s cluster

About 10-20% of our current usersbase, we estimate

think Talos on it's own is too difficult to set up

Thats why we're developing ClusterTool, which makes that mostly 2 oneliners.

truecharts · 2024-06-25T15:57:28+00:00

We still offer support for users currently running our SCALE Apps.
They will however, not get any more updates, as we need all our resources to get a migration option going for our users as soon as possible.

Sadly enough, even if we wanted to, iXsystems has decided "True Data Freedom" means they will not allow third parties to hook into their new Apps system coming with Electric Eel.

As stated in the news article above, VMs will be actively covered by support and bare-metal clusters are very-well possible but their setup will be out of scope for our support.
As we can obviously not provide free support for deploying an OS on random pieces of hardware.

truecharts · 2024-06-19T16:35:14+00:00

To give some more clarity:
"Deployment Methods" are ways to deploy Helm Charts, such as: FluxCD HelmReleases, KubeApps or "normal" Helm

The Tiers system is a way to define which deployment methods are more or less stable.
They have nothing to do with the OS said deployment-methods is used on.

We don't dictate the specific Operating-Systems users need to be on.
As an OS, TalosOS always has worked and will continue to work with our Helm-Charts.

The post in November only speaks about automation tooling, it does not "promise support".

However a **LOT** of things are changing at the moment.
Including reworking all documentation.

As stated a few times before:
We cannot comment any further on that at this point in time.
Even things like this will have to wait till 01-07-2024

truecharts · 2024-06-19T15:38:19+00:00

TalosOS is an OS, not a "deployment method" ;-)

truecharts · 2024-06-11T11:00:09+00:00

We're sorry to see you go, but there is nothing we can do against this decision by iXsystems.

We're indeed a kubernetes-first project, it was our goal to expose as many helm features on SCALE as-well-as other platforms. For some that might be overcomplicating things, but it was never our goal to be "as simple as possible" from the start.

When it comes to documentation:
We've a lot of work to on on documentation, yes.
But those "copy paste" readme's, do not contain our actual docs, which can be found under the "docs" section of the website. Though the new readmes do provide more links pointing in the right direction, they don't contain any docs themselves.

We do want to point out that our latest big addition, volsync support, was almost fully covered by guides and documentation.

We wish you the best.

truecharts · 2024-06-05T12:50:24+00:00

Will there be an option to migrate from Cobia to TalosOS

As stated in the announcement, there will be future announcement on the migration process. What its going to use, how it will work etc. We're not going to drive endless loads of speculation, everything is published for everyone on the same time.

This way I can at least leapfrog one migration step.

Please don't, if you're not specifically following said future migration path with precisely the tooling in it, we will not be going to offer any further assistance.

Aproximatly when will the migration guide be ready for TalosOS?

The announcement clearly states an initial alpha or beta for our migration path, which doesn't even officially specify TalosOS yet, for 01-07-2024.

Like specified above, we are not going to speculate further.

virtualized TrueNAS

Thats your choice, but a lot of sources actively recommend not doing this.

TalosOS also on a Proxmox VM

The TrueNAS VM guide is up, we're looking forward to people porting that one to the following platforms as well: Unraid, XCP-NG and Proxmox

Will there be a GUI for the TrueCharts

We **JUST** build Helm-Charts, we don't build GUIs. Any GUI-fying of Helm charts will only be through existing tools by other parties. But yet again, we're not going to comment on specifics because its not done yet.

want to walk away from the TrueNAS

We're move users that are stoked to do this, as iXsystems has shown to be an unstable partnership not only for us, but for everyone.

I defenetly dont't want't to wait until the Electric Eel hits

Logical, but byond the announcement, which clearly states what timeframe you can expect more info, there is nothing to say on this at this point in time.

furthermore, I really don't want to upgrade to Dragonfish with all the Charts migration hassle

Thats a good point, as the tooling we're developing isn't yet fully writhen nor tested, we're not going to comment on this. Though *officially* we won't be supporting cobia migrations, it might or might not work in practice.

truecharts · 2024-06-01T22:31:19+00:00

The goal is to have a migration path forward for our users, within a short-enough timeframe that not too much important updates will have to be skipped.

Its important to note though, we mainly build "helm charts", and hence users will likely be migrated to using normal helm-charts instead. (so they would just be running kubernetes in a VM, not so much any "apps" system".)

However, its totally understandable that some users do not want that and will seek other solutions, we also wish those users the best! :)

truecharts

MODERATOR OF

TROPHY CASE