This is the tool we're using for tracking issues for OST, so its the right place, if needed we can have a trello card pointing to this ticket.

0. Lago. I don't think that the fact Vagrant was used for POC KubeVirt alone is a major advantage to re-do all the work we've done to make OST run with Lago,
Moving to Vagrant will mean investing a lot of efforts and resources ( which we don't have, looking at the Lago+OST headcount ATM ) into making something we already have working for little value IMO and will delay significantly the work to support KubeVirt.
We can consider it once we'll have a full time maintainer for Lago/OST.

1. Once we support Ansible as deploy scripts in OST, which shouldn't be hard after the recent merges to Lago, we can just use the existing Kubenetes playbooks, not sure how using Vagrant makes it simpler.

Ansible for engine - not sure how/what we'll need, but provided us with POD definitions, I'm guessing once you have Kubenetes its just a matter of running / deploying the engine container? ( so according to the request we should have available engine & vdsm in containers, otherwise I didn't understand the request )

- too many items there, I think. We should probably document it in KubeVirt's trello and not here.
0. Do we use Lago as is, or vagrant? Unclear to me, and I do see a nice advantage for the community using vagrant.
1. Ansible installing K8S - makes sense to me. This is quite integrated into vagrant and is easy to do (though requires Ansible on Host L0) in Lago. Do we have Ansible to install Engine? Quite possibly from QCI - we should utilize that - but it's not within a Container - Engine is not yet containerized (production-ready, at least)
3. Good point about Add Host. Donno yet...
4. ACK
5. ACK.

Just to emphasis the scope and requirements, let me re-iterate on what we agreed on the email:

A new OST suite will be created which will run the same tests run today in basic suite, the difference will be:

1. Replace deploy scripts for engine + storage with Ansible playbook which will install Kubernetes
2. The Ansible playbook will also need to deploy engine + vdsm as containers in PODS once Kubernetes will be running
3. Not sure how 'add host' should work - will VDSM come ready in a container and already connect to the engine or we'll still need to run 'add host' command to add it? or an alternative 'add host' command.
4. Kubernetes will be running on VMs created by Lago
5. We will consider to use Atomic as OS for the VMs, but CentOS should work as well as starting point.

Please confirm I'm not talking nonsense and we can continue to move towards this goal

We need support for Ansible Playbooks before we start implementing this suite.

- I strongly agree. I think lago has just gained good support for providing the Ansible hosts list (via https://github.com/lago-project/lago/pull/428 ).
The provides the basic infrastructure needed from the host (L0) to do things via Ansible.
I'd argue though that we need to use Ansible from L1, not from L0. So I rather we copy the relevant Ansible, scripts, what not, and execute it from L1.

I'm not sure I'd use Atomic right away, though I agree it's a goal.

I think the way to go is with Atomic, it seems to have quite good support for getting Kubernetes running on top of it. I'm hoping we can reach the point where we boot up an atomic image with some cloud-init settings that make it boot Kubernetes.

But there is a question if people are supposed to boot Atomic on bare-metal. If not we need to find out what the process for running Kubernetes (Openshift?) on bare metal is going to be and imitate that.

Since this will require a whole new suite with different deploy scripts ( but still using the same tests ),
I wonder if we should add support to use Ansible scripts instead of bash scripts and utilize existing Ansible playbooks to install Kubernetes [1].
We will still add a new suite, but at least we'll use existing code and not write new bash scripts for it.

Also, Shouldn't we use CentOS Atomic images rather than base CentOS?

- WDYT?

[1] https://galaxy.ansible.com/grycap/kubernetes/