Discussion

Vision & Simplification

Chas opened the call by suggesting that to be successful in "getting this working," deploying multiple different versions may be effective in helping decide which architectures are more effective than others. He also wants other communities involved deeply in the project, suggesting agents for Shibboleth, directories, grids, and many other architectures to explore the power of the tool and ensure that it works for these designs.

In an effort to simplify the architecture, collection models' configuration data will be stored locally. The API will also be greatly reduced for the first version to support simple querying and filtering, but will still connect in real-time. It's still unclear how authentication will be handled. There will be close attention on dependencies and an effort to make the entire platform as lightweight and independent as possible.

The intention is to store collected diagnostic information local to the individual machine, as well. While it's Chas' personal opinion that "we're biting off more than we can chew if we're talking about a database," the architecture itself will be flexible enough to support this sort of elaboration if a deployer deems it necessary. Von concurred and added that he found the rest of the modifications reasonable.

The applications that could be built upon this powerful, simplified base seemed obvious, and include the first priority of a forensic application. General reporting and other applications could follow if development resources and timeframes prove sufficient. Chas intends to eventually farm off three efforts: people writing collection agents, others evolving the core, and a third group writing applications for the backplane handling performance monitoring, service-specific, and security-specific purposes.

Shibboleth

Nate expressed his concerns that, even with an application such as Shibboleth, which is relatively well-understood and has been extensively debugged in many pilot deployments, the difficulties of inter-realm and multi-party diagnostics may prove very significant. Scott Cantor of OSU, who is typically responsible for this technical support, will check server logs on a test target, while the deployer will check local logs. These logs are corroborated to find information surrounding a given event or handle.

The problems can arise in a wide variety of components and display ambiguous error messages, some from code that the Shibboleth project parsed from these systems, many of which may not refer to the interaction in the same way as Shibboleth itself.

The automation of this information gathering and assimilation process seemed difficult to Nate, although others on the call were optimistic. Mark suggested that collection agents will "talk to each other and correlate things... 5 minutes ago, I tried to do this, and it broke, and I need to figure out what happened." Other concerns surrounding access control to these logs and the identifiers used to represent an interaction from either point of view were also stated; reconstitution of parent events using pattern matching on various logs was suggested as a solution.

Action Items

Chas will send mail to Steven Carmody of Brown, Scott, and Nate to ask for further information on the experience of debugging Shibboleth deployments.