On 11/18/2014 09:03 PM, Serge Hallyn wrote:
Quoting Tamas Papp ([email protected]):
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
_______________________________________________
lxc-users mailing list
[email protected]
http://lists.linuxcontainers.org/listinfo/lxc-users
