Norbert,
Look in utils.pm(version 2.3.2) starting at line 963 for the start
time of processing block allocations. The routine is called
check_blockrequest_time
specifically line 1018: if ($start_delta_minutes <= (6 * 60)) {
Block allocations start getting processed up to 6 hrs before the start
time of the requested allocation.
Other answers are inline:
On Sun, Apr 28, 2013 at 1:04 PM, Madarasz, Norbert <[email protected]> wrote:
> Hi Josh,
>
> thank you your rich and helpful answer, it helped me a lot.
>
> Unfortunately, I haven't found the code where I can modify the 6-8 hour
> values. Can one of the developers tell me how to modify it?
>
> In order to understand better the allocation I went through the code but
> the following are very interesting for me:
> 1. VCL::blockrequest package is only used in vcld main function (line 398,
> 400, 407) but commented default out each time. Does it mean that
> blockrequest.pm isn't needed for anything? What's the reason?
blockrequest.pm is needed and works with the frontend to
process/allocate the machines for the block allocation. All of the
logic to determine which machines get used for reservations is in the
front end. And it made more sense to re-use the front end code for
scheduling then re-creating it in the backend.
The logic in blockrequest.pm is used to start and cleanup block
allocations in at specific times.
lines 398 through 411 is either left over old code or code that was
being tested and mistakenly left in. It's commented out and can be
ignored.
> 2. As I see XMLRPCprocessBlockTime is called from blockrequest.pmand
> xmlrpcWrappers_8php.html. If I'm right and
> blockrequest.pm isn't used anywhere so xmlrpcWrappers_8php.html stays to
> call XMLRPCprocessBlockTime, am I right?
blockrequest.pm drives the processing of the block allocations, so it's needed
> 3. In vcld.main, line 446 (# Attempt to set the blockRequest processing
> column to 1) means that the processing flag in the blockRequest table will
> cause processing Block Allocation? This database attribute is selected in
> fn get_management_node_blockrequests (utils.pm) that I found in only in
> vcld.main (line 361).
no, this sets a processing flag in the blockRequests table so the
backend doesn't go into an infinite loop for up to 6hrs when checking
on the block allocations.
There is also a processed flag in blockTimes table for each time slot
related to the block allocation.
So the rough flow is:
1) vcld pulls in the block allocation data using the
get_management_node_blockrequests routine from utils.pm, in vcld line
361
2) loops through each block request time entry and checks the start
time using check_blockrequest_time in utils.pm If the return value
start and it has not already been processed then it creates a new
child process for blockRequest.pm to begin it's work
lines: 375 thru 459
3) blockRequest.pm calls XMLRPC function XMLRPCprocessBlockTime from
utils.pm to begin allocated machines.
4) after the specific block request blockTimeid has ended,
blockRequest.pm is called again to clean-up.
Hope this helps.
Aaron
>
> Sorry for bothering you but how this block allocation works in code level?
> I've tried to find out the steps but I couldn't..
>
> Thank you in advance!
>
> Best regards,
> Norbert
>
>
> On 25 April 2013 14:42, Josh Thompson <[email protected]> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Norbert,
>>
>> The intent of Block Allocations is for them to preload a set of computers
>> for
>> a specific user group during one or more specific times and to allow only
>> users in that user group access to make reservations for the allocated
>> computers. From what you said, it sounds like your understanding of Block
>> Allocations is correct. However, the details of how Block Allocations are
>> implemented slightly diverge from the intent of them due to the fact that
>> VCL
>> can't know if a specific computer or VM will be available in the future.
>>
>> Block Allocations that have been accepted are considered for processing by
>> vcld. Around 6-8 hours (I forget the specific number) before the start of
>> a
>> time slot for a Block Allocation, vcld will pick it up for processing. It
>> calls the XMLRPCproccessBlockTime function you mentioned to process it. At
>> that time, specific computers are allocated for the time slot of the Block
>> Allocation. At that point, only users from the user group assigned to the
>> Block Allocation can make reservations for the allocated computers. We
>> have
>> found this model to work quite well at NCSU. However, we do have a very
>> large
>> number of nodes available.
>>
>> You are correct that checking the other block* tables would more fully
>> ensure
>> there are computers available for the Block Allocation. However, the
>> implementation of this would require that the scheduler ensure it can
>> allocate
>> computers for each block time slot that may overlap with the time a user
>> has
>> selected for their reservation. This would happen every time a user
>> changes
>> the image selected in the drop down box on the New Reservation page.
>>
>> Another option I'll think about would be to allocate all computers for
>> every
>> time slot when a Block Allocation is accepted. Then, any time something
>> happens to a computer that may affect its availability to a Block
>> Allocation
>> (it is unassigned from its host if it is a VM; it is failed during
>> provisioning of another reservation, etc) a new computer would be assigned
>> in
>> its place.
>>
>> In the short term, if the 6-8 hours in which vcld picks up Block
>> Allocations
>> to process them is not far enough in advance for your needs, I believe it
>> is
>> fairly easy to modify the vcld code to pick them up as early as you would
>> like. One of the vcld developers would have to comment on how this would
>> need
>> to be done.
>>
>> Josh
>>
>> On Wed April 24 2013 5:24:00 PM Madarasz, Norbert wrote:
>> > Hi guys,
>> >
>> > It's me again. First of all thank you again for the information you gave
>> me
>> > before.
>> > I would like to get familiar with block allocation policy so I have some
>> > questions:
>> > a. As I played with it I realized that after accepting a block allocation
>> > request (for 3 seats at a given time while I have only 2 vmslots defined)
>> > with a sysadmin user I can still reserve image (vmslot) at the same given
>> > time with a user from different user group. I tried it out more times and
>> > now I'm a bit confused why this can happen. I thought when I have an
>> > accepted block allocation for all computers (vmslots in my case) for a
>> time
>> > period then none from different user groups can reserve images for that
>> > time. Does it really work as described above?
>> > b. Inside the code utils.php there is a part in fn isAvailable "# remove
>> > computers from list that are allocated to block allocations". It selects
>> > rows from blockComputers table. Why does it check that table, what this
>> > table is for? After accepting a block allocation nothing will inserted
>> into
>> > blockComputers table but into blockRequest, blockTimes, blockWebDate and
>> > blockWebTime. Should not the check part select from these tables to
>> decide
>> > if there is any block allocated computers in the future?
>> > c. In xmlrpcWrappers.php in fn XMLRPCprocessBlockTime I found two INSERT
>> > queries into the table blockComputers. Can you please tell me when this
>> > function is called and by who?
>> >
>> > Thank you for your help it would help me a lot.
>> >
>> > Regards,
>> > Norbert
>> - --
>> - -------------------------------
>> Josh Thompson
>> Systems Programmer
>> Virtual Computing Lab (VCL)
>> North Carolina State University
>>
>> [email protected]
>> 919-515-5323
>>
>> my GPG/PGP key can be found at www.keyserver.net
>>
>> All electronic mail messages in connection with State business which
>> are sent to or received by this account are subject to the NC Public
>> Records Law and may be disclosed to third parties.
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v2.0.19 (GNU/Linux)
>>
>> iD8DBQFReSSpV/LQcNdtPQMRAsABAJ9fNAMOJPJlMlj3N3EDJ8ekB6JQqACeItpr
>> aft11pqDVFw2e9zPXIdbHKg=
>> =YY7/
>> -----END PGP SIGNATURE-----
>>
>>
--
Aaron Peeler
Program Manager
Virtual Computing Lab
NC State University
All electronic mail messages in connection with State business which
are sent to or received by this account are subject to the NC Public
Records Law and may be disclosed to third parties.
