-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu February 5 2009 10:18:17 am Josh Thompson wrote:
> > > function name: XMLRPCblockAllocation
> > >
> > > parameters:
> > > imageid - id of the image to be used
> > > start - unix timestamp for the start time (i.e. machines should be
> > > pre
This is just semantics for now but it might be better to think of the number of
things being allocated as requests rather than machines. This will allow for
block requests of cluster images.
Regarding the return code... it might be useful to return the number of requests
that haven't been suc
never mind this response
I overlooked the part about keeping the first function which provides the
ability to create a block reservation through the API.
Aaron
--On February 5, 2009 10:33:40 AM -0500 Aaron Peeler
wrote:
That would work.
But now you loose the ability to create new block
That would work.
But now you loose the ability to create new block allocations through the
API. Previously it created one if there was not an existing entry.
So I guess we need to ask is this a desired/separate feature, the ability
create block reservations through the API.
--On February
Another suggestion.
Can you look at staggering the reload start times based on the load of the
management node?
A problem that currently exist on the backend method is that the block
allocation process inserts multiple reloads at a time, which can quickly
overload a management node. For exam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
For the frontend, one function works as well as two would. However, I can see
how it would simplify code on the backend to just pass a blockTimes id since
it wouldn't have to determine all of the other information (blockTimes
entries include blockr
Would it make sense to break this into two functions?
Have this function XMLRPCblockAllocation with only two parameters
blockrequestid and blockTimeid.
The second function would be to create the Block Allocation -
XMLRPCcreateBlockAllocation.
Aaron
--On February 4, 2009 4:39:30 PM -0500 Jo