Re: [atomic-devel] API to leverage during the install phase of a container?

[Fabian Deutsch <fdeutsch redhat com>]

----- Original Message -----
> ----- Original Message -----
> > From: "Fabian Deutsch" <fdeutsch redhat com>
> > To: atomic-devel projectatomic io
> > Sent: Monday, May 11, 2015 8:54:13 AM
> > Subject: [atomic-devel] API to leverage during the install phase of a
> > 	container?
> > 
> > Hey,
> > 
> > lately I've been experimenting with LABELs, especially to leverage
> > $ atomic install
> > 
> > As far as I have experienced it "LABEL install …" is providing some snippet
> > which is
> > run when atomic install is called.
> > 
> > I started to wonder when I noticed that I need to manually lay out
> > some service file to start the container at boot time.
> 
> Not that this idea is new or novel, but ...
> 
> I think a key differentiator of Atomic vs other Linux (even RHEL) could be
> that it is completely API-driven.

I am not sure I understand - do you mean Atomic is purely API driven?

> > So - What I wonder about if there is already an "API" which atomic provides
> > to
> > a container or if this is planned for future?
> > 
> > The problem is that the bash script approach is not really portable.
> > We can not know ahead in what context the install snippet will be run.
> > And thus it is "pure luck" if an install will work or not.
> > 
> > A clean API would help to fill this whole.
> 
> I think a lot of design patterns/goals I've seen thus far are sort of
> trending in that direction (cloud-init, ostree, systemd, dbus, cockpit), but
> I'm not sure if this goal is formalized at all ?

I'm also not sure if I get this right here: Do you mean that cloud-init, ostree, etc
become the defacto APIs?

If so, then it's fine - we just need to know what assumptions can be made about
the host.

- fabian

> > In this special case I'd expect a call to let me enable the container
> > to be run at boot time.
> > 
> > - fabian
> > 
> >
> 
>