Note: I copied this email to the atomic-devel(a)projectatomic.io list. The
atomic(a)lists.fedoraproject.org is mainly meant for automated emails.
On 02/07/2018 09:27 AM, Elad Alfassa wrote:
Hi all,
Hi Elad!
I have some questions regarding Fedora Atomic Workstation:
1) How do 3rd party repositories (such as ones providing nonfree drivers, which obviously
can't be containerized) work with rpm-ostree?
If our end goal is for users to be able to use Fedora Atomic Workstation for every
usecase they use Fedora Workstation for today, we need a plan for this.
You can add a yum repo file into /etc/yum.repos.d/ and install software via `rpm-ostree
install pkg.name.rpm`, which will pull the software from the 3rd party yum repositories.
There are some issues with say kernel modules that need DKMS, but most rpms will work
fine.
One possible solution (which isn't exactly the most clean one, but it might work) is
to allow /usr/local to be writable, and allow it to be managed with package management
tools such as dnf. This will also be useful for legacy software which people still need to
use, but can't be containerized easily.
/usr/local is writable today. but if you're installing rpms then why not use
`rpm-ostree install` ?
3) I understand the benefit of containerizing my workstation. However, I'm not sure
everything I do can be done in a container.
For example, if I want to hack on a system-level DBus service. What's the proposed
workflow for this? keep in mind I don't want to just make temporary changes
that'll disappear after a reboot, because I want to be able to use my service even if
it never finds its way into Fedora proper (since it probably won't).
Am I supposed to create a container and expose DBus (and other system stuff my service
might need) to the container?
And what if I want to hack on the container runtime itself? :)
If you want to hack on the software as flat files then just throw them in a writable fs
(/usr/local, for example) and modify/hack on them there. If you want to more officially
install them then create an rpm out of them and package layer them. If they aren't in
fedora proper you could use COPR to build/manage them.
4) If I have a container for development, this means that I have to have two copies of
coreutils, openssh, and most system libraries/utilities.
One copy, the "host", is updated by rpm-ostree. But what about the copy on the
container? I'll have to remember to manually rebuild it on every update, or manually
run "dnf update" in the container, which is not ideal (i'll probably forget,
and end up running insecure/buggy software).
Would it be possible to build a container based on the host filesystem in such a way that
all basic system libraries and utilities are accessible directly (not as a copy) for the
container? Alternatively, would some mechanism for automatic re-building of the container
images after every ostree update is done can be created?
To date we haven't really explored this option as much. I have talked about it with
Colin before and I like to call this type of container a 'host context' container.
The idea is pretty much everything is shared with the host as well as a small overlay of
packages that are specific to the current context you are in. You could have many
contexts. Either way there will still be parts in each context that would still need to be
updated/managed.
5) Do we expect every developer using Fedora to write their own Dockerfile / Buildah
script for their development environment? I think that's a bit too much overhead and
we need to at least have a utility to automatically generate these based on some common
configurations, and the usage might look something like
create_dev_container --langauges=rust,python,c --additional-packages=ffmpeg
interesting idea. we haven't really fleshed that out yet. most people are building
their own pet containers because most peoples environments can be pretty unique to them.
I like the idea of Atomic Workstation, and I want it to become our default offering one
day, but I think that before we get there we have to figure out this kind of stuff. (Maybe
you already did and I just missed the documentation?)
Thanks,
--
-Elad.
Thanks for the questions!