Re: frontend API for block reservations (VCL-78)

2009-03-05 Thread Josh Thompson
-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

Re: frontend API for block reservations (VCL-78)

2009-02-05 Thread Andy Kurth
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

Re: frontend API for block reservations (VCL-78)

2009-02-05 Thread Aaron Peeler
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

Re: frontend API for block reservations (VCL-78)

2009-02-05 Thread Aaron Peeler
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

Re: frontend API for block reservations (VCL-78)

2009-02-05 Thread Aaron Peeler
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

Re: frontend API for block reservations (VCL-78)

2009-02-05 Thread Josh Thompson
-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

Re: frontend API for block reservations (VCL-78)

2009-02-05 Thread Aaron Peeler
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

frontend API for block reservations (VCL-78)

2009-02-04 Thread Josh Thompson
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm going to start work on VCL-78 which is an addition to the frontend XML RPC API to allow the backend to call the frontend for allocating computers for block reservations. Currently, the block reservations are created in the frontend, but compute