Uploaded image for project: 'Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces) '
  1. Red Hat OpenShift Dev Spaces (formerly CodeReady Workspaces)
  2. CRW-3897

Use `dsc` to update DevSpaces from `latest` to `next` build

    XMLWordPrintable

Details

    • False
    • None
    • False
    • 0
    • 0% 0%

    Description

      As of CRW-3877, we can deploy DS 3.latest or 3.next to an OCP cluster.

      But what doesn't is that we can't use dsc to then do an update from 3.4 / latest -> 3.5 / next, to test upgrade paths between releases:

      $➔ /tmp/dsc-350/dsc/bin/dsc server:deploy --olm-channel=next
› Current Kubernetes context: 'openshift-operators/api-ci-ln-ng4x4gb-72292-origin-ci-int-gce-dev-rhcloud-com:6443/kube:admin'
  ✔ Verify Kubernetes API...[1.24]
  ✔ OpenShift version: [4.11]
 ›   Warning: Red Hat OpenShift Dev Spaces has been already deployed. Use server:start command to start a stopped Red Hat OpenShift Dev Spaces instance.

$➔ /tmp/dsc-350/dsc/bin/dsc server:update 
› Current Kubernetes context: 'openshift-operators/api-ci-ln-ng4x4gb-72292-origin-ci-int-gce-dev-rhcloud-com:6443/kube:admin'
  ✔ Verify Kubernetes API...[1.24]
  ❯ Red Hat OpenShift Dev Spaces operator pre-update check
    ✖ Check InstallPlan approval strategy...[Automatic]
      → Use 'dsc server:update' command only with Manual InstallPlan approval strategy.
    Error: Command server:update failed with the error: Use 'dsc server:update' command only with Manual InstallPlan approval strategy. See details: /home/nboldt/.cache/dsc/error.log.

      How hard would it be to add the ability to deploy a new catalog source from another IIB, then trigger the update process?

      Current workaround could be to run

      ./installCatalogSourceFromIIB.sh --install-operator devspaces --channel fast --quay --iib quay.io/devspaces/iib:next-v4.11-x86_64

      and then watch the subscription update happen automatically from the new catalog source?

      I'm thinking one of these commands would be useful:

      • dsc server:deploy --olm-channel=next (even if 3.4 is already deployed, start over and deploy 3.5 on top to allow the upgrade to happen)
      • dsc server:update --olm-channel=next (apply just the new IIB/catalog source/subscription and let OLM handle the update from the `fast` channel)

      This should also work for installing 3.4 from RHEC `stable` channel, and being able to update to quay `fast` channel, for either `latest` or `next` tags.

      Attachments

        1. screenshot-1.png
          screenshot-1.png
          284 kB
        2. screenshot-2.png
          screenshot-2.png
          14 kB
        3. screenshot-3.png
          screenshot-3.png
          123 kB
        4. screenshot-4.png
          screenshot-4.png
          13 kB

        Issue Links

          clones

          Feature Request - Feature requests from customers and/or users CRW-3877 Installation of pre-release versions of {prod-short} from the `fast` channel (using dsc)

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          incorporates

          Bug - A problem that impairs or prevents the functions of the product. CRW-4370 "Subscription devspaces-subscription not found" error when run "dsc server:update" command against DS 3.5.0 installed from OperatorHub

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Resolved
          is blocked by

          Bug - A problem that impairs or prevents the functions of the product. CRW-4191 Failed to deploy DSC from next/latest channels

          • Critical - To be worked on immediately following BLOCKER issues.
          • Closed
          is depended on by

          Task - Represents a small unit of work that is not end-user facing. CRW-4132 Use Release Candidates bits on the Developer Sandbox staging cluster

          • Major - To be worked after higher priority work items are addressed. When the severity is high and the effort to change it is low to moderate, this term is chosen. Issues in this category likely have an existing workaround but implementation or execution may be non-trivial.
          • Closed
          links to

          GitHub che-incubator/chectl#2659: feat: Allow to switch between channels

          GitHub che-incubator/chectl#2661: fix: Prevent handging while waiting kubernetes resources

          GitHub che-incubator/chectl#2663: fix: Delete custom catalog sources even without app.kubernetes.io/par…

          Activity

            People

              abazko Anatolii Bazko
              abazko Anatolii Bazko
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: