# ARGUS Collaboration Meeting - 9/10/2015
## General News
* Selection process restarted for the hired person that did not come
* The other person (Marco) has started and will work partly on ARGUS
* UMD-4 still being build: small delay
* Internal testbed will use Puppet
* BDII already verified
* First announcement postponed
## EL7 and Java8 Support
Update of dependencies (Jetty, VOMS, Canl) completed for all components
* No stress tests done yet
* To build the real packages, need to push the last version of dependencies to the repos
* Packages available for beta testing
* CERN ready to do it in some production-like environment
* Put these packages in UMD-4 repos as soon as we are confident there is no known flaw: need to provide an automatic test suite
* No YAIM config provided with the new packages: need to rely on Puppet, Quattor or something else
* Configuration files not changed since last version
* Need to be stated clearly for sites who may want to migrate
* No functional change: only a few minor fixes
Client/server compatibility matrix using the ARGUS test suite
* Still fixing some of the tests that seem impossible to succeed
* Run through a Jenkins instance
* The new person at CNAF also spotted a few changes required: would be good to coordinate
## Open Issues - New needs
* Hypothesis last month was that CMS VOBOX was calling ARGUS with its own cert (no VOMS extension) rather than the user cert, confusing/overloading ARGUS... Almost clear that this is not the only trigger.
* Cause for the CMS problem remains to be understood... still tuned
* Recent analysis showed that an additional problem was that when the ARGUS server was unresponsive, CREAM would remember it during a significant period (up to several hours if unlucky).
* when CREAM was complaining about impossibility of getting a pepd answer, using the pep client would work on the same machine...
* Problem in the pep Java client? connection reused?
* Some tuning on one CE was done: need to wait next incident to see the exact impact
* ARGUS overload seen recently due to many WNs contacting the server at the same time (glexec): may be connected to some application workflow, to be analyzed
* NFS used for the shared gridmapdir may be the bottleneck in this kind of situation: in this case, ARGUS is more a victim than a culprit, may require improving ARGUS to use a database rather than the legacy gridmapdir. In fact planned in INDIGO.
* NFS/gridmapdir is not involved in the CMS VOBOX problem
Andrea : the ARGUS Java client library may rely on a http client library that may be old and not used by any other component. Should look at it
* First guess: the problem seen on CREAM at CERN may be related to a connection pooling problem
Extending the policy engine to support authz in IOTA context (see Misha's email after last meeting): decision based on VO+CA
* Andrea: should be no major problem to add the support for this. Need to agree on what we want to do exactly.
* Could be a good use case to demonstrate ARGUS ability to address different use cases
Add Marco to GGUS support unit and to ARGUS future discussion list.
Next meeting: November 6, 2 pm CET
* Agreement to continue with this monthly meeting with the generally the first Friday of the month as the probable date