louis-gounot
commented
9 years ago As far as I've understood supermarket, it stores content in an object store (S3 implementation supported right now) thus solving content sharing between instances. That said, it doesn't help so much when you don't have an S3 compatible object store behind the firewall (as it is the case in my company). When using local storage, supermarket stores content inside public/system rails directory and this directory is not managed by supermarket-ctl reconfigure (you need to create it by hand and chown it to supermarket user). I suggest to have public/system directory managed through supermarket-ctl reconfigure with two options, if the attribute value is nil, then store directly in public/system directory (created by cookbook with proper rights), else (attribute is set to some custom directory) ensure the target directory is present and has proper rights + symlink public/system directory to it. I choosed /var/opt/supermarket/content as storage directory for my private supermarket. It will solve the local storage issue out of the box and allow the system administrator to have whichever FS backend he wants (NFS, SAN, LVM, Ceph RBD, Gluster, ...). What do you think about it ?
smith
As a system administrator of a Supermarket instance, I want to be able to run multiple app servers and store cookbooks on a shared filesystem.
I should be able to specify the filesystem path at which uploaded cookbooks are stored. I then can use a facility of my choice (SAN, NFS, etc.) to ensure anybody who accesses any application server node gets the same files.