Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add DisableInitContainer field in the CR #1880

Merged
merged 4 commits into from
Aug 14, 2024

Conversation

dkwon17
Copy link
Contributor

@dkwon17 dkwon17 commented Aug 12, 2024

What does this PR do?

This PR adds the DisableInitContainer field in the CheCluster CR.

This field sets the config.workspaces.persistUserHome.disableInitContainer field in the Che-owned DWOC.

Screenshot/screencast of this PR

image

What issues does this PR fix or reference?

How to test this PR?

  1. Prepare a patch file:
cat > /tmp/cr-patch.yaml <<EOF
apiVersion: org.eclipse.che/v2
kind: CheCluster
spec:
  devEnvironments:
    persistUserHome:
      enabled: true
      disableInitContainer: true
EOF
  1. Deploy the operator:
## Openshift
./build/scripts/olm/test-catalog-from-sources.sh --cr-patch-yaml /tmp/cr-patch.yaml

## Minikube
./build/scripts/minikube-tests/test-operator-from-sources.sh --cr-patch-yaml /tmp/cr-patch.yaml
  1. Verify that the devworkspace-config DWOC in the eclipse-che namespace has the following fields:
config:
  workspace:
    persistUserHome:
      enabled: true
      disableInitContainer: true
  1. In the Che CR, spec.devEnvironments.persistUserHome.disableInitContainer to false. Verify that the DWOC has the following fields:
config:
  workspace:
    persistUserHome:
      enabled: true
      disableInitContainer: false
  1. In the Che CR, remove the spec.devEnvironments.persistUserHome.disableInitContainer field. Verify that the disableInitContainer has been removed from the DWOC:
config:
  workspace:
    persistUserHome:
      enabled: true
      disableInitContainer: true

PR Checklist

As the author of this Pull Request I made sure that:

Reviewers

Reviewers, please comment how you tested the PR when approving it.

Signed-off-by: dkwon17 <dakwon@redhat.com>
Signed-off-by: dkwon17 <dakwon@redhat.com>
Copy link
Contributor

@AObuchow AObuchow left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small documentation comments but overall LGTM

api/v2/checluster_types.go Outdated Show resolved Hide resolved
// When the `/home/user` directory is persisted, the init container is used to initialize the directory before
// the workspace starts. If set to true, the init container will not be created.
// This field is not used if the `workspace.persistUserHome.enabled` field is set to false.
// Enabled by default.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused, I thought this was disabled by default? Do we have a docs bug in DWO?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, the value is set to false by default, but the init container itself enabled by default

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay that makes more sense. Maybe we should write "Set to false by default" or "The init container is enabled by default"? I'm okay with leaving it as is, but it almost reads as "DisableInitContainer is enabled by default = the init contianer is disabled by default"

Signed-off-by: dkwon17 <dakwon@redhat.com>
@openshift-ci openshift-ci bot removed the lgtm label Aug 12, 2024
@tolusha
Copy link
Contributor

tolusha commented Aug 13, 2024

/test v14-devworkspace-happy-path

Copy link
Member

@ibuziuk ibuziuk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dkwon17 could you clarify what is the motivation and use-case behind this feature?
from the first glance DisableInitContainer looks like internal impl details rather than smth. to be exposed for configuration

@tolusha
Copy link
Contributor

tolusha commented Aug 13, 2024

/retest

@dkwon17
Copy link
Contributor Author

dkwon17 commented Aug 13, 2024

@ibuziuk The new field allows persistenthome setup from the tooling container's entrypoint instead of the initcontainer, since disabling the initcontainer means that persistent home can now only be set up by the tooling container (which was the beheaviour before this PR https://github.com/devfile/devworkspace-operator/pull/1251/files#diff-f1f3498fd50bbc235d4d09f5f5485a91f5a4a5cfeb20b127c96fc849a30ba56b).

// the workspace starts. If set to true, the init container will not be created.
// This field is not used if the `devEnvironments.persistUserHome.enabled` field is set to false.
// Enabled by default.
DisableInitContainer *bool `json:"disableInitContainer,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dkwon17 maybe we should clarify more when this flag should be used?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about:

	// Determines whether the init container that initializes the persistent home directory should be disabled.
	// When the `/home/user` directory is persisted, the init container is used to initialize the directory before
	// the workspace starts. If set to true, the init container will not be created.
	// Disabling the init container allows persistent home to be prepared from the first workspace container's entrypoint script.
	// This field is not used if the `workspace.persistUserHome.enabled` field is set to false.
	// The init container is enabled by default.

WDYT @ibuziuk @AObuchow ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me, though I'd modify the way "first workspace container" is said:
// Disabling the init container allows persistent home to be prepared from the first workspace container's entrypoint script.

I'm not sure what's the "standard" way of calling the main/tooling container? Do we say "tooling container" or "first container component"?

Some alternatives:

  • Disabling the init container allows home persistence to be initialized by the entrypoint present in the workspace's first container component.
  • Disabling the init container leaves the responsibility of initializing home persistence to the workspace's tooling container component, through an entrypoint, for example.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, in my latest commit I went with:

// Determines whether the init container that initializes the persistent home directory should be disabled.
// When the `/home/user` directory is persisted, the init container is used to initialize the directory before
// the workspace starts. If set to true, the init container will not be created.
// Disabling the init container allows home persistence to be initialized by the entrypoint present in the workspace's first container component.
// This field is not used if the `devEnvironments.persistUserHome.enabled` field is set to false.
// The init container is enabled by default.
DisableInitContainer *bool `json:"disableInitContainer,omitempty"`

Signed-off-by: dkwon17 <dakwon@redhat.com>
@openshift-ci openshift-ci bot removed the lgtm label Aug 13, 2024
@dkwon17
Copy link
Contributor Author

dkwon17 commented Aug 13, 2024

I've made the changes to the description, could you please take a look again @ibuziuk

@openshift-ci openshift-ci bot added the lgtm label Aug 13, 2024
Copy link

openshift-ci bot commented Aug 13, 2024

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: AObuchow, dkwon17, tolusha

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link

openshift-ci bot commented Aug 13, 2024

@dkwon17: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/v14-che-behind-proxy 11ddb35 link true /test v14-che-behind-proxy

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.16 :: get-sources-rhpkg-container-build_3.16/55: FAILURE

devspaces-operator-bundle : 3.16 :: Failed in 63401097 : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.17 :: get-sources-rhpkg-container-build_3.x/7459: FAILURE

devspaces-operator-bundle : 3.x :: Failed in 63402297 : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.17 :: get-sources-rhpkg-container-build_3.x/7460: FAILURE

devspaces-operator-bundle : 3.x :: Failed in 63402455 : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.16 :: get-sources-rhpkg-container-build_3.16/56: FAILURE

devspaces-operator-bundle : 3.16 :: Failed in : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.17 :: get-sources-rhpkg-container-build_3.x/7461: FAILURE

devspaces-operator-bundle : 3.x :: Failed in 63405390 : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.16 :: get-sources-rhpkg-container-build_3.16/57: FAILURE

devspaces-operator-bundle : 3.16 :: Failed in 63407640 : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.17 :: get-sources-rhpkg-container-build_3.x/7462: FAILURE

devspaces-operator-bundle : 3.x :: Failed in 63408548 : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

@devstudio-release
Copy link

Build 3.16 :: get-sources-rhpkg-container-build_3.16/58: FAILURE

devspaces-operator-bundle : 3.16 :: Failed in 63409047 : BREW:BUILD/STATUS:UNKNOWN
FAILURE:; copied to quay

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Unplanned
Development

Successfully merging this pull request may close these issues.

6 participants