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

Adding e2e tests for cluster provisioning when OSM is used #105

Open
moadqassem opened this issue Dec 13, 2021 · 3 comments
Open

Adding e2e tests for cluster provisioning when OSM is used #105

moadqassem opened this issue Dec 13, 2021 · 3 comments
Labels
priority/normal Not that urgent, but is important sig/cluster-management Denotes a PR or issue as being assigned to SIG Cluster Management.

Comments

@moadqassem
Copy link
Member

moadqassem commented Dec 13, 2021

User Story
In order to make sure that OSM is working as expected, we need to make sure that we test it thoroughly with every PR merge. That's why we need a proper infrastructure where we can build, run, integrate and test osm, to make sure everything is working as expected.

Acceptance Criteria

  • Add the proper scripts to handle the deployment of OSM
  • Make sure that OSM and OSM webhook are running and tested as well
  • Make sure that all OSM dependencies are in place
  • Run the e2e testing suite successfully with each master merge
  • Introduce e2e tests for all cloud provider that we support by OSM
  • Introduce e2e tests for all operating systems that we support by OSM
  • Introduce e2e tests for all kubernetes versions that we support by OSM
@moadqassem moadqassem self-assigned this Dec 23, 2021
@moadqassem moadqassem added priority/normal Not that urgent, but is important sig/cluster-management Denotes a PR or issue as being assigned to SIG Cluster Management. Epic labels Feb 18, 2022
@ahmedwaleedmalik
Copy link
Member

With kubermatic/machine-controller#1369 in machine-controller, we switched the E2E tests to use OSM as default instead of the legacy user data. Hence, all the PRs in machine-controller are being tested against OSM as well.

Instead of reinventing the wheel, we can simply reuse those tests for OSM. The only significant change that we need for this is to build and use OSM image against the PR.

Prow job could like something like this:

  - name: pull-osm-e2e-aws
    decorate: true
    clone_uri: "ssh://git@github.com/kubermatic/operating-system-manager.git"
    extra_refs:
      - org: kubermatic
        repo: machine-controller
        base_ref: main
        clone_uri: 'ssh://git@github.com/kubermatic/machine-controller.git'
    labels:
      preset-aws: "true"
      preset-e2e-ssh: "true"
      preset-rhel: "true"
      preset-goproxy: "true"
      preset-kind-volume-mounts: "true"
      preset-docker-mirror: "true"
      preset-kubeconfig-ci: "true"
    spec:
      containers:
        - image: quay.io/kubermatic/build:go-1.20-node-18-kind-0.18-7
          command:
            # Build OSM container image and then call `./hack/ci/run-e2e-tests.sh` from machine-controller.
            - "./hack/ci/run-e2e-tests.sh"
          args:
            - "TestAWSProvisioningE2E"
          env:
            - name: CLOUD_PROVIDER
              value: aws
          securityContext:
            privileged: true
          resources:
            requests:
              memory: 7Gi
              cpu: 2
            limits:
              memory: 7Gi

NOTE: We should ideally take kubermatic/machine-controller#1626 in account as well while working on this ticket.

@ahmedwaleedmalik
Copy link
Member

ahmedwaleedmalik commented Aug 15, 2023

@moadqassem WDYT? I think this should significantly reduce the effort required to integrate and maintain E2E tests for OSM. We don't really need to implement anything per OS, cloud provider basis, etc. since MC already is taking care of all of those combinations.

@moadqassem
Copy link
Member Author

@moadqassem WDYT? I think this should significantly reduce the effort required to integrate and maintain E2E tests for OSM. We don't really need to implement anything per OS, cloud provider basis, etc. since MC already is taking care of all of those combinations.

Yes that sounds good for me as well. I will close the epic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/normal Not that urgent, but is important sig/cluster-management Denotes a PR or issue as being assigned to SIG Cluster Management.
Projects
None yet
Development

No branches or pull requests

2 participants