virtualization benchmark suites

[Carl Trieloff]

On 09/22/2011 09:54 PM, Frank Novak wrote:
>
> project-planning-bounces at ovirt.org wrote on 09/23/2011 07:57:08 AM:
>
>> From: Carl Trieloff <cctrieloff at redhat.com>
> ....
>>>>>> What is the group's feeling about benchmarking projects? If there's
>>>>> interest I'll pursue things on our end
>>>>>> (no promises). But I think this is good feedback from our customers
>>>>>> and
>>>>> am interested to hear comments on
>>>>>> the idea.
>>>>> How would that differentiate from specvirt?
>>>> specvirt is neither free as in beer nor free as in speech.  It's not
>>>> something that a customer can easily obtain and play around with
>>>> themselves.
>>> Does such benchmark ever existed (apart from kernel build)? :)
>>> As you pointed Anthony, let the ovirt project first focus on simplify
>>> the build process before we develop a competing benchmark suite to the
>>> one that we base lots of our marketing over.
>>>
>>> Sorry spilling cold water, just one thing at a time.
>>
> +1  (to the extent I get a vote.. Hmm, may need to go look at those rules
> again! :-) )
>
>> My view is build the eco-system. That means welcome any additional
>> complementary project. Having multiple projects under coordination means
>> that each project can build at it's own rate, yet we can have
>> integration. Additionally, not everyone can work on the same thing. We
>> have the concept of project maturity, so there is no risk as long as it
>> is well defined and complementary.
>>
>> Additionally, if a project comes in and after a year or so gets no
>> traction we can sunset it. This provides a healthy model to have
>> community innovation in and around the oVirt core project.
>>
> We need to get a lot of seeds going.. while additional projects may take a
> little attention from the initial project base, we need to foster growth.
> I think the real question is whether or not we think it's within the scope
> and mission of oVirt; I think there's certainly a need for it as a
> community effort.. certainly important to the KVM ecosystem in general..
> may not exactly fall into 'management' related, but I think we're broader
> than that. It's also somewhat independent of the core framework, so
> hopefully doesn't cause too much disruption to getting the base going, and
> probably doesn't pull on/distract the core buildout.. may appeal more to
> somewhat of a different crowd..
>
>

yes, the key is going to be working out what is complementary, 
balancing building momentum and breadth. I'm sure we will spend many
emails on this topic working through this as the project grows. I would
also like some of Jim's input here when he gets back from PTO.

Carl.