Thanks for the review, Stéphane. So the next thing I was wanting to do (beside fixing lxc-destroy and having the ubuntu-cloud template properly handle cached images and locking in custom lxcpaths for unprivileged users) was the networking. I have a question on that.
Originally I was going to have /etc/lxc/lxc-usernet be a control file with entries like: serge veth lxcbr0 2 meaning serge can attach to veths to lxcbr0. Mind you I'm not sure anything but veth makes sense for unprivileged users, but I don't want to lock other things out right now. Then /run/lxc/nics was going to track the number of already in-use nics per user. The problem with that will be similar to the problem I had with locking for the api: when a container exits, the monitor would have to drop the count again. So if the monitor actually dies a hard death, the user could end up with no active allocations, but /run/lxc/nics saying he was at his quota. One alternative is to simply chown /sys/class/net/$veth to $user, then check the number of $user-owned veths instead of checking /run/lxc/nics for a count. Are there any other ideas? -serge ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
