[lxc-users] packaging

[Tamas Papp]

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?

> 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)?

> 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).

Have you seen flocker? It would be awesome, if its featureset could be 
part of lxd (but as lxc, not docker:).
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).

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 this is what is in my mind as a dream.
1. Containers can be replicated to (even geographically) remote hosts.
2. Containers can be migrated in live without a shared storage: initial 
transfer -> incremental transfer1..2....N -> container 
stop/freeze/hibernate ->final transfer.
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....


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


Cheers,
tamas