Re: [atomic-devel] Atomic as Base OS for Standalone Appliance

[Colin Walters <walters verbum org>]

Hi Shane,

On Mon, May 21, 2018, at 3:09 PM, Shane O'Donnell wrote:
> Hey All –
> 
> We’re building an IoT edge device based on CentOS Atomic Host 

Cool; without knowing more it feels like this falls in between "server"
and "device"?   If it's more "device" like then the newly formed Fedora
IoT group is intended to be the place, although as of yet as far as I
can tell there isn't even a mailing list?

> As an example, we’re trying to follow the “transactional” nature of 
> Atomic, but we’re finding there’s no real “commit”.  When we need to 
> change something in the OS itself, 

A big topic here is whether you derive from the CAH ostree commits (hostimages),
or whether you do a custom compose/build.  The latter is fairly straightforward
and gives you full control.

> we end up stuck with a “hotfix” 
> flagged deployment that we can’t really “commit” to clear the flag, 
> which leaves us unable to make follow-on transactional changes.

It depends on what you want to do - we could probably fairly easily
support a model where there's one or more persistent "layer"s.  I just
filed this: https://github.com/projectatomic/rpm-ostree/issues/1370

But again it depends on what content you want there.

> We are also in the process of migrating our Ansible-based platform 
> customization and software-load (i.e., Docker containers managed via 
> Docker Compose) which seems somewhat unnatural in the Atomic world.

Hmm.  Today we do support Ansible although most of our efforts
as you noticed are oriented towards Kubernetes.  

> The docs seem pretty clearly focused on using Atomic as the OS for a 
> cluster, but our standalone deployments seem to leave us with a lot of 
> questions.  I think the following list is a reasonable summary of the 
> big questions we haven’t really figured out yet:
> 
> 
>   *   Is there a “commit” that would allow us to commit the current 
> “hotfix” to the current deployment?

Not today, though the above issue covers some of it.   On IRC you mentioned
kernel arguments; we could add `--inplace` or something.  That'd likely
be fairly easy to do.  Kernel argument management is a gap for sure.

>   *   All of our appliances start with a common base image.  What’s the 
> recommended approach for changing kernel arguments so they appear in the 
> common base image?

ostree today does not store kernel arguments in the commit.  See also
https://github.com/ostreedev/ostree/issues/479

The high level thing to understand is that the design mostly is that
rpm-ostree can be used in the same places/same way as one might use
"classic" package managers like yum/apt.  Since today one doesn't
store kernel arguments in rpm/deb packages, ostree also didn't do it
by default.  Instead you use kickstart or config management or whatever.
But that doesn't mean we couldn't!   Like I said in the issue, it'd
probably make sense to do, but we'd have to work through some overlap
in terms of how it works with Anaconda, etc.

See also one of our oldest issues:
https://github.com/projectatomic/rpm-ostree/issues/471

> Note that we’re both invested and committed to using Atomic, and we’d 
> like to offer up a resource to help flesh out the “standalone” side of 
> the documentation so we both have some agreed upon contract between 
> users and core devs, as well as to better enable new users with this use 
> case.

That's always nice!