SMWG meeting minutes Present: Michel (LAL), Alessandra (Manchester), Colin (Manchester), Ian (CERN), Chris (RALPP), Peter (Lancaster), Graeme(Glasgow), Paul(Galsgow), James (CERN), Pete (Oxford), Iwona (Berkeley) Apologies Cristina (INFN) Group organisation ================== who is going to dedicate time and how? we are all very busy and we need really to use this infrastructure to document what we do for ourselves already so that it doesn't get dispersed. - People are willing to use the infrastructure to collect/document what they do already for theyir sites. - We should collect what is around and see what's missing and point that out. This is the area of major overlap with the Grid Services monitoring group. SMWG should tell them what's missing to monitor grid services and give feedback on what developers propose and GSMWG should make sure that the monitoring framework is compatible with what it is in use at sites. - We could start a wish list page on the wiki so that sites can list what they need and see if other sites have already solved the problem and are willing to share their solution. - We have to start a best practices document. We are going to use the wiki that has been setup for that. - We don't have committed people perhaps we could get it from the ROCs but we have to demonstrate that what we are doing is generally useful. People present at the meeting are willing to participate and give sometime because they see that it will make their life easier in the future. - We do have enough expertise on management and monitoring tools to write documentation. Wiki and relation with existing wikies ====================================== The point being 'we are lazy' and we don't want to rewrite every(any)thing that has been already written unless it makes sense. On the left bar of the sysadmin wiki I've added already a couple of links to other grid wikies that contains a substantial amount of information for grid sites. However GridPP wiki contains also the embrio of documentation for cfengine which might be of wider usage and could be moved to the sysadmin wiki. Same for other type of documentation unless the maintainance is more natural somewhere else. - In relation to other wikies we need to be clear on what goes. For example storage docs are already well developed in the GridPP wiki, fabric management can be started in the sysadmin wiki. - We should get a skeleton of categories nad cross references, otherwise if we start to write random pages it becomes difficult to maintain and search. - If we start to make a distinction between monitoring and management tools we have the problem that a lot of tools can do both so they belong to both categories. - We can have category for each tool and associate with it a front end page with pros and cons of that tool and then have the real documentation pages belonging to the tool category and to the monitoring category or the management category depending on the content of that particular page. - We could implement a traffic light system (a coloured icon on the front end page?) with green for tools that have been used are well documented or easy to use, amber for tools that are used but not that maybe are not that easy or not well documented and red for tools that are not used or people had a bad experience with. - We should date each page or addition to make it easier to know if the content is still relevant without having to look at the history (more direct aproach) - There should be some editing or supervision Repository organisation ======================= Do we need to discuss a schema or should I jot one down and that will be ok? - 'Editing for the repository is also important. People can commit tools that do the same thing in different ways and this might confuse someone who is wants to use them and doesn't know which is the better one. Sometimes there might be different solutions to a problem because they correspond to different requirements and then it is useful to have both tools. In the case of GSMWG new plugins/probes will be created by developers it is evident that they have to avoid replicating effort. In the SMWG case it will be matter of evaluating tools and documenting the differences and the requirements. - No agreement on the schema but a proposal could be a directory per tool and subdirs for different type of files for example Nagios | * config * HOWTO * plugins | ** batch system ** load .... Next meetings ============= We will have meetings every every two or three weeks. The next one will be on the 21 of March at 4pm UK, 5 pm CERN, 8 am California. Actions ======= Action: Ian put a summary of the monitoring survey in the wiki Action: Michel put a summary of the WLCG survey in the wiki (?) Action: Alessandra contact LCG security contacts to see if they want to cooperate on the security best practices. Action: All make a list of categories (tools if we follow the schema proposed) for the wiki.