Choose timezone
Your profile timezone:
Powered by Indico
v3.3.2-pre
# Collaboration Meeting - 2/3/2017
[Agenda](https://indico.cern.ch/event/617972/)
## General News
Andrea: Argus is one of the production services that should be included in the proposal for EINFRA-12 call
* Would help if WLCG could express that ARGUS is a critical service
* The same for EGI
* Emphasize that Argus is infrastructure-agnostic and is the basis for the all the infrastructure we depend on (grid, INDIGO)
* Peter and Andrea are discussing what the project could provide to Argus and send next week a short description of what is planned that will be sent to WLCG
* If Argus is included and the project is funded, would provide some funding for Argus support after INDIGO end
NIKHEF: new team member joining today...
* Exact responsibility still to be discussed but will lower the pressure on Mischa!
## CA LoA Support
Two proposals on the table and described in a comparable way:
- [Andrea](https://docs.google.com/document/d/1lT-ppRRb6AIINBq4GtScwvDVxsC52jhyBIeCsNri7JI/edit#heading=h.c6j5k9a20ol4)
- [Misha](https://docs.google.com/document/d/1aYf3-oTrWek83wmZgxzEIMCdmvVEMZH0EZ-pLgB34vk/edit#heading=h.c6j5k9a20ol4)
Most of the work done so far has been done by Mischa, is CNAF committed to do the development and support if Andrea's proposal is chosen?
* Andrea: sure, CNAF is committed to support any solution chosen in fact...
Peter: not only the technical details must be taken into consideration, also the timeline to implement it
* Becoming urgent, even if there is not yet a clear deadline...
* A requirement for accepting certificates from the RCauth CA (currently a prototype at NIKHEF) on the infrastructure.
* Andrea: development time is approximately the same, the main code to identify the IOTA CA and set attributes will be Mischa's code in both cases.
* Main difference is the attributes set and when they are set
* One week of development required, meaning 3 calendar weeks
* Peter: a solution ready by end of March is acceptable
Main difference in both approaches
* Mischa's proposal: PIP only retrieve the policy names from the INFO file but doesn't say if it is a IOTA or not (done in PAP). Agnostic to LoA.
* The proposed Python script to update the PAP policy will be in charge of setting the right value to match for the ca_policy_names attribute.
* Andrea's proposal requires the PIP to do the mapping between policy and LoA
* Plan is to have the mapping information in the PIP configuration file
* Also need a different script to update the PAP from the EGI-provided list of VOs eligible for IOTA CAs
* No consensus yet whether this is really required
* In fact, in Andrea's proposal the eligibility of a VO for a given policy could be optionally be assessed in the PIP, using the EGI RPM, without the need of separate rules for IOTA CAs, if this is enough to do it at the VO level (no flexibility to have different policies for different resources but probably possible for different FQANs in the VO). This third approach could be a first step.
Decision : start with the third proposal (leverage [EGI VO-CA-AP file](https://wiki.nikhef.nl/grid/Lcmaps-plugins-vo-ca-ap#vo-ca-ap-file))
* In the next days, Andrea writes the third proposal as a Google Doc in the same format of others
* Andrea checks if the EGI file format is appropriate and complete and reports to Mischa
* Preliminary work of implementation and feedback by 2 weeks
## AOB
GGUS support line monitoring for Argus was broken because there were no open tickets! A "luxury" problem to have! :-)
Next meeting: March 17, 1:30 pm