-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue March 3 2009 10:00:03 am Andy Kurth wrote: > > 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?
Actually, the backend isn't using the XML RPC API for anything right now. For the block reservation API that I'm currently working on (and for anything else in the future), I think whatever we determine in this thread should be used as the account with which the backend authenticates to the frontend. > 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. Correct. - From what Aaron said in his response about the number of locations vclreload is used in the backend code, it sounds like renaming it to something like 'systemuser' would not be too difficult. We'd need to create a JIRA issue for it and coordinate working on that issue on the frontend, database, and backend all at the same time. How does that sound? Josh - -- - ------------------------------- 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 www.keyserver.net -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iD8DBQFJr/m2V/LQcNdtPQMRAo5HAJ9D+CuXoDx8dI0A7Pl78O2Y2LQ7RgCfXoT9 bMeypAsQ1uwNNpr0kqAqfWg= =uheL -----END PGP SIGNATURE-----
