----- Original Message ----- > ----- Original Message ----- > > From: "Fabian Deutsch" <fdeut...@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 > > > > > >
