On Sat, Oct 4, 2008 at 1:17 AM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Sat, Oct 04, 2008 at 12:13:38AM +0530, Balbir Singh wrote: >> On Fri, Oct 3, 2008 at 11:43 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: >> True, it definitely does and the way I look at APIs is that they are >> layers. We've built the first layer that abstracts permissions, paths >> and strings into a set of useful API. The second layer does things >> that you say, the question then is why don't we have it yet? >> >> Let me try and answer that question >> >> 1. We've been trying to build configuration, classification and the >> low level plumbing >> 2. We've been planning to build the exact same thing that you say, we >> call that the pluggable architecture, where controller plug in their >> logic and provide the abstractions you need, but not gotten there yet. >> >> When you announced cgroup support in libvirt, it was definitely going >> to be a user and we hoped that you would come to us with your exact >> requirements that you've mentioned now (believe me, your feedback is >> very useful). The question then to ask is, is it cheaper for you to >> build these abstractions into libvirt or either helped us or asked us >> to do so, we would have gladly obliged. You might say that the onus is >> on the maintainers to do the right thing without feedback, but I would >> beg to differ. > > The thing I didn't mention, is that until Dan posted his current patches > actually implementing the cgroups stuff in LXC driver, I didn't have a > good picture of what the ideal higher level interface would look like. > If you try and imagine high level APIs, without having an app actually > using them, its all too easy to design something that turns out to not > be useful. > > So while I know the low level cgroups API isn't what we need, it needs > the current proof of concept in the libvirt LXC driver to discover what > is an effective approach for libcgroups. I suspect our code will evolve > further as we learn from what we've got now. By doing this entirely > within libvirt we can experiment with effective implementation strategies > without having to lockdown a formally supported API immediately. Once > things settle down, it'll easier for libcgroups to see exactly what is > important for a high level API and thus make one that's useful to more > apps in the long term. > Please remember my words "if you ever find that you have a code base that looks like what we have in libcgroups, please remember to switch over to libcgroup". I fear that you will reach that stage, the code that is going in right now has too many things hard-coded and will need a lot of changes going forward, things like adding support for new controllers is not going to be straight forward, your assumption that only root can create a container might be broken and we'll build support for hierarchies, which will require further changes, etc. I am not scaring you, just trying to make sure we don't solve the same problems twice. Balbir -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list