----- Original Message ----- > From: "Gandalf Corvotempesta" <gandalf.corvotempesta@xxxxxxxxx> > To: "Prashanth Pai" <ppai@xxxxxxxxxx> > Cc: "John Mark Walker" <johnmark@xxxxxxxxxxxx>, "gluster-users" <Gluster-users@xxxxxxxxxxx> > Sent: Thursday, 29 September, 2016 3:55:18 PM > Subject: Re: Minio as object storage > > 2016-09-29 12:22 GMT+02:00 Prashanth Pai <ppai@xxxxxxxxxx>: > > 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. _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
