[lxc-users] packaging

[Serge Hallyn]

Quoting Tamas Papp (tompos at martos.bme.hu):
> 
> On 11/18/2014 09:03 PM, Serge Hallyn wrote:
> >Quoting Tamas Papp (tompos at martos.bme.hu):
> >>Ouch, yes lxd.
> >>
> >>As far as I understand it's going to be very soon at least as stable
> >>as lxc is now, right?
> >lxd doesn't replace lxc, it uses the lxc go bindings.  It's taking the
> >'lxc api' we've had for a few years, and exporting it over a REST api,
> >plus adding a new (cleaned up) command line which is a client of the
> >REST api.  But yes I want to be able to use it myself asap so for the
> >very basic functionality I watn it to be stable asap :)
> 
> OK, you're right.
> Though I was referring to lxc command line tools. After a (probably
> short time) lxc-* tools will not support new features, what lxd
> will.
> Is it correct this way?

lxd builds on top of lxc, and any core new lxc features desired by
lxd will go into the lxc api proper.  However yes we will not be
doing major changes to the lxc-* tools themselves (other than how
they inherit improvmenets from the api) - becaues we dont' want to
do non-backcompat changes breaking people's scripts/tools.  That
is precisely the point of having the new lxc command, because we
wanted a new cleaner interface but couldn't really do that with lxc-*
as is.

> >I don't think that's correct.  I'm spending time getting the base lxd
> >functionality off the ground right now, but I intend to keep working
> >on lxc more than on lxd.  There's plenty to be done - which is needed
> >for lxd as much as for lxc - like getting systemd in containers and
> >getting lxc on systemd hosts all working seamlessly, etc.
> >
> >Now, you say "lxc will not improve much" - I have my own list of things
> >I want to get done, but if there are things you feel need to be done
> >in lxc, perhaps we should be building a list, prioritizing it, and
> 
> This is a very good question, how your list looks like? Is there a
> roadmap (both lxc and lxd)?

We're working on that this week.  (I'll be out the next few weeks
after that though)

> >coming up with a decisive list of things we consider crucial for 2.0.
> 
> I don't have so much new requests, just as usual:)
> I was rather wondering, where the project or projects are going to,
> what the direction is, what the goal is (I don't find the good word
> here:O).

We absolutely will support lxc - in fact we committed to 5 years of
support for 1.0, and 2.0 is on the roadmap for release early next
year.

> Have you seen flocker? It would be awesome, if its featureset could
> be part of lxd (but as lxc, not docker:).

Uh, no i don't think I have.

> Actually I use currently lxc a very similar way, but of course not
> as seamlessly as it will work with flocker or will lxd do (with
> shared storage, if I understand correctly).

The command line API is documented very precisely at

https://github.com/lxc/lxd/blob/master/specs/command-line-user-experience.md

and is very much open for review/comment.  If you have any specific
suggestions for things we ought to add, please do bring them up here.

> I can see, that live migration should work fine (haven't tested
> myself yet) - Thanks Tycho! Though Meshuggah isn't...
> http://tycho.ws/blog/2014/09/container-migration.html
> 
> What I miss here is a usable storage backend. ZFS (and btrfs) can do
> incremental send/receive and block level, which is a very-very
> effective way to work without shared storages, but distributed
> environment.

So for myself how I see that semantically is that the lxc api is
about containers on a host.  lxd is more about management across
hosts.  So the fs send/receive is planned for lxd.  Stéphane
definately wanted that (in his case for btrfs)

> So this is what is in my mind as a dream.
> 1. Containers can be replicated to (even geographically) remote hosts.

check

> 2. Containers can be migrated in live without a shared storage:
> initial transfer -> incremental transfer1..2....N -> container
> stop/freeze/hibernate ->final transfer.

check.  We want to do that with p.haul integrated into lxd, I
think in the first half of next week.

Those should be possible with lxd.  And really, don't see this as
"a replacement for lxc-*".

> My experience is that the second incremental transfer usually
> doesn't take more time, just a few seconds.
> 
> My current issues are with lxc is that
> 
> 1. I need to create the container with lxc-create, than mv
> everything to zfs dataset (config and rootfs are included).
> 2. When I want to destroy a container I have to do this: lxc-stop ->
> zfs destroy -r (destroy snapshots) -> busy -> restart cgmanager ->
> zfs destroy. It usually works, but sometimes something still keeps
> the lock.....for a while.
> In fact I am not totally sure, that this is not a zfs feature....

Yeah I've had that, I think only with zfs.

So please do look at the command line user exp doc I linked
above, I think it should give you what you want.

> These are my prefences, among others like more userspaces and
> systemd support of course.
> Just my two cents;)
> 
> 
> Cheers,
> tamas
> 
>