Re: [atomic-devel] Fedora Atomic Workstation questions

[Dusty Mabe <dusty dustymabe com>]

On 02/07/2018 11:49 AM, Elad Alfassa wrote:
> 
> 
> On Wed, Feb 7, 2018 at 4:45 PM, Dusty Mabe <dusty dustymabe com <mailto:dusty dustymabe com>> wrote:


>     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.
> 
> 
> Oh, great! for some reason I assumed rpm-ostree can only download pre-composed trees from Fedora.
> In the future it might be worth to add some sort of compatibility wrapper around "dnf install" (and such) like dnf has for yum - to show a message to let you know that tool is "deprecated" and that rpm-ostree is what they need to use now. Otherwise people might get confused about "how do I install anything? non of the tools I'm used to are here".

Definitely. We think about this often and want to come up with a good solution. Some of those conversations have happened in #405 starting here: https://github.com/projectatomic/rpm-ostree/issues/405#issuecomment-342985721

> 
>     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.
> 
> 
> At the moment, I can have auto-updates for my host system and for my Flatpaks, but there's no real mechanism to update containers. I assume people will not be happy if we just automatically run "dnf update" inside all their containers, but if you have a lot of "contexts" you'll have to update all of them yourself.
> I'm not sure what's the best approach here, but ideally I think the aim should be for as little "maintenance overhead" as possible. If you have to maintain your pet containers and update them manually, you're either going to spend a lot of time on this, or not bother at all and run insecure software.

Yeah. as little maintenance as possible would be nice. In the Host contexts that mostly builds on rpm-ostree you would package layer files into each context, which could then be managed by rpm-ostree on the host itself. If it's just `dnf install` instead then it gets trickier, but could be doable. 

Regarding the 'my pet container is out of date' comment, If you think about it today if you have your host and you do some development in a VM (like via vagrant), then you still have to update both the host and the VM, so not much lost there. I realize, though that this conversation is about how we make things better :). 


> 
> Building on this "contexts" idea, maybe a "context" could be some sort of a "managed container"  that will be automatically updated when you update your host (both via graphical or cli tools)? Or at least give you a message when you switch into that context suggesting you install security updates.

+1. I agree

> 
> 
> 
> 
>     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.
> 
> 
> Yeah, but even if you build a "pet container", you have to start somewhere. If we have a tool to get you started more quickly, it could have a set of reasonable, opinionated defaults that you can later add upon (either by editing the Dockerfile / script that will be created by this command or by running dnf on the newly created container).
> I think I'm going to make a proof of concept for this later, to see if people are interested in such a tool.
> 

That would be cool. Maybe checkout toolbox from CoreOS to see if it will aid us in this journey: https://github.com/coreos/toolbox 

> In case this is not clear, I'm not asking these questions just because I just want to *use* Atomic Workstation, but also because I want to contribute and help make it better.

That's awesome. We're glad to have you in the community. We have weekly meetings and we hang out in IRC in #atomic on freenode. Come find us!