After presentation:

Q (Baosong Shan): For the "project" area will there be one instance or more?
A (Jan): in general, number of instances to be kept low.
A (Jan,Luca): negotiable, AMS might get its own instance since already "big".

Q (Baosong): When will EOSPROJECT be ready for testing?
A (Luca): Probably from March

Q (Baosong): Can we test FUSEX+QuarkDB namespace before?
A: Yes, on user/service account home directories - already running the new combination.

Q: Could some users start earlier with testing?
A: Sure. For different communities, arrangements can be made for testing

Q: What if there are plenty of references to different locations? Moving might mean everything or nothing.
A (Massimo): Symlinks should still work as replacement for volume mounts inside AFS, etc.
A (Jan): Only a few of the tools are aware about volume mounts. To prevent unwanted volume traversal, could replace them with symlinks; at filesystem-level this should not break anything (unless being AFS admins and using "vos release" etc)

Q: (Frank Locci) BE-CO client machines would need to be up to date with the latest client but are snapshotted.. What to do in order to do this on prod machines which are staged/snapshotted?
A: Suggest to freeze the version that is at the point in time seeming to be bug-free; update when an important bug in the client is fixed for you. Similar model to LXPLUS=LXBATCH (frequent updates) and Linux desktops (which see fewer versions)

Q (Elena Gianolio): What about the AFS web sites?
A: Agreement with the Web team: migration mostly driven by the Web Team => pointer (i.e URL redirector) could be changed almost at the same time as the website data; would still need validation from the user => test link to be tested => OK from user, before making to prod
   Also: the Web Team is investigating containers, which might provide more security to the websites (would no longer using the same shared identity for allowing the web server access)