Juniper Openstack

Duplicate image upload to swift shouldn't happen

  1. Series trunk
  2. Bug #1787494
Bug #1787494 reported by Sahana Sekhar Palagrahara Chandrashekar
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Juniper Openstack
Status tracked in Trunk
R5.0
Won't Fix
High
Radosław Romaszewski
Juniper Openstack r5.0.2
Trunk
New
High
Radosław Romaszewski
Juniper Openstack r5.1.0

Bug Description

If the image is already present in the container, the same image shouldn't be uploaded again.
The UI needs to always query the database first before uploading the image.

See original description
Sahana Sekhar Palagrahara Chandrashekar (sahanas)
Changed in opencontrail:
importance: Undecided → High
assignee: nobody → Sarin Kizhakkepurayil (sarink)
description: updated
Revision history for this message
Sarin Kizhakkepurayil (sarink) wrote :

challenge is we upload to swift first and then we try to create the device-image and in this case backend API will fail when fq_name matches with existing.

UI can not be doing "check" first, then upload then create as its sub-optimal. we could see option to delete uploaded if device-image creation fails

ideally there should be a single API than baking into UI all this business logic.

Revision history for this message
Sahana Sekhar Palagrahara Chandrashekar (sahanas) wrote :

The fq_name can be different for the same image right? The fq_name is what the user supplies. So if the user uploads the same image with different fq_name, it is still a duplicate. The device-image will get created anyway.

Jeba Paulaiyan (jebap)
no longer affects: opencontrail
tags: added: contrail-command fabric
Revision history for this message
Sarin Kizhakkepurayil (sarink) wrote :

@Radek, as discussed in the call,

lets,
1.remove the uuid addition to name
2.create device-image object to config first
3.upload to swift
4.update the device-image with url from swift.
5. additionally, while listing when the url is not set, disable the image row.

since this is change in the workflow, we're targeting this in 5.1 and not disturb 5.0

Revision history for this message
Sarin Kizhakkepurayil (sarink) wrote :

May be we will backport to 5.0 once 5.0.2 is out. may be for 5.0.3 release

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.