Installer e2e test

[ratanasovvmw]

This test executes the following workflow:

• download upstream bundle contents
• start local repo
• build a BYOH bundle and upload it to the local repo
• spin up a Ubuntu 20.04 VM and inside it run
  • cli install with local repo
  • kubeadm init phase preflight
  • cli uninstall

Upon success return 0.

[jamiemonserrate]

@ratanasovvmw - This e2e test seems to test the installer in isolation - so its not really an e2e test then :)

I think this should be integrated within our existing e2e suite. More specifically, when we run the PR-Blocking test, the installer should be triggered as part of that workflow.

So what that means is

• That test would need to build the bundle and host it (So these bash lines move into the golang test itself - probably e2e_suite_test.go)
• We would need to start Vagrant in our e2e_suite_test.go
• The e2e tests should then spin up all containers inside this Vagrant VM. So that would mean modifying the e2e_docker_helper.go to do this.
• We would then stop invoking --skip-installation - as we do here

That is a proper e2e test in my mind. Thoughts?

[ratanasovvmw]

@jamiemonserrate
My idea was exactly to make an installer e2e test :) (currently the test is under agent/installer/e2e) as an overview how it may look like on the inside. Whether it'll go in like this, or be integrated in the project e2e tests (not in scope of this PR) is another thing. In general, I think there should be both installer e2e and project e2e so failures are localized faster.

To spin up a container in Vagrant (initially I was going to do so) you need containerd etc and configure it in the Vagrant VM. This is what installer is doing and we want to test. For example, if we remove the kernel configuration from installer, the test may still pass because it is already there.

It is interesting to see if multiple BYOH hosts can co-exist on the same VM : installer is configuring the kernel which is shared for all containers and there could be races between install/uninstall installing different k8s versions etc.