Helm chart changes discussion.

[ilithanos]

With the name and organization changes we are already at a point where the helm chart is no longer a direct upgrade from the old chart without creating side effects.

I think it might be an idea to go through and get the rest of the naming, tooling around it etc updated before we create a real release of it to avoid users having to go through the migration risks again shortly after.

But what to change and why besides the CRD location and container images is something I think needs a discussion before we just move ahead and do it.

One thing I do suggest is getting the chart name changed to tofu-controller as well, that will at the same time signal to users that something had changed.

It might even make sense to look into value names, if there are any inconsistencies around those etc.

When all the stuff is ready for release the next hard step begins: writing a detailed official migration guide to avoid users getting their terraform managed resources destroyed by the chart deleting the crds and redeploying them, as that could lead to data loss for the users.

Any opinions or thoughts on this?

[chanwit]

One thing I do suggest is getting the chart name changed to tofu-controller as well

Agreed

[chanwit]

It might even make sense to look into value names, if there are any inconsistencies around those etc.

When all the stuff is ready for release the next hard step begins: writing a detailed official migration guide to avoid users getting their terraform managed resources destroyed by the chart deleting the crds and redeploying them, as that could lead to data loss for the users.

No objects on any of these. Let's wait to see other opinions.

If we agreed, we would continue by converting them into actionable items?

ping @yitsushi wdyt?

[yitsushi]

I agree with that... but at the same time, I don't know when we can cut a new RC, we have a lot of features packed on main that's not part of the latest RC, therefore we have zero feedback if they are even working as expected, we only have the "it has test and we tested it" badge.

I'm totally fine with waiting on all the cleanup, and I can see it's a pain to migrate, but if there are people want to experiment (install in new environments) with new features, right now they don't really have any options as it would require to check main then

1. build a controller image and publish somewhere (internal or external OCI repo)
2. build a runner image and publish somewhere (internal or external OCI repo)
3. build a branch planner image and publish somewhere (internal or external OCI repo)
4. update helm values, build the helm chart, and push it somewhere

After that, they can install it on a non-local cluster.

[ilithanos]

That is definitely a problem @yitsushi, I agree.

But is there another option?

Getting feedback on the new features in main

For fixing the no easy way to play around with latest changes to main, my first thought is setting up a pipeline for building bleeding edge images and releasing them to the registry with a specific tag.

That would at least allow testing by changing the image versions deployed.

This could be achieved by changing the pipelines from pushing to the latest tag when building on all PR's to use a pr-12-sha tag on PR builds and trigger a build when merged to master getting tagged with the something like nightly and latest for a bleeding edge build that people can play with.

The issue with migrating currently

The big issue with migrating isn't as much the configuration steps. But due to how the old chart was constructed migrating to tofu-controller from tf-controller without following a specific procedure can result in deployed cloud resources getting destroyed.

It's not a huge problem for users that doesn't have destroyResoucesOnDeletion enabled, as the resources will stick around. But if state files are stored in cluster they will end up being lost too, since the migration will delete the CRDs and redeploy them.

This is the thing that kind of worries me regarding doing the helm chart in stages.

I'm not sure we need all cleanup done before releasing a new RC, but at least ensuring that future upgrades won't risk destroying deployed resources first kind of seems needed based on the reactions in slack and the issue that moving the CRDs within the chart fixed.

(And just to avoid misunderstandings, I'm not saying 'we' as if I'm a maintainer here, but 'we' as a community in general)

[ilithanos]

I'll sit down later to see if I can draft up some issues/tasks for this, so that we have a plan for how this should be done.

I'll draft them within this discussion thread first, and then convert them into issues when we all agree on the plan.