Check if the value generated using custom UUID is unique; re-try creation otherwise

[shubham-pampattiwar]

Ref discussion: #101 (comment)

[shawn-hurley]

Now that we are using labels for the connection between the two, can we use generate name and have the api server deal with this?

[mateusoliveira43]

@shawn-hurley I think that is a good idea. We currently use the value of the label also as the object name (which is 63 char length, but could be 253 char length). Is there a function in the libraries we use that already implements this for us?

[kaovilai]

Per my comments earlier, apiserver already has retry logic on generateName it creates for objects. I believe Shawn is not asking us to use any libs to implement this.. but to create object without specifying name. Just the generateName in metadata.

Generated values
Some values of an object are typically generated before the object is persisted. It is important not to rely upon the values of these fields set by a dry-run request, since these values will likely be different in dry-run mode from when the real request is made. Some of these fields are:

name: if generateName is set, name will have a unique random name

src

[mpryc]

From what is worth I think the retry logic on name is a very corner case now, so I would focus on more important issues to be addressed first.

[kaovilai]

I think this is less about discussing retry (that you consider to be corner case) specifically, but to remove the need for UUID code to exists inside NAC. Just use name generated via generateName from apiserver.

[shubham-pampattiwar]

@kaovilai partially correct. Yes we can use GenerateName instead of using custom UUID for name. Currently custom UUID is used for establishing NAB - VB mapping and also for NAB name (but not a necessity here). GenerateName would be an improvement but we still need custom UUID for mapping purposes we already discussed. So yes we could use GenerateName for NAB name but custom UUID code still needs to reside. Hope this clears up any confusion on this.

[kaovilai]

User create NAB

• NAB creates VeleroBackup with only generateName and without specifying name with label created-by-nab: <nab-name>
  • NAC lists VeleroBackup created by NAB by label created-by-nab: <nab-name> as needed.
    • Since VeleroBackup name came from generateName (which apiServer already retries for a different name if collide with existing VeleroBackup), we do not need a UUID logic inside NAC.

[shubham-pampattiwar]

yes this wasn't the issue, the problem would arise when we try to sync backups across clusters and in that case we wanted to avoid collisions, thats why we ended up using custom UUID.

[kaovilai]

If NAB syncs across cluster, wouldn't the apiserver generateName logic work in both clusters if both are synced to have the same NABs in the cluster?

[kaovilai]

Anyway yes as mpyrc said prob more important issues.. I just get excited at deleting code.

[kaovilai]

If NABs do not sync across cluster, it would be interesting to see how one cluster's NAC read the other.