In working on the API for block reservations (VCL-78), I've realized there
needs to be an owner for any block reservations created via the API.
Additionally, when the backend uses the API to process an existing block
reservation, it will need to use some userid to authenticate. Should we
create a new user for such tasks in addition to the vclreload user? Should
we rename the vclreload user? Should we just keep using the vclreload user
for any system based tasks and just keep the name even though it doesn't
reflect the use?
I'm not familiar with how the XML RPC API stuff works so bear with me and
correct me if I'm reading things incorrectly. The backend provides credentials
in order to use the XML RPC API. Is vclreload being used for this?
I understand the next step when the backend asks the API to generate reload
requests for a given blockrequest/blocktime. The reload requests each need to
have a user assigned to them, currently vclreload.
My thoughts:
I don't really see why we need more than one system account. I think having
an account named vclreload that is used for several other things could be
confusing. I think it would be kind of difficult to rename the account since
it'd have to be changed everywhere at the same time to keep things from
breaking. So, that leaves me not really liking any of the options.
What are others' thoughts?
I agree and don't see the need for having more than one account that is assigned
to non-user/utility/system requests. However, it would be nice if the name was
more generic.
How about this: we start by defining the system account name in the database and
set it to vclreload for now. We can then gradually update the code (backend and
frontend) to use this rather than a hard-coded user name.
It's good that you brought this up... vclreload may have had to be changed to
something like "cloudmakingbeastreload" after the "is this name kosher" thread
is resolved.
-Andy
- --
- -------------------------------
Josh Thompson
Systems Programmer
Virtual Computing Lab (VCL)
North Carolina State University
josh_thomp...@ncsu.edu
919-515-5323
my GPG/PGP key can be found at pgp.mit.edu
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJrEfMV/LQcNdtPQMRAuNTAJsGubBW3L83d1yGcR5SOi4+TgWwawCfXci+
LXGTRADwwhMFjA036aobP8U=
=0Nz3
-----END PGP SIGNATURE-----
--
Andy Kurth
Virtual Computing Lab
Office of Information Technology
North Carolina State University
andy_ku...@ncsu.edu
919.513.4090
