GMT Developer mode that uses native docker-compose and just hooks into containers

[ArneTR]

We have recently experienced that people tend to use very complex docker compose files and using them with GMT directly is not possible.

A possible way to enable developers to re-use them easier could be to just scan the files, capture the later to be used container names, then orchestrate the whole file with docker compose up and just tap into the containers.

This discussion is to keep track of the idea and add upsides and downsides as long as it either gets rejected or implemented.

Upsides

• In Development people that have used the native docker compose can expect the same orchestration and no need to adapt for GMT reduced implementation

Downsides

• Implementation effort to switch to new system
• Possible security problems in docker compose get also translated to any GMT runs
• People that do not use docker compose but maybe podman compose would maybe get slightly different behaviour. Technically all clients should implement the spec the same way but Google searches and ChatGPT suggests there are implementation differences. Anyone got hard details and experiences here?
• In order to make the GMT run securely and also in a somewhat expected way some docker-compose features might need to be blacklisted. (Exposing ports, mounting local volumes, mounting files writeable, btrfs which might have no kernel support etc.)
  • So in the end we might bring users to the GMT easier but when then really using it in a cluster or even submitting a job to our test cluster it will still fail ... so in some form we are just delaying the problem

[ArneTR]

@ribalba I have put our discussion on the phone to an online one. Happy if you add your remarks

[ribalba]

I think the difference is in how people start using the GMT. If I am a company and I want to try and see if I can use the GMT to measure my software it is very off-putting to have to spend multiple days to just get the basic structure working. As I mentioned I needed to code features into the GMT to get something running. This company would have never been able to use the GMT. At this point I am not even thinking about exact measurements. Adding to the huge hurdle of getting my code to run in the GMT I then also have to write the usage scenario file. Learn all that syntax etc ... So as a company this is an investment multiple days/ if not weeks for a tool I don't even know I want to use. So people will abandon ship and use a simpler tool that doesn't give you as exact measurements but works out of the box. [0][1]

I think it boils down to the discussion. Do we want a tool only experts can use, that can invest multiple days in getting something running or do we want something that can work out of the box for people to try. Once people see the advantages of running something in the GMT locally they can then make the decision to invest into "porting" their infrastructure to our "secure" format.

So I propose the --compose-file argument that can be used locally to get the system up and running very fast with the measurements not being exact and then when people want exact measurement, on our cluster, they have an argument to put in the work.

Basically what learning curve to we want

┌────────────────────────────────────┐      ┌────────────────────────────────────────┐
│                                    │      │                                        │
│                         ┌──────────┤      │                                        │
│    ┌────────────────────┘          │      │                                        │
│    │                               │      │                             ┌────────  │
│    │                               │      │                             │          │
│    │                               │      │                     ┌───────┘          │
│    │                               │      │              ┌──────┘                  │
│    │                               │      │         ┌────┘                         │
│    │                               │      │    ┌────┘                              │
├────┘                               │      │ ───┘                                   │
└────────────────────────────────────┘      └────────────────────────────────────────┘

[0] https://github.com/hubblo-org/scaphandre
[1] https://codecarbon.io/