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

Drop OpenShift 3 support #1550

Closed
astefanutti opened this issue Jun 22, 2020 · 6 comments
Closed

Drop OpenShift 3 support #1550

astefanutti opened this issue Jun 22, 2020 · 6 comments
Assignees
Labels
area/continuous integration Related to CI and automated testing status/never-stale

Comments

@astefanutti
Copy link
Member

astefanutti commented Jun 22, 2020

Camel K CRDs currently uses apiextensions.k8s.io/v1beta1, which will be removed in a future release of Kubernetes (currently planned for 1.22): kubernetes/kubernetes#82022.

Work has been done in #1514 to migrate to apiextensions.k8s.io/v1. However, OpenShift 3.11 is based on Kubernetes 1.11 that does not serve apiextensions.k8s.io/v1. It implies it won't be possible to support both Kubernetes 1.22+ and OpenShift 3.11 generally.

OpenShift 3.11 is still used in our CI, with GitHub Actions and Travis, to run integration tests on OpenShift. Before dropping support for OpenShift 3, a solution has to be found to migrate CI to run integration tests on OpenShift 4.

CRC seems the best replacement candidate to setup OpenShift 4. Unfortunately, it relies on virtualisation, and GitHub Actions Linux hosted runners do not support nested virtualisation. Yet it is supported by the macOS runner with actions/runner-images#433. After some experiments, it seems not really stable as I faced crc-org/crc#1331. It may be due to the 7GB memory limit set for the GitHub actions runners, which may be a blocker anyway whenever we'll have to run more demanding workload.

It is unfortunate DIND support has be removed from OpenShift, which is what's used to run vanilla K8s on our CI: openshift/origin#23177.

For reference, the GH Actions workflow used to experiment with CRC:

name: CRC

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

jobs:
  crc:
    runs-on: macos-latest

    steps:
      - name: Info
        run: |
          df -h
          sysctl hw.memsize
          sw_vers

      - name: Checkout code
        uses: actions/checkout@v2

      - name: Setup CRC
        env:
          PULL_SECRET: ${{ secrets.PULL_SECRET }}
        run: |
          curl -L https://mirror.openshift.com/pub/openshift-v4/clients/crc/1.11.0/crc-macos-amd64.tar.xz -o crc-macos-amd64.tar.xz
          tar xf crc-macos-amd64.tar.xz
          rm crc-macos-amd64.tar.xz
          cd crc-macos-1.11.0-amd64/

          ./crc setup

          #./crc config set memory 8192
          ./crc config view

          echo $PULL_SECRET > pull.secret
          ./crc start -p pull.secret --log-level debug
          eval $(./crc oc-env)
@tsedmik
Copy link

tsedmik commented Feb 9, 2021

Please, take a look at https://github.com/openshift/release/tree/master/ci-operator. This CI should provide you with OCP 4.x environment for testing in upstream.

@tadayosi
Copy link
Member

Should we give this a try?
https://github.com/redhat-et/microshift

@astefanutti
Copy link
Member Author

Should we give this a try?
https://github.com/redhat-et/microshift

Yes, it seems worth trying. It's not very clear what are the differences / limitations compared to vanilla OCP, but the documentation mentions testing as a possible use case:

We believe these properties should also make Microshift a great tool for other use cases such as Kubernetes applications development on resource-constrained systems, scale testing, and provisioning of lightweight Kubernetes control planes.

@tadayosi
Copy link
Member

Let me work on it a bit. Another potential option worth evaluating is:
https://github.com/code-ready/snc

@github-actions
Copy link
Contributor

This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!

@tadayosi
Copy link
Member

tadayosi commented Jul 7, 2022

Superceded by #3421

@tadayosi tadayosi closed this as completed Jul 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/continuous integration Related to CI and automated testing status/never-stale
Projects
None yet
Development

No branches or pull requests

3 participants