-----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-----

Reply via email to