Hello folks,
The infra team has not been sending regular updates recently because we’ve been caught up in several different pieces of work that were running into longer than 2 week sprint cycles. This is a summary of what we’ve done so far since the last update.
* The bugzilla updates are done with a python script now and there’s now a patch to handle a patch being abandoned and restored. It’s pending a merge and deploy after the holiday season.
* Smoke jobs for python linting and shell linting.
* Smoke jobs for 32-bit builds.
The big piece that the infra team has been spending time has been working on is identifying the best way to write end to end testing for GCS (Gluster for Container Storage). We started with the assumption that we want to use a test framework that as far as possible sticks closely to the upstream kubernetes and Openshift Origin tests. We have had a 3-pronged approach to this over the last two months.
1. We want to use machines we have access to right now to verify that the deployment scripts that we publish works as we intend for it to work. To this end, we created a job on Centos CI that consumes the deployment exactly like we recommend anyone run the scripts in the gcs repository[1]. We’re running into a couple of failures and Mrugesh is working on identifying and fixing them. We hope to have this complete in the first week of January.
2. We want to use the upstream end to end test framework that consumes ginkgo and gomega. The framework already exists to consume the kubectl client to talk to a kubernetes cluster. We’ve just had a conversation with the upstream Storage-SIG developers yesterday that has pointed us in the right direction. We’re very close to having a first test. When the first test in the end to end framework comes about, we’ll hook it up to the test run we have in (1). Deepshikha and I are actively working on making this happen. We plan to have a proof of concept in the second week of January and write documentation and demos for the GCS team.
3. We want to do some testing that actively tries to break a production sized cluster and look for how our stack handles failures. There’s a longer plan on how to do this, but this work is currently on hold until we get the first two pieces running. This is also blocked on us having access to infrastructure where we can make this happen. Mrugesh will lead this activity once the other blockers are removed.
Once we have the first proof of concept test written, we will hand over writing the tests to the GCS development team and the infra team will then move to working on building out the infrastructure for running these new tests. We will continue to work in close collaboration with the Kubernetes Storage SIG and the OKD Infrastructure teams to prevent us from duplicating work.
[1]: https://ci.centos.org/view/Gluster/job/gluster_anteater_gcs/
--
The infra team has not been sending regular updates recently because we’ve been caught up in several different pieces of work that were running into longer than 2 week sprint cycles. This is a summary of what we’ve done so far since the last update.
* The bugzilla updates are done with a python script now and there’s now a patch to handle a patch being abandoned and restored. It’s pending a merge and deploy after the holiday season.
* Smoke jobs for python linting and shell linting.
* Smoke jobs for 32-bit builds.
The big piece that the infra team has been spending time has been working on is identifying the best way to write end to end testing for GCS (Gluster for Container Storage). We started with the assumption that we want to use a test framework that as far as possible sticks closely to the upstream kubernetes and Openshift Origin tests. We have had a 3-pronged approach to this over the last two months.
1. We want to use machines we have access to right now to verify that the deployment scripts that we publish works as we intend for it to work. To this end, we created a job on Centos CI that consumes the deployment exactly like we recommend anyone run the scripts in the gcs repository[1]. We’re running into a couple of failures and Mrugesh is working on identifying and fixing them. We hope to have this complete in the first week of January.
2. We want to use the upstream end to end test framework that consumes ginkgo and gomega. The framework already exists to consume the kubectl client to talk to a kubernetes cluster. We’ve just had a conversation with the upstream Storage-SIG developers yesterday that has pointed us in the right direction. We’re very close to having a first test. When the first test in the end to end framework comes about, we’ll hook it up to the test run we have in (1). Deepshikha and I are actively working on making this happen. We plan to have a proof of concept in the second week of January and write documentation and demos for the GCS team.
3. We want to do some testing that actively tries to break a production sized cluster and look for how our stack handles failures. There’s a longer plan on how to do this, but this work is currently on hold until we get the first two pieces running. This is also blocked on us having access to infrastructure where we can make this happen. Mrugesh will lead this activity once the other blockers are removed.
Once we have the first proof of concept test written, we will hand over writing the tests to the GCS development team and the infra team will then move to working on building out the infrastructure for running these new tests. We will continue to work in close collaboration with the Kubernetes Storage SIG and the OKD Infrastructure teams to prevent us from duplicating work.
[1]: https://ci.centos.org/view/Gluster/job/gluster_anteater_gcs/
--
nigelb
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx https://lists.gluster.org/mailman/listinfo/gluster-devel
