Chapter 1. Getting started with Dev Spaces If your organization is already running a OpenShift Dev Spaces instance, you can get started as a new user by learning how to start a new workspace, manage your workspaces, and authenticate yourself to a Git server from a workspace: Section 1.1, "Starting a workspace from a Git repository URL" Section 1.1.1, "Optional parameters for the URLs for starting a new workspace" Section 1.2, "Starting a workspace from a raw devfile URL" Section 1.3, "Basic actions you can perform on a workspace" Section 1.4, "Authenticating to a Git server from a workspace" Section 1.5, "Using the fuse-overlayfs storage driver for Podman and Buildah" 1.1. Starting a workspace from a Git repository URL With OpenShift Dev Spaces, you can use a URL in your browser to start a new workspace that contains a clone of a Git repository. This way, you can clone a Git repository that is hosted on GitHub, GitLab, Bitbucket or Microsoft Azure DevOps server instances. Tip You can also use the Git Repository URL field on the Create Workspace page of your OpenShift Dev Spaces dashboard to enter the URL of a Git repository to start a new workspace. Important If you use an SSH URL to start a new workspace, you must propagate the SSH key. See Configuring DevWorkspaces to use SSH keys for Git operations for more information. If the SSH URL points to a private repository, you must apply an access token to be able to fetch the devfile.yaml content. You can do this either by accepting an SCM authentication page or following a Personal Access Token procedure. Important Configure personal access token to access private repositories. See Section 6.1.2, "Using a Git-provider access token" . Prerequisites Your organization has a running instance of OpenShift Dev Spaces. You know the FQDN URL of your organization's OpenShift Dev Spaces instance: https:// <openshift_dev_spaces_fqdn> . Optional: You have authentication to the Git server configured. Your Git repository maintainer keeps the devfile.yaml or .devfile.yaml file in the root directory of the Git repository. (For alternative file names and file paths, see Section 1.1.1, "Optional parameters for the URLs for starting a new workspace" .) Tip You can also start a new workspace by supplying the URL of a Git repository that contains no devfile. Doing so results in a workspace with Universal Developer Image and with Microsoft Visual Studio Code - Open Source as the workspace IDE. Procedure To start a new workspace with a clone of a Git repository: Optional: Visit your OpenShift Dev Spaces dashboard pages to authenticate to your organization's instance of OpenShift Dev Spaces. Visit the URL to start a new workspace using the basic syntax: Tip You can extend this URL with optional parameters: 1 See Section 1.1.1, "Optional parameters for the URLs for starting a new workspace" . Tip You can use Git+SSH URLs to start a new workspace. See Configuring DevWorkspaces to use SSH keys for Git operations Example 1.1. A URL for starting a new workspace https:// <openshift_dev_spaces_fqdn> #https://github.com/che-samples/cpp-hello-world https:// <openshift_dev_spaces_fqdn> #git@github.com:che-samples/cpp-hello-world.git Example 1.2. The URL syntax for starting a new workspace with a clone of a GitHub instance repository https:// <openshift_dev_spaces_fqdn> #https:// <github_host> / <user_or_org> / <repository> starts a new workspace with a clone of the default branch. https:// <openshift_dev_spaces_fqdn> #https:// <github_host> / <user_or_org> / <repository> /tree/ <branch_name> starts a new workspace with a clone of the specified branch. https:// <openshift_dev_spaces_fqdn> #https:// <github_host> / <user_or_org> / <repository> /pull/ <pull_request_id> starts a new workspace with a clone of the branch of the pull request. https:// <openshift_dev_spaces_fqdn> #git@ <github_host> : <user_or_org> / <repository> .git starts a new workspace from Git+SSH URL. Example 1.3. The URL syntax for starting a new workspace with a clone of a GitLab instance repository https:// <openshift_dev_spaces_fqdn> #https:// <gitlab_host> / <user_or_org> / <repository> starts a new workspace with a clone of the default branch. https:// <openshift_dev_spaces_fqdn> #https:// <gitlab_host> / <user_or_org> / <repository> /-/tree/ <branch_name> starts a new workspace with a clone of the specified branch. https:// <openshift_dev_spaces_fqdn> #git@ <gitlab_host> : <user_or_org> / <repository> .git starts a new workspace from Git+SSH URL. Example 1.4. The URL syntax for starting a new workspace with a clone of a BitBucket Server repository https:// <openshift_dev_spaces_fqdn> #https:// <bb_host> /scm/ <project-key> / <repository> .git starts a new workspace with a clone of the default branch. https:// <openshift_dev_spaces_fqdn> #https:// <bb_host> /users/ <user_slug> /repos/ <repository> / starts a new workspace with a clone of the default branch, if a repository was created under the user profile. https:// <openshift_dev_spaces_fqdn> #https:// <bb_host> /users/ <user-slug> /repos/ <repository> /browse?at=refs%2Fheads%2F <branch-name> starts a new workspace with a clone of the specified branch. https:// <openshift_dev_spaces_fqdn> #git@ <bb_host> : <user_slug> / <repository> .git starts a new workspace from Git+SSH URL. Example 1.5. The URL syntax for starting a new workspace with a clone of a Microsoft Azure DevOps Git repository https:// <openshift_dev_spaces_fqdn> #https:// <organization> @dev.azure.com/ <organization> / <project> /_git/ <repository> starts a new workspace with a clone of the default branch. https:// <openshift_dev_spaces_fqdn> #https:// <organization> @dev.azure.com/ <organization> / <project> /_git/ <repository> ?version=GB <branch> starts a new workspace with a clone of the specific branch. https:// <openshift_dev_spaces_fqdn> #git@ssh.dev.azure.com:v3/ <organization> / <project> / <repository> starts a new workspace from Git+SSH URL. After you enter the URL to start a new workspace in a browser tab, the workspace starting page appears. When the new workspace is ready, the workspace IDE loads in the browser tab. A clone of the Git repository is present in the filesystem of the new workspace. The workspace has a unique URL: https:// <openshift_dev_spaces_fqdn> / <user_name> / <unique_url> . Additional resources Section 1.1.1, "Optional parameters for the URLs for starting a new workspace" Section 1.3, "Basic actions you can perform on a workspace" Section 6.1.2, "Using a Git-provider access token" Section 6.2.1, "Mounting Git configuration" Configuring DevWorkspaces to use SSH keys for Git operations 1.1.1. Optional parameters for the URLs for starting a new workspace When you start a new workspace, OpenShift Dev Spaces configures the workspace according to the instructions in the devfile. When you use a URL to start a new workspace, you can append optional parameters to the URL that further configure the workspace. You can use these parameters to specify a workspace IDE, start duplicate workspaces, and specify a devfile file name or path. Section 1.1.1.1, "URL parameter concatenation" Section 1.1.1.2, "URL parameter for the IDE" Section 1.1.1.3, "URL parameter for the IDE image" Section 1.1.1.4, "URL parameter for starting duplicate workspaces" Section 1.1.1.5, "URL parameter for the devfile file name" Section 1.1.1.6, "URL parameter for the devfile file path" Section 1.1.1.7, "URL parameter for the workspace storage" Section 1.1.1.8, "URL parameter for additional remotes" Section 1.1.1.9, "URL parameter for a container image" 1.1.1.1. URL parameter concatenation The URL for starting a new workspace supports concatenation of multiple optional URL parameters by using & with the following URL syntax: https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ? <url_parameter_1> & <url_parameter_2> & <url_parameter_3> Example 1.6. A URL for starting a new workspace with the URL of a Git repository and optional URL parameters The complete URL for the browser: https:// <openshift_dev_spaces_fqdn> #https://github.com/che-samples/cpp-hello-world?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml Explanation of the parts of the URL: 1 OpenShift Dev Spaces URL. 2 The URL of the Git repository to be cloned into the new workspace. 3 The concatenated optional URL parameters. 1.1.1.2. URL parameter for the IDE You can use the che-editor= URL parameter to specify a supported IDE when starting a workspace. Tip Use the che-editor= parameter when you cannot add or edit a /.che/che-editor.yaml file in the source-code Git repository to be cloned for workspaces. Note The che-editor= parameter overrides the /.che/che-editor.yaml file. This parameter accepts two types of values: che-editor= <editor_key> Table 1.1. The URL parameter <editor_key> values for supported IDEs IDE Status <editor_key> value Note Microsoft Visual Studio Code - Open Source Available che-incubator/che-code/latest che-incubator/che-code/insiders latest is the default IDE that loads in a new workspace when the URL parameter or che-editor.yaml is not used. insiders is the development version. JetBrains IntelliJ IDEA Community Edition Deprecated che-incubator/che-idea/latest che-incubator/che-idea/ latest is the stable version. is the development version. JetBrains IntelliJ IDEA Ultimate Edition (over JetBrains Gateway) Technology Preview che-incubator/che-idea-server/latest che-incubator/che-idea-server/ latest is the stable version. is the development version. che-editor= <url_to_a_file> 1 URL to a file with devfile content . Tip The URL must point to the raw file content. To use this parameter with a che-editor.yaml file, copy the file with another name or path, and remove the line with inline from the file. The che-editors.yaml file features the devfiles of all supported IDEs. 1.1.1.3. URL parameter for the IDE image You can use the editor-image parameter to set the custom IDE image for the workspace. Important If the Git repository contains /.che/che-editor.yaml file, the custom editor will be overridden with the new IDE image. If there is no /.che/che-editor.yaml file in the Git repository, the default editor will be overridden with the new IDE image. If you want to override the supported IDE and change the target editor image, you can use both parameters together: che-editor and editor-image URL parameters. The URL parameter to override the IDE image is editor-image= : Example: https:// <openshift_dev_spaces_fqdn> #https://github.com/eclipse-che/che-docs?editor-image=quay.io/che-incubator/che-code: or https:// <openshift_dev_spaces_fqdn> #https://github.com/eclipse-che/che-docs?che-editor=che-incubator/che-code/latest&editor-image=quay.io/che-incubator/che-code: 1.1.1.4. URL parameter for starting duplicate workspaces Visiting a URL for starting a new workspace results in a new workspace according to the devfile and with a clone of the linked Git repository. In some situations, you might need to have multiple workspaces that are duplicates in terms of the devfile and the linked Git repository. You can do this by visiting the same URL for starting a new workspace with a URL parameter. The URL parameter for starting a duplicate workspace is new : Note If you currently have a workspace that you started using a URL, then visiting the URL again without the new URL parameter results in an error message. 1.1.1.5. URL parameter for the devfile file name When you visit a URL for starting a new workspace, OpenShift Dev Spaces searches the linked Git repository for a devfile with the file name .devfile.yaml or devfile.yaml . The devfile in the linked Git repository must follow this file-naming convention. In some situations, you might need to specify a different, unconventional file name for the devfile. The URL parameter for specifying an unconventional file name of the devfile is df= <filename> .yaml : 1 <filename> .yaml is an unconventional file name of the devfile in the linked Git repository. Tip The df= <filename> .yaml parameter also has a long version: devfilePath= <filename> .yaml . 1.1.1.6. URL parameter for the devfile file path When you visit a URL for starting a new workspace, OpenShift Dev Spaces searches the root directory of the linked Git repository for a devfile with the file name .devfile.yaml or devfile.yaml . The file path of the devfile in the linked Git repository must follow this path convention. In some situations, you might need to specify a different, unconventional file path for the devfile in the linked Git repository. The URL parameter for specifying an unconventional file path of the devfile is devfilePath= <relative_file_path> : 1 <relative_file_path> is an unconventional file path of the devfile in the linked Git repository. 1.1.1.7. URL parameter for the workspace storage If the URL for starting a new workspace does not contain a URL parameter specifying the storage type, the new workspace is created in ephemeral or persistent storage, whichever is defined as the default storage type in the CheCluster Custom Resource. The URL parameter for specifying a storage type for a workspace is storageType= <storage_type> : 1 Possible <storage_type> values: ephemeral per-user (persistent) per-workspace (persistent) Tip With the ephemeral or per-workspace storage type, you can run multiple workspaces concurrently, which is not possible with the default per-user storage type. Additional resources Chapter 7, Requesting persistent storage for workspaces 1.1.1.8. URL parameter for additional remotes When you visit a URL for starting a new workspace, OpenShift Dev Spaces configures the origin remote to be the Git repository that you specified with # after the FQDN URL of your organization's OpenShift Dev Spaces instance. The URL parameter for cloning and configuring additional remotes for the workspace is remotes= : Important If you do not enter the name origin for any of the additional remotes, the remote from <git_repository_url> will be cloned and named origin by default, and its expected branch will be checked out automatically. If you enter the name origin for one of the additional remotes, its default branch will be checked out automatically, but the remote from <git_repository_url> will NOT be cloned for the workspace. 1.1.1.9. URL parameter for a container image You can use the image parameter to use a custom reference to a container image in the following scenarios: The Git repository contains no devfile, and you want to start a new workspace with the custom image. The Git repository contains a devfile, and you want to override the first container image listed in the components section of the devfile. The URL parameter for the path to the container image is image= : Example https:// <openshift_dev_spaces_fqdn> #https://github.com/eclipse-che/che-docs?image=quay.io/devfile/universal-developer-image:ubi8-latest 1.2. Starting a workspace from a raw devfile URL With OpenShift Dev Spaces, you can open a devfile URL in your browser to start a new workspace. Tip You can use the Git Repo URL field on the Create Workspace page of your OpenShift Dev Spaces dashboard to enter the URL of a devfile to start a new workspace. Important To initiate a clone of the Git repository in the filesystem of a new workspace, the devfile must contain project info. See https://devfile.io/docs/2.2.0/adding-projects . Prerequisites Your organization has a running instance of OpenShift Dev Spaces. You know the FQDN URL of your organization's OpenShift Dev Spaces instance: https:// <openshift_dev_spaces_fqdn> . Procedure To start a new workspace from a devfile URL: Optional: Visit your OpenShift Dev Spaces dashboard pages to authenticate to your organization's instance of OpenShift Dev Spaces. Visit the URL to start a new workspace from a public repository using the basic syntax: You can pass your personal access token to the URL to access a devfile from private repositories: 1 Your personal access token that you generated on the Git provider's website. This works for GitHub, GitLab, Bitbucket, Microsoft Azure, and other providers that support Personal Access Token. Important Automated Git credential injection does not work in this case. To configure the Git credentials, use the configure personal access token guide. Tip You can extend this URL with optional parameters: 1 See Section 1.1.1, "Optional parameters for the URLs for starting a new workspace" . Example 1.7. A URL for starting a new workspace from a public repository https:// <openshift_dev_spaces_fqdn> #https://raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml Example 1.8. A URL for starting a new workspace from a private repository https:// <openshift_dev_spaces_fqdn> #https:// <token> @raw.githubusercontent.com/che-samples/cpp-hello-world/main/devfile.yaml Verification After you enter the URL to start a new workspace in a browser tab, the workspace starting page appears. When the new workspace is ready, the workspace IDE loads in the browser tab. The workspace has a unique URL: https:// <openshift_dev_spaces_fqdn> / <user_name> / <unique_url> . Additional resources Section 1.1.1, "Optional parameters for the URLs for starting a new workspace" Section 1.3, "Basic actions you can perform on a workspace" Section 6.1.2, "Using a Git-provider access token" Section 6.2.1, "Mounting Git configuration" Configuring DevWorkspaces to use SSH keys for Git operations 1.3. Basic actions you can perform on a workspace You manage your workspaces and verify their current states in the Workspaces page ( https:// <openshift_dev_spaces_fqdn> /dashboard/#/workspaces ) of your OpenShift Dev Spaces dashboard. After you start a new workspace, you can perform the following actions on it in the Workspaces page: Table 1.2. Basic actions you can perform on a workspace Action GUI steps in the Workspaces page Reopen a running workspace Click Open . Restart a running workspace Go to ... > Restart Workspace . Stop a running workspace Go to ... > Stop Workspace . Start a stopped workspace Click Open . Delete a workspace Go to ... > Delete Workspace . 1.4. Authenticating to a Git server from a workspace In a workspace, you can run Git commands that require user authentication like cloning a remote private Git repository or pushing to a remote public or private Git repository. User authentication to a Git server from a workspace is configured by the administrator or, in some cases, by the individual user: Your administrator sets up an OAuth application on GitHub, GitLab, Bitbucket, or Microsoft Azure Repos for your organization's Red Hat OpenShift Dev Spaces instance. As a workaround, some users create and apply their own Kubernetes Secrets for their personal Git-provider access tokens or configure SSH keys for Git operations . Additional resources Administration Guide: Configuring OAuth for Git providers User Guide: Using a Git-provider access token Configuring DevWorkspaces to use SSH keys for Git operations 1.5. Using the fuse-overlayfs storage driver for Podman and Buildah By default, newly created workspaces that do not specify a devfile will use the Universal Developer Image (UDI). The UDI contains common development tools and dependencies commonly used by developers. Podman and Buildah are included in the UDI, allowing developers to build and push container images from their workspace. By default, Podman and Buildah in the UDI are configured to use the vfs storage driver. For more efficient image management, use the fuse-overlayfs storage driver which supports copy-on-write in rootless environments. You must meet the following requirements to use fuse-overlayfs in a workspace: For OpenShift versions older than 4.15, the administrator has enabled /dev/fuse access on the cluster by following https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.19/html-single/administration_guide/index#administration-guide:configuring-fuse . The workspace has the necessary annotations for using the /dev/fuse device. See Section 1.5.1, "Accessing /dev/fuse" . The storage.conf file in the workspace container has been configured to use fuse-overlayfs. See Section 1.5.2, "Enabling fuse-overlayfs with a ConfigMap" . Additional resources Universal Developer Image 1.5.1. Accessing /dev/fuse You must have access to /dev/fuse to use fuse-overlayfs. This section describes how to make /dev/fuse accessible to workspace containers. Prerequisites For OpenShift versions older than 4.15, the administrator has enabled access to /dev/fuse by following https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.19/html-single/administration_guide/index#administration-guide:configuring-fuse . Determine a workspace to use fuse-overlayfs with. Procedure Use the pod-overrides attribute to add the required annotations defined in https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.19/html-single/administration_guide/index#administration-guide:configuring-fuse to the workspace. The pod-overrides attribute allows merging certain fields in the workspace pod's spec . For OpenShift versions older than 4.15: For OpenShift version 4.15 and later: Verification steps Start the workspace and verify that /dev/fuse is available in the workspace container. After completing this procedure, follow the steps in Section 1.5.2, "Enabling fuse-overlayfs with a ConfigMap" to use fuse-overlayfs for Podman. 1.5.2. Enabling fuse-overlayfs with a ConfigMap You can define the storage driver for Podman and Buildah in the ~/.config/containers/storage.conf file. Here are the default contents of the /home/user/.config/containers/storage.conf file in the UDI container: storage.conf To use fuse-overlayfs, storage.conf can be set to the following: storage.conf 1 The absolute path to the fuse-overlayfs binary. The /usr/bin/fuse-overlayfs path is the default for the UDI. You can do this manually after starting a workspace. Another option is to build a new image based on the UDI with changes to storage.conf and use the new image for workspaces. Otherwise, you can update the /home/user/.config/containers/storage.conf for all workspaces in your project by creating a ConfigMap that mounts the updated file. See Section 6.2, "Mounting ConfigMaps" . Prerequisites For OpenShift versions older than 4.15, the administrator has enabled access to /dev/fuse by following https://access.redhat.com/documentation/en-us/red_hat_openshift_dev_spaces/3.19/html-single/administration_guide/index#administration-guide:configuring-fuse . A workspace with the required annotations are set by following Section 1.5.1, "Accessing /dev/fuse" Note Since ConfigMaps mounted by following this guide mounts the ConfigMap's data to all workspaces, following this procedure will set the storage driver to fuse-overlayfs for all workspaces. Ensure that your workspaces contain the required annotations to use fuse-overlayfs by following Section 1.5.1, "Accessing /dev/fuse" . Procedure Apply a ConfigMap that mounts a /home/user/.config/containers/storage.conf file in your project. kind: ConfigMap apiVersion: v1 metadata: name: fuse-overlay labels: controller.devfile.io/mount-to-devworkspace: 'true' controller.devfile.io/watch-configmap: 'true' annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /home/user/.config/containers data: storage.conf: | [storage] driver = "overlay" [storage.options.overlay] mount_program="/usr/bin/fuse-overlayfs" Warning Creating this ConfigMap will cause all of your running workspaces to restart. Verification steps Start the workspace containing the required annotations and verify that the storage driver is overlay . Example output: Note The following error might occur for existing workspaces: In this case, delete the libpod local files as mentioned in the error message. 1.6. Running containers with kubedock Kubedock is a minimal container engine implementation that gives you a Podman-/docker-like experience inside a OpenShift Dev Spaces workspace. Kubedock is especially useful when dealing with ad-hoc, ephemeral, and testing containers, such as in the use cases listed below: Executing application tests which rely on Testcontainers framework. Using Quarkus Dev Services . Running a container stored in remote container registry, for local development purposes Important The image you want to use with kubedock must be compliant with Openshift Container Platform guidelines . Otherwise, running the image with kubedock will result in a failure even if the same image runs locally without issues. Enabling kubedock After enabling the kubedock environment variable, kubedock will run the following podman commands: podman run podman ps podman exec podman cp podman logs podman inspect podman kill podman rm podman wait podman stop podman start Other commands such as podman build are started by the local Podman. Important Using podman commands with kubedock has following limitations The podman build -t <image> . && podman run <image> command will fail. Use podman build -t <image> . && podman push <image> && podman run <image> instead. The podman generate kube command is not supported. --env option causes the podman run command to fail. Prerequisites An image compliant with Openshift Container Platform guidelines . Process Add KUBEDOCK_ENABLED=true environment variable to the devfile. (OPTIONAL) Use the KUBEDOCK_PARAM variable to specify additional kubedock parameters. The list of variables is available here . Alternatively, you can use the following command to view the available options: Example schemaVersion: 2.2.0 metadata: name: kubedock-sample-devfile components: - name: tools container: image: quay.io/devfile/universal-developer-image:latest memoryLimit: 8Gi memoryRequest: 1Gi cpuLimit: "2" cpuRequest: 200m env: - name: KUBEDOCK_PARAMS value: "--reverse-proxy --kubeconfig /home/user/.kube/config --initimage quay.io/agiertli/kubedock:0.13.0" - name: USE_JAVA17 value: "true" - value: /home/jboss/.m2 name: MAVEN_CONFIG - value: -Xmx4G -Xss128M -XX:MetaspaceSize=1G -XX:MaxMetaspaceSize=2G name: MAVEN_OPTS - name: KUBEDOCK_ENABLED value: 'true' - name: DOCKER_HOST value: 'tcp://127.0.0.1:2475' - name: TESTCONTAINERS_RYUK_DISABLED value: 'true' - name: TESTCONTAINERS_CHECKS_DISABLE value: 'true' endpoints: - exposure: none name: kubedock protocol: tcp targetPort: 2475 - exposure: public name: http-booster protocol: http targetPort: 8080 attributes: discoverable: true urlRewriteSupported: true - exposure: internal name: debug protocol: http targetPort: 5005 volumeMounts: - name: m2 path: /home/user/.m2 - name: m2 volume: size: 10G Important You must configure the Podman or docker API to point to kubedock setting CONTAINER_HOST=tcp://127.0.0.1:2475 or DOCKER_HOST=tcp://127.0.0.1:2475 when running containers. At the same time, you must configure Podman to point to local Podman when building the container.

