Add support for chroots and/or containers

[david-caro]

Aside from the vms, that will require major refactoring of the virt module to do it right

[ifireball]

Can this be a plugin? "lago mock ...", and "lago docker ..." ? I guess we will need ways to create 'lago status' plugins and JSON language plugins.

[david-caro]

that's a bit more of an issue, as that is not consistent with the current architecture, as there's no 'lago vm' command (or similar) to support that way of working, we should first support the lago vm one, and that's a full invertion of the current way of working (instead of action+object, you start running object+action, start vm_name vs vm start)

[ifireball]

well, I think package repos used to work that way (I don't have the ovirt plugin installed atm so can't check), it will be somewhat more consistent with how git/puppet do things. (git remote, git config, etc.). OTOH I've no strong opinion here but we may have a name spacing issue (how do you tell it that you meant the 'engine' container and not the 'engine' vm, or maybe names should never collide like this). I would like it to be possible to add "things" with plugins.

[david-caro]

My idea was that just change the backend that provides the 'vm', where vm can be an actual vm, a container, a chroot or whatever, so in that case, the name collision issue is the same as having two vms with the same name, up to you.

The plugins here would provide new backends, not every plugin has to be a command plugin

[david-caro]

btw. the 'just' there is an euphemism... :/

[eedri]

After talking with @fabiand, maybe we should consider using Kubenetes to actually support containers inside Lago. So instead of managing containers ourselves on the bare metal, we'll have a VM running Kubenetes and it will manage other nested VMs as PODs which will support running containers.

@fabiand maybe you can elaborate on what we talked about?

[ifireball]

This is not a replacement for this issue. We want container support in Lago to allow doing things more efficiently when a full VM is not needed, for example, for letting lago provide services for tests like storage or DNS, etc.

[eedri]

But the question is how costly it would be to manage those containers alone and if we have a valid use case to support it, rather than using Kubenetes to do it instead.

[ifireball]

Considering nested Kubernetes for this is like considering nested Katello to replace "lago ovirt reposync". It does not make sense at all. We want containers to conserve resources. Kubernetes, for all its benefits, will not do that on the small scale that Lago operates in.

Kubernetes running in a VM will also not be useful to run things that need to transfer communications between the host networks and the internal prefix networks, like for example VPM services that will let you "VPN into Lago" remotely.

[fabiand]

Technically Kubernetes can run inside or outside of the Lago VMs.

But Kubernetes does not come for free, so you have to install some stuff on the host to make it work, you also have to configure stuff (docker, firewall) to make it work. In addition to that you'll need to setup an external networking plugin to add networking to it - and depending on the networking plugin other host stuff might need configuration.

OTOH you could run kubernetes also on the VMs which are spawned by Lago. Then these hosts support a) package installations and b) pod deployments. And this provides the flexibility that you can setup a multi-node kubenetes cluster, which is also something whi is eventually needed during testing (i.e. if you want to test daemonsets, or deployment update strategies). In this setup - because it's isolated and well known - it's easier to setup the inter node communication.

In the end I agree that Kubernetes could be setup on the host, but it will make the lago setup more difficult, is not predictable how many nodes you will have in the cluster.

@ifireball wrt to lago ovirt reposync - If k8s would be running on all vms, then it still makes sense to call reposync, as the vms are still regular OSes - with k8s installed alongside. If the assumption is true that all vms run k8s, then you could even consider to add verbs to lago to expose functionality.

For the VPN service container - would it be an option ot forward a port from the host to the K8s Cluster, where the VPN software could be used to provide access to the VMs and and the K8s Cluster itself?

[ifireball]

@fabiand Perhaps the core idea of Lago is that it tries to emulate a "dark datacenter" on top of which you need to install your software in order to test it. Since some aspects of managing a data center are not always important for the tests them selves, Lago provides those as lightweight services. Notable examples are DNS services and package curation services.

Since Lago was initially designed as a testing platform, allowing "remote access" to the emulated data center is not something that had been on the radar. But it had been asked for enough time since.

Keeping with the datacenter metaphor, an appropriate remote access service would wither be something like OpenVPN, if providing access similar to what a datacenter admin would have, or a reverse web proxy, if emulating how end users typically access services running in a remote secured dataceter...

WRT running K8s on top of Lago VMs, that is something that seems to be a prerequisite to making OST for Kubvirt. The installation process for that is, IMO, an inseparable part of the testing process, and not something that should be wrapped into Lago features. In order to figure this out, we must first figure out what the process for a user with a real "dark datacenter" is going to be.

The latter topic, is however, not the topic of this issue at all.