(feat): Isolation Mode for host, docker and VMs

[ArneTR]

This is a first draft of the new isolation mode for the GMT.

GMT will then directly support switching isolations modes depending on the configuration of WHAT to measure.

The flag will be in the usage scenario.

Current planned isolation modes:

• Host (minimal implementation)
• Docker
• Podman (raises NotImplementedError)
• Kata-Containers Cloud Hypervisor
• Kata-Containers QEMU

The host mode is only minimally implemented and uses a shim where all 'exec' commands are run on the host and everything else is forwarded to docker.
This design decision stems from the idea that even in host mode one COULD want to start services on the system.
This is to be discussed as one quirk results from this: Started services cannot be interacted with anymore other than calling 'docker exec ' as a command ... which feels a bit weird ...

@ribalba Interested for your opinion on the host mode draft. This PR however is mostly for the isolation functionality that I need so happy to rip host mode out again like this

[ribalba]

This looks really "dirty" and I am not quite sure what this would do:

isolation:
  type: host
  backend: null

services:
  test-container:
    image: alpine:latest
    setup-commands:
      - command: apk add stress-ng

flow:
  - name: Running Command
    container: test-container
    commands:
      - type: console
        command: __GMT_VAR_COMMAND__
        note: Running __GMT_VAR_COMMAND__

I am telling the isoltation to be host but am still using docker?

I get the simplicity on how this solves the host problem with a little script that just redirects docker exec commands to the host but somehow this makes the whole output weird as well. You will get loads of docker things when running stuff in host mode.

If this is something we just want to use internally I think this is ok. But if we want people to use it I would make it "cleaner" and easier to use. Now this is very confusing.

[ArneTR]

This looks really "dirty" and I am not quite sure what this would do:

isolation:
  type: host
  backend: null

services:
  test-container:
    image: alpine:latest
    setup-commands:
      - command: apk add stress-ng

flow:
  - name: Running Command
    container: test-container
    commands:
      - type: console
        command: __GMT_VAR_COMMAND__
        note: Running __GMT_VAR_COMMAND__

I am telling the isoltation to be host but am still using docker?

I get the simplicity on how this solves the host problem with a little script that just redirects docker exec commands to the host but somehow this makes the whole output weird as well. You will get loads of docker things when running stuff in host mode.

If this is something we just want to use internally I think this is ok. But if we want people to use it I would make it "cleaner" and easier to use. Now this is very confusing.

You are referencing the test here, right? Idea is just atm that you can use host mode but STILL start processes on the system as docker containers.

I understand this can be confusing and see three ways to handle it:

• Forbid the services tag and not allow any start of containers when using host mode
• Do not start the stuff as services but as actuall process -> Almost impossible IMHO as it has to be extracted from a container
• Introduce a new root level key "host_services" which can start services on the system and close them again after the measurement. Handy ... but only if host mode was a bigger game.

Happy to remove host mode with my idea from this one.

I imagine you have a host mode implementation already in your head?

[ribalba]

I would not mix host mode and "container" mode. If there is type: host I would ignore/ ban the services key. Like this it is cleaner and easier to understand.

Or if you want to keep both I would add the type to the flow step:

flow:
  - name: Running Command Container
    container: test-container
    type: container  #if the container key is pressent assumed
    commands:
      - type: console
        command: __GMT_VAR_COMMAND__
        note: Running __GMT_VAR_COMMAND__

 - name: Running Command Host
    type: host
    commands:
      - type: console
        command: __GMT_VAR_COMMAND__
        note: Running __GMT_VAR_COMMAND__

  - name: Running Command Container VM
    container: test-container
    type: container  #if the container key is pressent assumed
    backend: vm
    commands:
      - type: console
        command: __GMT_VAR_COMMAND__
        note: Running __GMT_VAR_COMMAND__

and don't have the isolation root key