cc @houhoucoop

I can see 500 when attempting to back up the same image twice.
"message": "failed to create backup backing image 'parrot': backup backing image 'parrot' already exists"

Since it's a 500 error, I think the root cause is likely on the backend side.

I can see 500 when attempting to back up the same image twice. "message": "failed to create backup backing image 'parrot': backup backing image 'parrot' already exists"

It doesn't seem to be what I encountered. Also I observed inconsistent behavior when trying to back up from the following two locations. Could you try both of them?

These are all the cases I have tested, not sure which ones are expected and which are defects.

Case 1: One backup target: default

• Backup single backing image
  • If the backup exists: 500 (backup already exists)
  • If the backup does not exist: 200 (success)

Case 2: Multiple backup targets: default, cifs

• Backup the same backing image
  • Select backup target default: 200 (success)
  • Select backup target cifs 500 (backup already exists)

Case 3: Bulk backup action:

• Attempt bulk backup for one or multiple backing images
  • Select one backing image 500 (EOF)
  • Select multiple backing images 500 (EOF)

cc @a110605 @mantissahz ^

@mantissahz Can you confirm if Case 2 is a defect? frontend needs to make corresponding UI adjustments.

@mantissahz Can you confirm if Case 2 is a defect? frontend needs to make corresponding UI adjustments.

It is not allowed because UI creates the BackupBackingImage of a backing image using the same BackupBackingImage name (the backing name) for different backup targets.

1. UI can allow users to fill in a custom name when (and passed it by the payload) creating a backup backing image.
   https://github.com/longhorn/longhorn-manager/blob/5187ffde3c6c2d009b5406db7193966463505b46/api/model.go#L180-L196.

2. or the Backend can use a random name to create the BackupBackingImage, then UI displays the
   name of a BackupBackingImage by the backing image name in the response payload.

@mantissahz Can you confirm if Case 2 is a defect? frontend needs to make corresponding UI adjustments.

It is not allowed because UI creates the BackupBackingImage of a backing image using the same BackupBackingImage name (the backing name) for different backup targets.

1. UI can allow users to fill in a custom name when (and passed it by the payload) creating a backup backing image.
   https://github.com/longhorn/longhorn-manager/blob/5187ffde3c6c2d009b5406db7193966463505b46/api/model.go#L180-L196.
2. or the Backend can use a random name to create the BackupBackingImage, then UI displays the
   name of a BackupBackingImage by the backing image name in the response payload.

I see, I prefer option 2.
After checking the frontend code, we don't generate UUIDs, so generating them on backend may ensure more consistency. What do you think?

I see, I prefer option 2.
After checking the frontend code, we don't generate UUIDs, so generating them on backend may ensure more consistency. What do you think?

The backend can handle that if the name in the request payload is empty or equal to the backing image name, it will generate a random name to create a backup of the backing image.

The UI can still allow users to have a costume BackupBackingName name when creating a backup of the backing image if you want to.

I will fix the backend part tomorrow

Pre Ready-For-Testing Checklist

• Where is the reproduce steps/test steps documented?
  The reproduce steps/test steps are at:

All operations can be done via UI

1. Create a parrot BackingImage
2. Setup two different BackupTarget: s3 and nfs
3. Create two backups from the UI with two different BackupTargets
4. Two BackupBackingImages are created successfully with parrot-XXXXX
5. Delete the parrot BackingImage
6. Restore the BackupBackingImage (Both should work)
7. parrot is restored.

PR:

• fix: add data engine option to restore backing image api longhorn-manager#3392

Recent issues are mostly related to the APIs and the integration between the backend and frontend.

@houhoucoop @a110605 In addition to implementing the UI part, remember to self-validate if the functionalities work before moving it to ready-for-testing. This will make you familiar with Longhorn more.

cc @a110605 @ChanYiLin @mantissahz @innobead