virtualization benchmark suites

Frank Novak fnovak at us.ibm.com
Fri Sep 23 01:54:06 UTC 2011



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..

> regards
> Carl.
>


Cheers,
Frank




More information about the Project-planning mailing list