Bug 1480653

Summary: Worm File Level policy won't work with Gluster-SWIFT
Product: [Community] GlusterFS Reporter: Abdalla <gabriel.cavalcante88>
Component: object-storageAssignee: bugs <bugs>
Status: CLOSED EOL QA Contact:
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.10CC: bugs, luneo7
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Abdalla 2017-08-11 15:00:38 UTC
Description of problem: Hello Folks, I'm trying to use gluster-swift with a worm file level enabled volume on gluster FS; If I make changes using the filesystem, the files inside the volume become RO as expected; if I use the gluster-swift api to PUT the file, the old file is updated with the content of the new file, even with auto-commit-period 1.


Version-Release number of selected component (if applicable): Centos 7 Containers, Gluster 3.10 installed from the centos-release-gluster310 repo.


How reproducible:


Steps to Reproduce:
1. Create a volume with a file-level worm policy, using the commands:

 * gluster vol create test storage1:/export/sdb1/test storage2:/export/sdb1/test
 * gluster volume set test features.worm off
 * gluster volume set test features.worm-file-level on
 * gluster volume set test features.retention-mode enterprise
 * gluster volume set test features.auto-commit-period 1
 * gluster volume set test features.default-retention-period 600
 * gluster vol start test

2. Mount the volume in a container that will be the gluster-swift server:

 * mkdir -p /mnt/gluster-object/test/
 * mount -t glusterfs storage1:test /mnt/gluster-object/test/

3. Install, create rings and start gluster-swift as stated in: https://github.com/gluster/gluster-swift/blob/master/doc/markdown/quick_start_guide.md

4. From the gluster-swift docker container, create a swift container inside the account:

curl -i -X PUT http://localhost:8080/v1/AUTH_test/test

5. Create and Send the object:

echo 'my test' > file.txt
curl -i -X PUT -T file.txt http://localhost:8080/v1/AUTH_test/test/file.txt

Returns 201 Created.

6. Try to send the same object again:
echo 'test gain' > file.txt
curl -i -X PUT -T file.txt http://localhost:8080/v1/AUTH_test/test/file.txt

Returns 201 Created.


Actual results:

The file is written by the gluster-swift into the /mnt/gluster-object/test/ folder normally, even after the auto commit period.

If we try to change the file directly on the mount point (fs level), it returns the expected 'read-only filesystem' message.

Expected results:

Gluster-swift shouldn't be able to change the file after commit period and the proxy server should return a 503/500 error to the client when he tries to send the same object after the commit period. (In the future we can make a PR with the correct exception for this case).


Additional info:

Using a worm policy by volume works as intended: gluster-swift returns 503 errors because it can't move the temp files into the final file. (In the future this behaviour need to be treated, but servers as a proof of concept for us).

Comment 1 Abdalla 2017-08-11 15:18:21 UTC
All files used to test the behavious are available at the following git repository:

http://gitlab.ts3corp.com.br/TS3CORP/gluster.git

Comment 2 Lucas Ferreira 2017-08-14 12:56:51 UTC
I think this is related to you being able to do a mv command and overwrite a file, so it's related to this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1480788

Comment 3 Lucas Ferreira 2017-08-14 17:12:12 UTC
Until the mv command if fixed, there is a workaround, I made a pull request for that workaround (https://github.com/gluster/gluster-swift/pull/4)

Comment 4 Lucas Ferreira 2017-08-23 20:32:12 UTC
Following the guidelines I did a pull request using gerrit (https://review.gluster.org/#/c/18109/)

Comment 5 Shyamsundar 2018-06-20 18:27:55 UTC
This bug reported is against a version of Gluster that is no longer maintained (or has been EOL'd). See https://www.gluster.org/release-schedule/ for the versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline gluster repository, request that it be reopened and the Version field be marked appropriately.

Comment 6 Shyamsundar 2018-06-20 18:28:01 UTC
This bug reported is against a version of Gluster that is no longer maintained
(or has been EOL'd). See https://www.gluster.org/release-schedule/ for the
versions currently maintained.

As a result this bug is being closed.

If the bug persists on a maintained version of gluster or against the mainline
gluster repository, request that it be reopened and the Version field be marked
appropriately.