[Gluster-users] Minio as object storage

[Prashanth Pai]

----- Original Message -----
> From: "Gandalf Corvotempesta" <gandalf.corvotempesta at gmail.com>
> To: "Prashanth Pai" <ppai at redhat.com>
> Cc: "John Mark Walker" <johnmark at johnmark.org>, "gluster-users" <Gluster-users at gluster.org>
> Sent: Thursday, 29 September, 2016 3:55:18 PM
> Subject: Re: [Gluster-users] Minio as object storage
> 
> 2016-09-29 12:22 GMT+02:00 Prashanth Pai <ppai at redhat.com>:
> > In pure vanilla Swift, ACL information is stored in container DBs (sqlite)
> > In gluster-swift, ACLs are stored in the extended attribute of the
> > directory.
> 
> So, as long the directory is stored on gluster, gluster makes this redundant
> 
> > This can be easily done using haproxy.
> 
> The only thing to do is spawn multiple VMs with gluster-switft
> pointing to the same gluster volume,
> nothing else, as exattr are stored on gluster and thus readable by all
> VMs and HAproxy will balance the requests.
> 
> Right ? A sort of spawn&play :)
> 

Correct. gluster-swift itself is pretty much stateless here
and uses glusterfs for storing all user related data.

You can also choose between two auth systems - tempauth
and gswauth. Tempauth stores usernames and password (plaintext!)
in a conf file at /etc/swift while gswauth uses a dedicated
glusterfs volume to store username and password (hashed).

The ACL information is stored in xattrs regardless of which of
the above two auth mechanisms you choose to use.

gluster-swift has it's configurations files at /etc/swift
and also has ring files there. These ring files determine
which volumes are made available over swift interface.

If you have 10 volumes, you can choose to make only few
of them available over object interface.