[one-users] Test Adapter for OpenNebula ?

[Gary Mazz]

Hi Ruben,

Thansk this works well. It will give me a leg up before I hook into the 
cluster.

cheers, -g

Ruben S. Montero wrote:
> Morning Gary,
>
> Check http://dev.opennebula.org/projects/onesim/wiki/Wiki and give it
> a try. Let us know
> if it is good for your purposes.
>
> Cheers!
>
> Ruben
>
> On Tue, Sep 29, 2009 at 11:25 AM, Gary Mazz <garymazzaferro at gmail.com> wrote:
>   
>> Hi,
>>
>> I think this would work for the initial development,  I think the simulated
>> time, especially for provisioning and startup is important. It allows my
>> work out the "remote aspects" of the http protocol. A settable in a conf
>> file would be great.
>>
>> Its 3:30 am by me, need some sleep... :-)
>>
>> -gary
>>
>> Borja Sotomayor wrote:
>>     
>>> Hi,
>>>
>>>       
>>>> Well in fact this may be quite straight forward if we assume that all
>>>> operations always succeed and we do not need to model the behavior of
>>>> the hosts. Gary, let me know if this would work for your demo. Borja,
>>>> we can use this as a very simple development backend.
>>>>         
>>> To be more specific, I think this 'test adapter' would have to provide the
>>> following features:
>>>
>>> - Allow specification of a number of physical hosts with specific
>>> capacities using a configuration file.
>>>
>>> - Internally keep track of what VMs are running and respond to monitoring
>>> command with predictable values. For simplicity, a simple starting point
>>> could be to make all VMs say that they are using 0% of their allocated CPU
>>> or 100% of their allocated CPU (maybe in the future allowing for more
>>> complex models, to replicate real workloads).
>>>
>>> - Allow execution of all OpenNebula operations. For simplicity, as Ruben
>>> points out, a simple starting point is to assume that all operations
>>> complete successfully and instantly. In the future, it would be nice to also
>>> configure delays (most importantly, suspension/resumption shouldn't be done
>>> instantaneously; the test driver should try to replicate that there's a
>>> delay while the VM suspends/resumes, and that is should remain in the
>>> "suspending" state for some time before transitioning to "suspended") and
>>> even failures (e.g., I want to add error handling code in Haizea, but doing
>>> this with a real testbed is messy, since it involves somehow provoking the
>>> VMs to fail).
>>>
>>> - As a starting point, this test adapter should operate in "real time".
>>> For simulations, it would be nice to have "simulated time" (so we can
>>> fast-forward through a lot of requests) but since the core and the scheduler
>>> are separate processes, it would involve coordinating this simulated time
>>> between the two components. This is doable, but we would to think about
>>> what's the best way of doing this.
>>>
>>>
>>> Gary: Would the above meet your requirements?
>>>
>>>
>>> Cheers!
>>>       
>> _______________________________________________
>> Users mailing list
>> Users at lists.opennebula.org
>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>
>>     
>
>
>
>