Uploaded image for project: 'FTS'
  1. FTS
  2. FTS-372

Namespaced uuid version 5 for Atlas



    • New Feature
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • None
    • fts-rest 3.4.1
    • REST API
    • Security Level: Public Data (This ticket is visible to anyone on the internet and will be indexed by search engines)
    • None
    • 4
    • FTS & DMC - 10


      Different uuid versions are guaranteed not to clash (since there are bits reserved to specify the uuid version)
      Provided a namespace per vo+fts3 (i.e. md5 hash of the vo name+fts3 name), and using any random value provided by the VO (i.e Rucio internal request id), then the uuid will be unique (with high probability, of course), and will be reproducible. Therefore, Rucio will be able to double-check if the job was submitted or not if they missed the confirmation.
      Even if they didn't, if they resubmit, this feature will avoid duplicated transfers.

      Other VOs will not care, since they will keep using version 4 (random)

      Of course, we give away the guarantee of uniqueness in time, and delegate this to the VO, since once the job is deleted from the DB, it could be reused.

      From FTS3, this could affect the backup table, though, if they reuse their id after the job lands in it. We could either check on submission (how fast would that be??) or need to be resilient to duplications when running the backup (ON DUPLICATE IGNORE ?).

      Rucio will need to take care by themselves about possible duplicated job ids separated by long periods of time. I doubt that would be problematic, though.





            marsuaga Maria Arsuaga Rios
            aalvarez Alejandro Alvarez Ayllon (Inactive)
            0 Vote for this issue
            4 Start watching this issue