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

[Balbir Singh]

On Sat, Oct 4, 2008 at 1:17 AM, Daniel P. Berrange <berrange at redhat.com> 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 at redhat.com> 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