-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I created VCL-102 for this.
Josh On Thu March 5 2009 11:17:47 am Aaron Peeler wrote: > Sounds good - lets do it. > > 'systemuser' as a name works for me. I can't think of any conflicts. > > Aaron > > > > --On March 5, 2009 11:11:30 AM -0500 Josh Thompson <josh_thomp...@ncsu.edu> > > wrote: > > -----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----- > > Aaron Peeler > OIT Advanced Computing > College of Engineering-NCSU > 919.513.4571 > http://vcl.ncsu.edu - -- - ------------------------------- 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) iD8DBQFJsAN0V/LQcNdtPQMRAlYwAJwNfV9sB5N9Ort67LRbpOat3FNJFACffRpw vWAL8jMjWYmRwxQ3uqFvyfg= =k5K+ -----END PGP SIGNATURE-----
