[rm-wg] Meeting: Fri 28th Sept, 8AM PDT, 11AM EDT, 4PM BST, 3PM GMT

[Sergio Andreozzi]

Hi Paul,

I've uploaded a new version of the GLUE Spec document.

https://forge.ogf.org/sf/docman/do/viewDocument/projects.glue-wg/docman.root.drafts/doc14639

Moreover, the status and open issues of GLUE/RM integration is collected 
in this page:
https://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/RM2GLUE

Cheers, Sergio


Strong, Paul ha scritto:
>
> All,
>
>
>       *Next Meeting*
>
> *When*: Fri 28th September 2007, 8AM PDT, 11AM EDT, 4PM BST, 3PM GMT
>
> *Duration* : 1 hour
>
> *Where*:
> Con-call - The pass code is 2051278. UK:+44-800-085-6481, US: +1 888 
> 237 8573.
> Glance - http://rmwg.glance.net, pass code 0928.
>
> *Agenda:*
>
> It’s about time we recovered from the post summer torpor! Dave and I 
> have been active in our organizations building things that use the 
> reference model, or at least something like it, and we have some 
> thoughts I think we’d like to share before we make the push for 
> publishing the document.
>
> Specifically from my point of view –
>
>     * Whilst the notion of a pattern DAG, a DAG of managed components
>       and the logical DAG of the components that manage is very useful
>       in describing a conceptual view of how things fit together, the
>       sub-classing of Grid Components into Managed, Pattern and
>       Manager Grid Components within the UML seems to be less useful
>       or rather less actionable. It may be that Pattern and Manager
>       sub-classes are appropriate, but it seems unnecessary to have
>       the notion of Managed, as all Grid Components can be managed.
>       Anyway, we should discuss.
>
>     * Grid Component state. Here we have found that we are using two
>       types of state, an operational state and an admin state. These
>       are summary states with the complete “state” reflected by the
>       various attributes of the Grid Component. I am actually
>       uncomfortable with the notion of Admin state because it couples
>       the life cycle of the Grid Component too closely to an
>       implemented process. It would be good to discuss though.
>
>     * State & Configuration. A couple of months back there was an
>       interesting discussion on State vs Configuration on the OGSA
>       alias. At eBay we have in fact created State and Configuration
>       classes. The existing UML uses stereotypes to effectively
>       categorize configuration and state related attributes. At eBay
>       we have separate classes to capture these. Each Grid Component
>       has both State and Configuration. Our definition is that
>       Configuration attributes are those that can be directly
>       externally manipulated and that define the behavior of the Grid
>       Component. State attributes are typically those that are set
>       internally (although changes in them may be externally driven)
>       and reflect differences in the state of the Grid Component that
>       are interesting to an external observer/client (user or
>       manager). This State class is separate from the state attribute
>       that reflects where in the life-cycle the Grid Component is.
>       This may or may not make sense and a discussion would be useful.
>
>     * Instantiation and Interaction Dependencies. The UML is currently
>       incomplete because it does not allow the sub-classing of
>       association classes. Association classes may be sub-classes of
>       other classes though. So we would have to change the way we
>       represent things. Thus we would have to have Instantiation and
>       Interaction Dependencies as abstract super classes that we
>       sub-class until we reach leaf classes that can then be
>       Association Classes. Whilst it is certainly out of scope at
>       present to discuss how we could serialize the model, in one of
>       my projects we are using RDF and OWL DL. RDF allows us to
>       sub-class classes of relationships in a much cleaner and more
>       obvious way. The notion of classes of relationships and allowing
>       these relationships to have their own attributes is of
>       fundamental importance. In our CMDB work I am pushing heavily
>       for relationships to be fully fledged CIs. Another thing we
>       should discuss.
>
> Other than that we need to pick up momentum again before OGF21 in 
> Seattle, so that we can have a document that is in a state to 
> review/comment upon. I don’t think we have much to do conceptually, 
> but we do need to get the above resolved and written down.
>
> We should also get up to date on he latest GLUE work.
>
> Cheers
>
> Paul
>
> Paul Strong
>
> Distinguished Engineer
>
> Grid Computing & Enterprise Management
>
> eBay Research Labs
>
> Tel: +1 408 967-8450
>
> Cell: +1 408 981 8948
>
> Skype/AIM: FractalPaul
>
> http://labs.ebay.com
>