Re: [systemd-devel] How to deploy systemd-nspawn containers and use for deployment

[Nathan Williams]

Fwiw, if you're using Chef, the impending release of v3 of the systemd
cookbook has a machine_image and a machine resource, which use importd and
nspawn under the hood.

On Wed, Oct 19, 2016, 3:45 PM Lennart Poettering 
wrote:

> On Thu, 13.10.16 01:09, Brian Kroth (bpkr...@gmail.com) wrote:
>
> > Seems really dependent upon the container layout as to what's the most
> > appropriate way of doing that. For instance, if the underlying fs of the
> > source container is something like btrfs or zfs you could imagine doing a
> > send/recv of a golden snapshot. Possibly also for an lvm volume/snapshot.
> > For others rsync might be best. For others maybe it's just a deployment
> > script or tar or git repo.
>
> Yeah, to make this clear: I doubt we should really be in the
> deployment business too much. That's for other people to solve, for
> example rkt.
>
> However, I do think the most basic bits should probably be available,
> simply to get developers off the ground for the most basic testing. I
> figure that means "machinectl migrate" (as suggested in the other
> mail) is really as good as it might get, and anything fancier should
> really be left to other projects.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] ruby bindings

[Nathan Williams]

yes, i think it would be great to have a single library supporting all the
systemd features, and perhaps at some point i can donate the dbus-systemd
code to such a project (not that there's much to it, just a thin
systemd-specific layer on top of the great ruby-dbus work), but so far as
i'm aware, there's not a lot out there right now. at present the
systemd-journal gem is the best thing going for journald, and dbus support
is clearly out of scope. as i understand (from a brief comment in one of
the conf videos i saw), there's currently deadlocking concerns preventing a
journald dbus interface (?), but if one's ever implemented, i'd be happy to
add support for it to dbus-systemd.

in general, i'm not aware of many system services being written in ruby
(unless you count rack & friends), so perhaps there's just no real call for
it. journald obviously has broad appeal for application developers, and an
ecosystem of log aggregation tooling driving adoption with ops folks, but
up to now i think the dbus APIs have been under-utilized. my intention with
the dbus-systemd gem is to fill that need; selfishly, so i can scratch my
own itch to stop using shellout in the systemd Chef cookbook when there's
an API available to do what i want without all the contortions :). for the
cfg mgmt use case, i think something that just handles dbus interfaces is
right on target, and installing systemd-journal if i need it is no big deal.

cheers,

nathan

p.s. Pantheon's comments re: daemon-reload performance (great talks btw)
are also a big motivation for this; the systemd-cookbook is hopefully
headed toward needing far fewer reloads if we can swap in calls to
SetProperties instead.

On Tue, Oct 4, 2016 at 7:30 PM David Timothy Strauss 
wrote:

> For what it's worth, I try to encourage projects to identify their
> bindings as simply for systemd, even if the journal support is the first
> (and only) set of APIs available. It's just so easy to support the other
> APIs once the journal is already supported, and daemons that want to use
> the journal should consider using the notify API as well for
> startup/shutdown status -- and other APIs offered for daemons by systemd.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel