Re: [libvirt] Re: [discuss] The new cgroup patches for libvirt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]