From: LOUGHRAN,STEVE (HP-Corvallis,ex1) [steve.loughran@hp.com] Sent: Tuesday, June 22, 2004 2:48 AM To: Milojicic, Dejan Subject: RE: Notes from one of the GGF sessions Dejan. when are you going to get on groove. everyone else in the core team is? The notes are there, slides are there, work in progress is there. you can see who is online. stop worrying about the effort of installing another program, and just do it. Here it is, actions are group actions, not steve actions, in case you were wondering. ===== Discussion on lifecycle, how it maps to WSDM lifecycle. -need to emphasise that the lifecycle of CDDLM components does not WSDM has operational lifecycle messages DMTF has state model WG too. Dejan says the activity has stopped too. consistency of state models is imperative. That does not just mean that we have to adopt their state models, so much as we can drive the state models of the groups. Thought: a component that probes a WDSM endpointer (endpointer def= WSA:endpointReference) for the operational state of a deployed item. Specifically: failed deployment does not have to match to the operational state of things. Action: we engage with the state behaviour people. Monitoring requirements. How we bridge between CDDLM monitoring and WSDM? WSDM does not provide a monitoring application. Instead it provides the messages of things that need to be monitored/managed; other apps do the monitoring. It may prove to be CDDLM :). We need event notification. to know when something fails. Clarification of why CDDLM does need to monitor health of deployed things. It is because the failure gets signalled up so that the parents can choose actions on failure -sequential workflow or entire system undeploy. Thomas Maguire: we are declaring the clustering semantics for multiple systems. CDDLM needs to define the minimum that it deals with. Especially in the monitoring terms. Perhaps a Separation of Concerns can move some parts of the problem to other bits of the system. CDDLM contains rules for what happens on failure. Or more precisely, they are contained in the composite rules. We may be able to have a composite that works with WS-Policy to support policy-described actions. Action: follow WS-Policy. Heather: there is no explicit transfer of attributes from the config to the running components. But there is implicit transfer. -The issue of run-time tuning crops up again. It is certainly interesting to be able to extract runtime tuning state. But this leads to the problem -what tuning do you want to propagate back, and what bits dont you. We are certainly very likely to talk WSDM to things to manage them. Search for volunteers. Nobody on either side jumped up to volunteer spare time, for the obvious reason. Heather: WSDM will only act with XML syntax. Heather: our configuration attributes should match WSRF resource properties better. (Its not clear that they match well) If we need notification then WS-N is the only way we should be going. Heather: doesnt think there is room for two languages. Q: what are we deploying? A: WSDM resources, plus other things. Anything that is deployable/undeployable. WSDM says that it only manages a manageable resource Q: relation to MS Dynamic Systems Initative A: none Q: relation to other XML based deployment descriptors Actions: identify someone in CDDLM to work on WSDM. Tom Maguire can hook us up with CIM and other thing. We need to spell out an interop spec. ===== > -----Original Message----- > From: Milojicic, Dejan [mailto:dejan.milojicic@hp.com] > Sent: 22 June 2004 01:09 > To: LOUGHRAN, STEVE (HP-Corvallis,ex1) > Subject: Notes from one of the GGF sessions > > Hi Steve, > > Thanks for posting the answer to Kojo. I really appreciate. > > Best regards, > > Dejan. > > PS I have an impression that you were editing notes for one > of the GGF sessions. Did you have a chance to finalize them > so that I can submit them to GGF? Thanks! Or was it Jun that > took the notes? >