Maybe I’m missing something, but I don’t understand how the QEMU pointer helps those of us that were using balenaos-in-container. We very specifically need it to run in a container for platforms like Neeve and Azure Stack Edge.
Seemed like we were really close to getting 3+ working (see Issue #60 ), which @klutchell pinned two weeks ago… so, why kill it off?
Apologies, I should have followed up after updating the README. We internally discussed the past progress around supporting balenaos-in-container for OS 3+, and found that we still had a ways to go with regards to getting it to work. We decided to proceed with QEMU as the sole supported option.
However, it seems there’s some context we’re missing around your use case, where QEMU is incompatible with Neeve / Azure Stack Edge. Could you describe it please? It’ll allow us to reevaluate our decision with a more complete picture of customer use cases.
The use case for us is that we need to be able to run entirely inside a docker container. We have no control over the host OS and no control over the host container environment (docker, k8s, AKS, etc). We can’t run VMs, and we can’t use QEMU on the host. The only thing we get is a registry entry pointing to a single container.
balenaos-in-container let us meet that requirements, with an internal manageability layer.
hey @scscsc you’re right that there is no substitute for your use case. In a nutshell, it’s just not something that Balena can currently maintain, test and make sure is production ready.
You are of course free to fork it and keep using/updating it - it has after all a permissive license. Just keep in mind that it’s not a use case that balenaOS is being developed to interoperate with, so there are no guarantees about future compatibility.