GeezerVison is showing github.com — Create CI · Issue #2 · feast-dev/feast
Activitywoop commented on Dec 14, 2018 What do we want to run within CI? Are we just running tests and building binaries and docker images? pradithya commented on Dec 14, 2018 CollaboratorAuthor More actions Yes, that's pretty much it for starter. Should also includes publishing the artifacts. woop commented on Jan 1, 2019 I'm setting up Terraform configuration for the infrastructure, and Prow for monitoring GitHub. I think using Argo for running the tests would probably be the easiest long term, since that is what Kubeflow is using.
Before we get there we also need test scripts that can be executed from the stages in CI. woop commented on Jan 2, 2019 @tims @pradithya Can we discuss the range of tests that we require for Feast in the short term?
We will have 1 primary test cluster within our kf-feast GCP project. That cluster will be used to orchestrate all testing, and can even run some limited testing itself (unit tests and builds).
Other than that, we need to make a decision in terms of how we want to lay out the rest of the test systems. As I see it, we have three options:
- Have a dedicated and reusable setup to run tests in the GCP project. This means we will have a single Kubernetes cluster that is long running, and also any other infra that is required like Kafka, Pub/Sub, buckets, BQ. Only 1 run of tests can be executed at a time, and probably sequentially. We can tear down and clear all the resources after each run, and install them again at the start of new runs.
- We dynamically provision new resources for each run. Meaning we will probably have a startup container that creates a new Feast deployment and runs all tests. This would allow us to run tests in parallel, but this would consume have a longer startup time. It would also require some thinking in terms of how we want to isolate each of these systems. For example, isolating BQ datasets.
- We can also take a hybrid approach. One in which we reuse the same GCP resources for parallel runs, but we isolate the runs within namespaces inside the Kubernetes cluster. This would not be 100% deterministic though, since one run can influence the performance of another.
#22 woop commented on Jan 4, 2019 Closing this after base CI has been set up.
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|