It’s still used in Travis. I think Dave was suggesting kube for Jenkins.
-r > On Aug 23, 2020, at 9:34 PM, Dominic Kim <style9...@gmail.com> wrote: > > @David > Thank you for sharing. > I will look into it. > >> I don't think investing in ansible-based distributed deploy/testing is > worth the effort. > > IMHO, if we would not drop the ansible-based deployment, I think it would > still be worth it to guarantee it's working via CI. > > -dom > > 2020년 8월 21일 (금) 오후 11:24, David P Grove <gro...@us.ibm.com>님이 작성: > >> >> Hi, >> >> To answer the question about Jenkins documentation: General Apache >> Jenkins info: https://cwiki.apache.org/confluence/display/INFRA/Jenkins >> >> Our "normal" Jenkins jobs that (a) build/publish the website on >> commits and (b) push nightly controller/invoker images to dockerhub for use >> by our CI process does not need OpenWhisk-specific VMs. They are running >> on vanilla "website" and "ubuntu" Jenkins worker nodes shared by all >> projects and provided by Infra. The shared nodes are adequate for our >> these two jobs. >> >> We had dedicated nodes that were functional for a short period (a >> few >> months) to do multi-node testing of PRs for the core repo. This was >> triggered by a Jenkins job, but the real work was done via an ansible >> deploy/test, so it probably wasn't obvious at the Jenkins level that the >> machines were being utilized. This was not a very reliable setup. >> Vincent did document the setup in our cwiki (eg >> https://cwiki.apache.org/confluence/display/OPENWHISK/How+to+maintain+the >> +Jenkins+pipeline+for+OpenWhisk), but I would not suggest attempting to >> duplicate this on the new ci-builds.a.o Jenkins service. >> >> My opinion is that we don't really need dedicated Jenkins nodes. >> If >> we wanted dedicated VMs for testing, we should instead be configuring them >> as a Kubernetes cluster and doing multi-node testing via a Kubernetes >> deployment of OpenWhisk onto those nodes. I don't think investing in >> ansible-based distributed deploy/testing is worth the effort. This could >> be driven by a Jenkins job (which should be able to run on a non-dedicated >> node as it is doing very little actual work), but it does not need the >> Kubernetes cluster to actually be made from Jenkins worker nodes. >> >> --dave >>