che icon indicating copy to clipboard operation
che copied to clipboard

docs improvement: Managing workspaces $HOME directory persistence

Open deerskindoll opened this issue 1 year ago • 4 comments

Is your task related to a problem? Please describe

support comment:

One of my customer reported this. I had to try multiple options , finally got know from Andrew Obuchowicz that it should be "enabled" and got it to work.

persistUserHome: enabled: true

Suggestions:

  1. It should be consistent with other config tags to use "enable": imagePuller: enable: false spec: {} metrics: enable: true
  2. The documentation should be updated with helpful info so that its easy to follow and less time consuming: Table 3.1. Development environment configuration options of https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.13/html/administration_guide/configuring-devspaces#checluster-custom-resource-fields-reference-checluster-custom-resource-devEnvironments-settings

Describe the solution you'd like

potential docs improvement candidate

Describe alternatives you've considered

No response

Additional context

https://issues.redhat.com/browse/CRW-4659?filter=-1

deerskindoll avatar Jul 22 '24 10:07 deerskindoll

@dkwon17 @AObuchow please review

ibuziuk avatar Jul 22 '24 19:07 ibuziuk

Suggestions:

  1. It should be consistent with other config tags to use "enable": imagePuller: enable: false spec: {} metrics: enable: true

Unfortunately, changing the Che Cluster CR field from spec.devEnvironments.persistUserHome.enabled to spec.devEnvironments.persistUserHome.enable is not very straightforward. We cannot change a Che Cluster CR field easily as it will invalidate existing instances of the CR.

I believe the two options available to us are:

  1. Add a new spec.devEnvironments.persistUserHome.enable field and keep the old field (which should then be marked in documentation as deprecated). This seems like it'd be a bit confusing for users IMO.
  2. Introduce a v3 of the Che Cluster CRD so that we can implement logic that converts from v2 -> v3 of the Che Cluster CRD like we already have for v1 -> v2. This could eventually be done, but this is a large task IMO and should be done only if there are enough problems with the v2 Che Cluster CRD.
  1. The documentation should be updated with helpful info so that its easy to follow and less time consuming: Table 3.1. Development environment configuration options of https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.13/html/administration_guide/configuring-devspaces#checluster-custom-resource-fields-reference-checluster-custom-resource-devEnvironments-settings

This is the most feasible and immediate solution IMO. Looking at the docs, there is a table for the Che Cluster CRD spec.devEnvironments but no table for the fields in spec.devEnvironments.persistUserHome. Adding an extra table to inform users that the field is called "enabled" instead of "enable" would help here.

AObuchow avatar Jul 22 '24 19:07 AObuchow

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

che-bot avatar Jan 18 '25 00:01 che-bot

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

che-bot avatar Nov 12 '25 14:11 che-bot