===================================== Minutes from NPM Architecture Meeting EGEE JRA4 Face to Face (July 2005) ===================================== Date: 12th July 2005 Venue: NeSC, Edinburgh Present: DANTE: Loukik Kudarimoti (LK) DL: Mark Leese (ML) UEDIN: Ahmed Abdelrahim (AA), Ratnadeep Abrol (RA), Alistair Phipps (AKP) Apologies: DFN: Robert Stoy (RS) Glossary ======== DT = Diagnostic Tool f2f = face 2 face PS = PerfSONAR (GN2:JRA1 tool) TL = Translation Layer (to GN2:JRA1) TLS = Transport Level Security wrt = with respect to WS = Web Service Actions ======= [ML] Talk to KK about ML's suggestion to write paper on EGEE JRA4 NPM. [LK] Start discussion with NRENs about whether two roles are sufficient for authorising access to their data. [AKP] Ensure that discovery documentation contains info about possibility of attack of vulnerable tools if security left open. General Discussion ================== Paper ----- ML suggested that it would be good to write a paper on the EGEE JRA4 NPM work. This would be something simpler than the technical documents that we currently write and will be a easy way in for people looking at the JRA4 NPM work. RA said that if we were to do this it should be done after end of September. AKP said he'd be willing to help write such a paper. Capability Discovery -------------------- ML asked if capability discovery would be used by the Publisher. Answer: No. Publisher will be know what to ask from whom. These interfaces were derived to satisfy requirements of the Diagnostic Tool. Security -------- WSs on top of monitoring frameworks must accept security as defined by EGEE - EGEE roles, VOMS and TLS. Is this a reasonable restriction to make on these WSs? RA: For the time being these WSs are being written/provided in context of EGEE so it is OK. Consensus: Push to keep current situation with WS doing translation between EGEE security and framework security. PS will not have a strong security mechanism for the end of September. ML clarified that authorisation is done on role rather than individual users. LK: Do we use JRA3's trust manager library to read roles? AKP: Yes AKP: Current set of roles will be: * regular EGEE user (PS semantics: can access aggregated data); * EGEE ROC user (PS semantics: access to raw data and aggregated data). LK: Two roles will be sufficient to start with. Will need more later e.g.: * a role for asking measurements to be made; * to meet individual NREN's access requirements may need to create a role for each NREN. LK will try to start a discussion with NRENs about whether 2 roles would be sufficient for them. LK: Where should authorisation be done wrt TL? AKP: Ideally should be done at the framework layer (i.e. the one below the TL). But PS doesn't currently support security, so must be done in TL. LK: OK, will do in TL. LK: Is the TL to be used for more than just PS? AKP: No. AKP: Current design has no security on the discoverer. Is this OK? ML: No. With an open discoverer people may be able to detect machines are running particular tools and attack vulnerabilities in those tools. LK: Can use firewalls to get over this. AKP: Clarification: Only EGEE will be able to access discoverer, it isn't open to use by anyone else. ML: This is OK then. Should make clear in documentation that leaving discoverer security open can allow attack of vulnerable tools. Caching of discovery information by Mediator -------------------------------------------- ML: info will be static - changing maybe once per week - so such caching will be useful. AKP: a WS request incurs about a 600ms overhead, discovery calls are 2 step process (client -> mediator -> discoverer) and discovery will be queried often by DT, so should reduce number of calls as much as possible. Consensus: caching a good idea. Aggregation ----------- ML: leave until later - low priority. LK: if we have time can provide min capacity and max average bandwidth. RA: see if aggregation is requested by users once DT is out. AKP: Aggregation was in DJRA4.2, does it matter it won't be in MJRA4.6? RA: No. Aggregation is theoretical. We said in DJRA4.2 that we were including it to see that we could do it, and to see how useful it may be. So the decision to leave it out can be put in this context. AKP: Not sure if Mediator is the right place to do aggregation anyway - it requires too much data to be sent to mediator. Consensus: Aggregation will be lowest priority for MJRA4.6. This means that more likely than not it will not be in. NPM Data Caching ---------------- LK: history or most recent data required. ML: should have only a "base level" cache - i.e. with little intelligence. RA: agreed. Need logging in the cache so we can see how it has been used so we can decide how to add intelligence at a later date. RA: caching should go in, but should be low priority. AKP: would like to have cache place-holder in place even if caching itself does not go in. Consensus: Put in caching as dummy component that does nothing. Once basic NPM system functionality is in place then implement the cache. How many mediators will there be? --------------------------------- AKP: At previous f2f (in Geneva) it was said that we would have one mediator per ROC. RA: For EGEE 1, because of limited deployment we will have only one Mediator for the whole of EGEE. When there is one mediator per ROC, it is the ROC's responsibility to publicise to its users the mediator they should use. RA 15/07/2005