colorado.xsede.org content is updated by the the local 'colorado' account based on configured CVMFS privileges and unix permissions
Might want to rename 'colorado' to "cvmfs_colorado' or something similar to separate it from the XSEDE username space
Since we would likely have multiple use cases and publishers ask OSG:
What are the costs for having multiple top levels exports besides 'colorado.xsede.org'?
Can a single server host and publish multiple top levels?
Use Cases
The five likely CVMFS use cases identified by Lee are: RC-08, -09, -10, and SPI-11 and -12
The RC ones are the researcher ones (using content), the SPI ones are the service provider ones (hosting content)
Publishing use cases
Could be published by XSEDE SPs, XSEDE itself, or XSEDE allocated projects
Publishers, such as service providers, could publish directly on their own with XSEDE involvement if they have the capability to do so
Publishers could use an XSEDE wide publishing server if they can't publish on their own, like XSEDE allocated projects or community software software owners
Would be good for Lee, Jeff, Shava, and JP to review the use cases to see if they can be made more specific (narrows) or if anything in the use cases is just plain wrong
Derek suggested we focus on use cases that CVMFS is designed for and not get sidetracked by other things that it could be used for, like distributing packaged software
Community software areas owners who don't have the ability to run their own servers could use XSEDE's CVMFS
This would be a supplement to a local network file-system community software area typically used to share HPC software
XSEDE SPs typically install HPC software on a local network file-system (like onto ceph using spac at SDSC)
Installing in CVMFS would make that software available across HPC systems
Managing Content
Steps on cvmfs.xsede.org for the 'colorado' user to publish:
Configure CVMFS with the account that owns and can modify the contents of 'colorado.xsede.org'
The owner start an update transaction with command "cvmfs_server transaction colorado.xsede.org"
This mounts /cvmfs/colorado.xsede.org which the owner has write access to
The owner modifies contents
The owner closes transaction by running "cvmfs_server publish"
Security considerations:
Server logins should follow standard login logging practices
We need audit logs of who update files: either who used sudo or whatever cvmfs logs
Alternate content management approach:
By default the owner updates themounted file-system directly as shown above e
Have a separate local file-system protected using standard permission and updated first
Use a sudo wrapped command that initiates the transaction, rsync's to local file-system to the publishing file-system, and terminates the transaction
Don't see any immediate value for in using GCS v5 to put content on the server
Encourage SPs who have the ability to publish on their own to do so directly through OSG and not rely on XSEDE
Production platform
Pilot is on Jetstream
Production could be on Jetstream2 or AWS
Jim recommended a pilot report to hand over to ACCESS rather than implementing in production before the end of XSEDE.