Commands:
https:// <openshift_dev_spaces_fqdn> # <git_repository_url>
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ? <optional_parameters> 1
https:// <openshift_dev_spaces_fqdn> 1 #https://github.com/che-samples/cpp-hello-world 2 ?new&che-editor=che-incubator/intellij-community/latest&devfilePath=tests/testdevfile.yaml 3
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?che-editor= <editor_key>
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?che-editor= <url_to_a_file> 1
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?editor-image= <container_registry/image_name:image_tag>
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?new
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?df= <filename> .yaml 1
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?devfilePath= <relative_file_path> 1
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?storageType= <storage_type> 1
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?remotes={{ <name_1> , <url_1> },{ <name_2> , <url_2> },{ <name_3> , <url_3> },...}
https:// <openshift_dev_spaces_fqdn> # <git_repository_url> ?image= <container_image_url>
https:// <openshift_dev_spaces_fqdn> # <devfile_url>
https:// <openshift_dev_spaces_fqdn> # https:// <token> @ <host> / <path_to_devfile> 1
https:// <openshift_dev_spaces_fqdn> # <devfile_url> ? <optional_parameters> 1
oc patch devworkspace <DevWorkspace_name> --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse","io.openshift.podman-fuse":""}}}}}}}' --type=merge
oc patch devworkspace <DevWorkspace_name> --patch '{"spec":{"template":{"attributes":{"pod-overrides":{"metadata":{"annotations":{"io.kubernetes.cri-o.Devices":"/dev/fuse"}}}}}}}' --type=merge
stat /dev/fuse
[storage] driver = "vfs"
[storage] driver = "overlay" [storage.options.overlay] mount_program="/usr/bin/fuse-overlayfs" 1
kind: ConfigMap apiVersion: v1 metadata: name: fuse-overlay labels: controller.devfile.io/mount-to-devworkspace: 'true' controller.devfile.io/watch-configmap: 'true' annotations: controller.devfile.io/mount-as: subpath controller.devfile.io/mount-path: /home/user/.config/containers data: storage.conf: | [storage] driver = "overlay" [storage.options.overlay] mount_program="/usr/bin/fuse-overlayfs"
podman info | grep overlay
graphDriverName: overlay overlay.mount_program: Executable: /usr/bin/fuse-overlayfs Package: fuse-overlayfs-1.12-1.module+el8.9.0+20326+387084d0.x86_64 fuse-overlayfs: version 1.12 Backing Filesystem: overlayfs
ERRO[0000] User-selected graph driver "overlay" overwritten by graph driver "vfs" from database - delete libpod local files ("/home/user/.local/share/containers/storage") to resolve. May prevent use of images created by other tools
kubedock server --help
schemaVersion: 2.2.0 metadata: name: kubedock-sample-devfile components: - name: tools container: image: quay.io/devfile/universal-developer-image:latest memoryLimit: 8Gi memoryRequest: 1Gi cpuLimit: "2" cpuRequest: 200m env: - name: KUBEDOCK_PARAMS value: "--reverse-proxy --kubeconfig /home/user/.kube/config --initimage quay.io/agiertli/kubedock:0.13.0" - name: USE_JAVA17 value: "true" - value: /home/jboss/.m2 name: MAVEN_CONFIG - value: -Xmx4G -Xss128M -XX:MetaspaceSize=1G -XX:MaxMetaspaceSize=2G name: MAVEN_OPTS - name: KUBEDOCK_ENABLED value: 'true' - name: DOCKER_HOST value: 'tcp://127.0.0.1:2475' - name: TESTCONTAINERS_RYUK_DISABLED value: 'true' - name: TESTCONTAINERS_CHECKS_DISABLE value: 'true' endpoints: - exposure: none name: kubedock protocol: tcp targetPort: 2475 - exposure: public name: http-booster protocol: http targetPort: 8080 attributes: discoverable: true urlRewriteSupported: true - exposure: internal name: debug protocol: http targetPort: 5005 volumeMounts: - name: m2 path: /home/user/.m2 - name: m2 volume: size: 10G