[one-users] Test Adapter for OpenNebula ?

[Gary Mazz]

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!