ostreedev / ostree

Operating system and container binary deployment and upgrades
https://ostreedev.github.io/ostree/
Other
1.31k stars 301 forks source link

Create /sysroot in the deployment if it doesn't exist #2008

Open clime opened 4 years ago

clime commented 4 years ago

I think it would be great if ostree creates sysroot in the deployment automatically if it isn't already contained in the tree. It would make things easier for newcomers. I personally spent quite a long time debugging this. I mean, it is written in docs https://ostree.readthedocs.io/en/latest/manual/adapting-existing/ but it's quite easy to forget about it and you receive quite strange errors when you don't do it (under centos7 ostree-prepare-root keeps looping infinitely with error that sysroot.tmp already exists that's because the original error was already scrolled out and it is not even possible to rd.break in that state).

clime commented 4 years ago

This change should also include the following:

1) automatically create symlink ostree -> sysroot/ostree if it doesn't exist 2) automatically create symlink boot -> sysroot/boot if it doesn't exist

...because these symlinks are needed as well for the correct operation of ostree. If it is impossible to perform these actions during deployment, throw an error.

Alternatively, there should be a check on a tree being deployed if it conforms to ostree criteria or not instead of doing those automatic actions (one or the other might be preferred by different people i guess). In any case, i think that would save lots of debugging time to people working with ostree.

cgwalters commented 4 years ago

We haven't really tried to streamline the path for converting an existing system; it would make sense perhaps to do so, but on the other hand there are already a few working OSTree-based build systems out there, and usually one is best off basing on one that already works.

In your case since you mentioned centos7 - all of the code for CentOS Atomic Host is available. Bigger picture it uses rpm-ostree.

I think I said this on IRC - I'm happy to support using "raw ostree" and not rpm-ostree for sure. The current vision is that OSTree is more of a library than an end of itself.

Maybe it would help to have more references in upstream to some of this existing code?

clime commented 4 years ago

We haven't really tried to streamline the path for converting an existing system; it would make sense perhaps to do so, but on the other hand there are already a few working OSTree-based build systems out there, and usually one is best off basing on one that already works.

In your case since you mentioned centos7 - all of the code for CentOS Atomic Host is available. Bigger picture it uses rpm-ostree.

I think I said this on IRC - I'm happy to support using "raw ostree" and not rpm-ostree for sure. The current vision is that OSTree is more of a library than an end of itself.

Maybe it would help to have more references in upstream to some of this existing code?

It could help yes but i think that if there are certain requirements on a tree being deployed (like empty /sysroot dir exists, /boot points to /sysroot->boot, /ostree -> /sysroot/ostree), they could be checked while making the deployment and e.g. a warning could be printed, because if e.g. /sysroot is missing, you are not going to boot that deployment. If the boot symlink is missing, ostree admin status doesn't work and the message doesn't clearly say why.

It's not a big thing, i think people will usually figure it out eventually but making ostree more fool-proof also wouldn't hurt.

clime commented 4 years ago

As for the other comments (i needed to think about it first), CentOS atomic or even just rpm-ostree are nice projects but I believe they don't cover use-case when one wants to provision bare-metal hosts and no containerization is intended (applications should run directly on hosts because of special hardware access requirements). Also the systems should be immutable by default (unless ostree admin unlock is used which is a cool feature by the way) so rpm-ostree alone also gives "too much freedom". Just bare OSTree is perfect here (i.e. when one doesn't want containers and also any target host mutability).