Present: Petr V, Angela C-B, Enrico V, Maarten L, Linda C, Roberta M, Jim B, Berk B, Jules, Alexandre B, Tom D (Notes)

Apologies: Dave K, Dave C, Hannah S

Meeting Schedule:

• Tom will look to schedule Thursday meetings following the poll. Will set up some Zoom Meetings and email the details.

Following on From IAM Hackathon:

• 1.8.1 almost ready for release, with image targetted for end of this month
• full release details will be on GitHub, and release notes will be published accordingly
• Including what is planned for 1.8.2 release
• Potential release schedule aligning with a quarter-ish
• The aim is that once something useful or relevant is available it can be released - every two or three months, due to inexpensive release process
• The most difficult part is documentation changes, and this takes time

Maarten: request to look into tokens for XRootD token monitoring

• Details on use in OSG: https://osg-htc.org/docs/data/xrootd/install-shoveler/#configuring-security
• Aim is to follow this to do-away with certificate usage in EGI
• Sites which want to participate (those with XRootD or DCache) will need a "Shoveller" service, which sends messages to a central CERN queue (AMQ)
• This is probably dooable, but will likely need a dedicated IAM instance to manage
  • Likely to have low access rates.
  • Currently Shovellers have a year-long certificate, and so the admin must do tasks once per year
  • Sufficiently lived tokens will keep the request rate low
• In discussions with the person at the CERN side who receives messages, said that it would need a significant amount of development, as well as in the software (AMQ)
• No urgency - existing solution can be "tolerated" for some time still
• Logically shoveller can be a seperate node
  • In monitoring, messages are sent by XRootD as UDP packages - possible for these to get lost
  • This is what the current monitoring does - issues around package loss
  • In new system Shoveller situated nearby, reducing loss. This can then open a TCP connection
• Petr: should consider whether tokens are easier in this situation, or not
  • Can know that we can make this work, and that the use case is not crazy
  • Certificates will be needed for other secure services, so need to be sure it's not unreasonable to keep them in use here

Storage Path e-mail discussion

• Petr: unsure as to situation. Same namespace, avoiding prefix, but including VO name
• Maarten: came from a longer discussion last week, notes that details may not be expressed completely clear
• Have an opportunity to do better than we have been doing for the past 15 years.
• Must know how a particular service is implemented and how the name space starts
  • This should have been hidden
  • issue is that the "easiest" solution is to keep with it, and thus may not go away
• Discussion led to ticket "rediscovery" and it's update. Issue may have simplified for LHC-B
• Could be worth a review from others, and understand what can be changed and thus simplified
• Previously impossible to have different prefix in DPM - not sure if this is possible in other things
  • Maarten notes that in ALICE, the prefix should be ignored and be kept hidden from the client - a configuration option
  • Should be checked for other services, such as STORM
    • Enirco notes that it is supported to remove the /webdav in storm - was unsupported a while ago, the first part is the name of the VO
    • https://xfer.cr.cnaf.infn.it:8443/atlas/atlasdatadisk - can remove the prefix Webdav in this scenario
• Should have a "smart" implementation where the full (including prefix) path is still understood. Could be important, though not likely on the critical path

Overload of Atlas instance

• Still seeing same number of tokens within Harvester, though IAM has been adjusted
• Will need to make the service more robust - ideally not storing tokens in the database.
• Need to understand reasonable usage patterns, to not put the service under excess stress
• Find a sweet spot for IAM, and other services, which is best for a security and operational perspective
• Petr notes that as anyone can create a client and request tokens, this means that he is not sure always which client tokens are associated with
  • issue with disabling means that IAM administrator needs to approve all workflows
  • which limits the number of users which can try tokens with tools like OIDCAgent
• Petr notes that the key issue is monitoring IAM
  • watch for inappropriate usage to watch for clients request too many tokens and how they are stored in the database