hmmm... I guess we need to think of id generation differently for each provider type to make sense of the ID.
On Fri, May 31, 2013 at 10:44 PM, Suresh Marru <[email protected]> wrote: > On May 31, 2013, at 10:33 PM, Danushka Menikkumbura < > [email protected]> wrote: > > > UUID is good enough IMO and based on its version it could include the > > timestamp, MAC address, etc. > > Yes UUID is enough, but looks like Saminda is after a pretty looking UUID > algorithm. Pretty is subjective here. > > > > > Danushka > > > > > > On Sat, Jun 1, 2013 at 7:58 AM, Suresh Marru <[email protected]> wrote: > > > >> Superficially, every process will have a ID. The local and ssh jobs > have a > >> unix process id. EC2 has InstanceID, Unicore has a job id and so on. I > do > >> not have any pretty ID generation suggestion. The pretest I know off > beyond > >> UUID is the time in milliseconds:) > >> > >> Suresh > >> On May 31, 2013, at 9:59 PM, Lahiru Gunathilake <[email protected]> > wrote: > >> > >>> JobID is only applicable for Gram Jobs. > >>> > >>> Lahiru > >>> > >>> > >>> On Fri, May 31, 2013 at 6:28 PM, Saminda Wijeratne <[email protected] > >>> wrote: > >>> > >>>> Hi Devs, > >>>> > >>>> Some GFac Providers do not have a job id returned when a job is > >> submitted > >>>> (eg: EC2Provider). If we are to persist the job data for these > >> providers we > >>>> need to have a job id unique for the job table. Any suggestions on a > >> good > >>>> generation algorithm which wouldn't look so ugly as a UUID? > >>>> > >>>> Saminda > >>>> > >>> > >>> > >>> > >>> -- > >>> System Analyst Programmer > >>> PTI Lab > >>> Indiana University > >> > >> > >
