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

Reply via email to