CGS-WG Session #2 8-9:30am Wed. June 9 Larry presents, Tom takes notes Attendance: 10 constant, +5 more transient CGS-WG Intro Addressed Susan Malaika's comment from first meeting that forge.ggf.org requires login to get CGS docs. This has been corrected. CGS-WG Status Job Submission Information Model (JSIM) Document in 30-day public comment period http://www.ggf.org/Public_Comment_Docs/Public_Comment_Documents.htm Larry asks for review of doc and comments and explains the importance of "any" comment. Software Resource Information Model (SRIM) Current model draft at https://forge.gridforum.org/docman2/ViewCategory.php?group_id=61&category_id=736 AGENDA GGF IP Policy/sign-in sheet explained and passed Review SRIM open issues Work plan leading up to GGF12 Current SRIM Draft Use Case Document at https://forge.gridforum.org/projects/cgs-wg/document/DAIS-WG_Use_Cases/en/3 Open Issues Security DMTF confirms that Open Source CIMOM’s do not support more than all/none authentication. Some commercial CIMOM’s have more sophisticated security. A hook to do authentication of the user inside the database is possible, but there would be no way to get the user’s password. This needs more thought. Discussion ensues, and there is not a definitive answer right now. But we see this as good news and perhaps less of an issue as previously thought. Replication How detailed do we want our model? Use case? We need to get DAIS group to refine use cases. Need to focus the scope of what we need for the benefit of DMTF support. And we are going to have to create providers to deliver this info to CIMOM. Long discussion regarding vendors' commitment to use our models and to provide tools/providers. Questions regarding time involved to construct a model and write schema. If we agree upon a model, one of the features is to write xml schema. Then it should be possible to write a provider. Stored Procedures Should these be included? Names, types, parameter types and description? Use Case? Deployment for access is top priority. There are some tricky procedures in 'some' cases. What is listed here (names, types . . .) are needed. DAIS going to provide a list. When it comes to what you can send through as far as access is concerned, this can be anything. We have to support all. Discover tables, indexes, everything. Triggers Include these? In what form? Use case? If we need to model this, then at what level? The representation wrt internal database tables is probably more than we need. We need a use case. Indices Include in the model? At what level of detail? Use Case? Data type handling Should we model only basic, or more complex SQL types? So far we do not support user-defined types. What do we need? Do SQL92 types first. Then jump to SQL99. But what does provider do if we don't support SQL99? DAIS will work on list of priorities. XML Database Should we try to include support for XML at this time? What standard to use as a basis? Design decisions could become "not" backward compatible. No "gospel" yet for XML Databases. Decision made to not concern ourselves with this now. Work plan leading up to GGF12 Bi-weekly telecons Start on 22nd June. Mail list Exchange drafts and opinions there. New model draft to resolve current issues Roger Reich (Veritas/DMTF) joined us late . . . Reiterated our discussion about DMTF's support role. DMTF trying to get funding of $500,000+ to move CIM model to a full UML representation. So collaboration with groups like ours can happen. Support for XML getting into and out of CIM . . . as opposed to MOF . . . Some confusion here. Questions posed to Roger. Once we render CIM in UML, then many tools available such as a UML-to-XML translator. More questions for Roger . . . regarding depth of CIM. There is a different depth depending on interest. In the storage management model, depth is tremendous. Grid-service's model is weak, but this is new. Roger wants to understand more about the need for XML. Grid services communicate in XML. We want the CIMOM to communicate in XML. Representing CIM in UML is a good step, but not enough. We need CIMOM to send and receive in XML. There is project work to develop a web-service client adaptor for CIM. Today when you query a CIMOM you are getting back XML-formatted data structures described by a DTD, and this is moving to XSD. We need to marry this project to the UML project. We don't want " we want " value" The XSD does not really tell you anything. It is a very 'loose' model. Roger asking questions regarding our needs, trying to understand. Running out of session time. Larry proposes a written document to be submitted to the DMTF regarding the need to move away from CIM-XML to well defined XSD's.