Re: [atomic-devel] Fedora Atomic Workstation questions

[Dusty Mabe <dusty dustymabe com>]

Note: I copied this email to the atomic-devel projectatomic io list. The atomic 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!