Add possibility to tag objects.

[csc-felipe]

Description

This is a continuation to the tagging buckets feature from PR #419. The implementation is very similar.

The openApi spec supports tuples in 3.1 with prefixItems. We may want to change the api docs when that comes into use.

It does only one request to fetch metadata for all objects in a bucket.

NB: Please, check the Finnish language :)

Related issues

Is #5 solved with this?

• Use openApi 3.1 tuple definition #427

Type of change

• New feature (non-breaking change which adds functionality)

Changes Made

Added backend for updating metadata for an object. Added UI for displaying tags for objects, as well as hiding them. There is a new button, called 'Edit', which makes it possible to edit an object's tags.

Previously, the api docs for container update metadata had gone to the wrong place. The fix is in this PR :)

Testing

• Unit Tests
• Integration Tests

Mentions

[blankdots]

The openApi spec supports tuples in 3.1 with prefixItems. We may want to change the api docs when that comes into use.

Add an issue to keep track of this.

It does only one request to fetch metadata for all objects in a bucket.

How does this perform with a lot of objects ?

We sometimes use container sometimes bucket in the API specs. We should be a bit more consistent.

Other than that LGTM

[blankdots]

Suggested change

	description: The container which contains the objects to be updated.
	description: The container which consists of the objects to be updated.

[csc-felipe]

@sampsapenna had offered to stress test with lots of objects and containers. Could you check it out, please?

I would expect that it takes a few seconds to load the tags, similar to how it takes a few seconds to load the object table.

Created a couple of issues:

• Consistency in terminology #428
• Use openApi 3.1 tuple definition #427

[sampsapenna]

@sampsapenna had offered to stress test with lots of objects and containers. Could you check it out, please?

I would expect that it takes a few seconds to load the tags, similar to how it takes a few seconds to load the object table.

Created a couple of issues:

• Consistency in terminology #428
• Use openApi 3.1 tuple definition #427

Did some stress testing – we'll have to change the existing implementation of objects in query string if we want to fetch the whole container with one request. Depending on the object names it smashes through the URL size caps even with as few as 200 containers. Alternatively splitting the requests up is also an option. The performance is good until it runs into the URL issues. After the change takes place I can test it with a couple worst case scenarios.

8192 bytes is apparently the default limit for aiohttp – 2048, however, is the recommended cap.

[sampsapenna]

Unfortunately the Openstack API specification caps the object name to 1024 characters, so that means we can't reliably put even two objects into one request if we want to stay under the 2048 mark. Chrome is fine with 32KiB of content in the address, Firefox can deal with even more – so from the browser side we can go with higher assumptions without an issue.

I'd guess that the HAProxy in use is configured to complain sooner, just like aiohttp does.

[csc-felipe]

Thanks for testing, @sampsapenna. I did think this might be an issue. The most natural for me here would be to move objects to the body, but it's usually better not to change the API, so I'll split the requests, checking for the lower 2048 limit from aiohttp.

[csc-felipe]

Noticed a few issues while implementing the filtering. Edit button was showing in the folder list, folder with tag, object tags not properly deleting all the tags, leaving a tag with empty value because of inconsistency in the swift backend.

Hopefully all issues are gone now.

[csc-felipe]

This looks like the same feature #85.

[blankdots]

we need to display a message, in a different PR, that a title is not editable at the moment.

[blankdots]

i think commit e147318 is from PR #429 , or looks like it

[csc-felipe]

think commit e147318 is from PR #429, or looks like it

I made a branch demo/tags with commits from this PR and the filtering PR to use in a demo. That filtering commit was not pushed to this PR. The message here was that this PR was referenced in that same filter commit on the other branch.

[sampsapenna]

Tagging functionality works nicely, and does not prevent UI usage. Would be nice to be able to cancel the tag fetch when changing routes, to prevent performance issues with the filled event loop. Not sure how easily this would be implemented, though.

[csc-felipe]

Would be nice to be able to cancel the tag fetch when changing routes, to prevent performance issues with the filled event loop.

I will investigate.