Skip to content
This repository has been archived by the owner on Jun 29, 2022. It is now read-only.

Add a new CI pipeline to test FLUO and Rook Ceph #1000

Closed
surajssd opened this issue Sep 23, 2020 · 9 comments
Closed

Add a new CI pipeline to test FLUO and Rook Ceph #1000

surajssd opened this issue Sep 23, 2020 · 9 comments
Assignees
Labels
area/ci Items related to CI area/testing area/updates Items related to updates size/l Issues which likely require many work days (but not weeks)
Milestone

Comments

@surajssd
Copy link
Member

No description provided.

@surajssd surajssd added area/updates Items related to updates area/ci Items related to CI area/testing labels Sep 23, 2020
@invidian
Copy link
Member

How is it different from #959 and #894? Also why one aggregate issue instead of two?

@surajssd
Copy link
Member Author

This to put them together in one pipeline. Those are individual things to do that will be triggered by the pipeline created in this issue.

So both of them are blocked on this.

@surajssd surajssd added the proposed/next-sprint Issues proposed for next sprint label Sep 23, 2020
@invidian
Copy link
Member

Why do they need to be in a separate pipeline then?

@surajssd
Copy link
Member Author

Because in a normal pipeline this can disturb other tests as we have seen previously. I had a chat with @iaguis about this offline IIRC.

@invidian
Copy link
Member

Hm, we already have a concept of disruptive tests in our e2e framework, do we need another one? Disruptive tests should run serially and they can do whatever they want with the cluster, as long they revert the changes back to the original state before they finish (so next test can run too).

IMO we could have one node for testing OpenEBS and 3 nodes for Ceph (if that's really needed, can't be stretch it a bit and run Ceph on just one for testing?). I'm afraid about that number of pipelines and dividing test code between them will create hard to maintain solution. I prefer to have one, slower pipeline which does all (as pipelines are already slow), rather than multiple, which only does part of the job.

@surajssd
Copy link
Member Author

How do you propose to test FLUO?

@invidian
Copy link
Member

How do you propose to test FLUO?

  • To begin the test, all nodes should have updates disabled in FLUO via label/annotation.
  • Then we could either run a cluster with Flatcar version specified (latest - 1) OR we could re-configure node to use higher version channel (stable -> beta or stable -> alpha).
  • In test code, we trigger an update (either via pod or via removal of label) and we wait until node gets drained, updated and rebooted.
  • Test should verify, that node came back and have different Flatcar version now.

@surajssd surajssd added this to the v0.5.0 milestone Sep 23, 2020
@surajssd surajssd added size/l Issues which likely require many work days (but not weeks) and removed proposed/next-sprint Issues proposed for next sprint labels Sep 23, 2020
@surajssd surajssd self-assigned this Oct 12, 2020
@surajssd surajssd modified the milestones: v0.5.0, v0.6.0 Oct 12, 2020
@surajssd
Copy link
Member Author

@iaguis
Copy link
Contributor

iaguis commented Nov 4, 2020

Can this be closed now that #1142 is merged?

@iaguis iaguis closed this as completed Nov 4, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/ci Items related to CI area/testing area/updates Items related to updates size/l Issues which likely require many work days (but not weeks)
Projects
None yet
Development

No branches or pull requests

3 participants