Difference between revisions of "Talk:COSMOSSummit-11-Apr-08"

Revision as of 09:53, 11 April 2008

Attendees

Tania, Jimmy, Jack, Martin, Paul, Charlie, Rich, Bill, Srinivas, Toni, Don, Mark, David, Jason, Leonard, Joel, Sheldon, Hubert

Discussion

DC Discussion:

• At one time we had a significant focus on Muse, so we should figure out where we stand. Should we remove what was done before or can we refocus it? Is there any use for the WSDM work in COSMOS 1.1?
• What we did with the Muse code was not compatible with the spec. We must have conformant wire formats for the MDR API, and Muse doesn't provide that. We looked at whether or not we could "hack" Muse to make it compatible, but determined that this would not be a maintainable strategy. So we had to look at reasonable alternatives, and that's where JAX-WS came in; however, JAX-WS is not there and won't be there in time for COSMOS 1.0. We decided to go ahead with JAX-WS anyway, although we are now running into legal issues with Axis2.

• Is Muse dead or is it just sleeping? Do CA or IBM have any interest in WSDM these days? If so, where is the reference implementation going to be if it won't be in Muse?
• From CA's perspective, WSDM could be of interest in the post-1.0 timeframe. A lot of products are not fully WSDM enabled yet. There is some interest, however, there is not much in the products now. Perhaps this will change in the next 6-8 months.
• The original focus was management enablement. Are we going to walk away from these standards and then pick them up later? Don could convince CompuWare to invest in that area, but COSMOS has no interest then we don't want to build more code to throw away.

• Could we make a containment vessel that could host both of those things to support those web services management (WS-Man & WSDM) standards with some abstracted API? Since WSUM is not progressing quickly, if we work with the Muse project and WS-Man project to get some use out of both of them without a lot of agony, that may be useful.

COSMOS 1.0?

• For June, we are delivering: Tooling around MDRs, Framework around MDRs, SML work and framework around SDDs
• Don: We have no plans to adopt the function in the June release
• Jimmy: Our internal adopters are picking up COSMOS to help it gain traction and are taking an iterative approach. Therefore, not releasing COSMOS as 1.0 will not impact them.
• Is there a problem for someone trying to adopt and use the June deliverable if it is not 1.0? No.
• What are the benefits of releasing 1.0? Releasing as 1.0 makes a statement about the level of maturity of the project, and sets expectations about stability of the API, support, etc.
• Do we want to set our 1.0 target now? Yes, we should try to target something for this year (November). We need to start working now to clean up our processes.
• Before graduation, we will need to determine which top-level project we want to host us. We should talk to Bjorn and determine who the candidates are for the hosting products.

• Decision: Consensus is that we will remain in incubation, release 0.N in June and target a 1.0 release for November.

• Tania and Ruth will drive plans to get us ready for graduation to a mature project. Domenica may also be able to help with this.

SDD Update - Jason:

• What does this mean for the discussion for using the SDD tools to install COSMOS? It would be really good if we can have something in the June timeframe (even if we call it a beta SDD) as CA is running full E2E adoption. Then we can have a full implementation in November.

• Mark and Jason met with a member of the SDD technical committee on how we can synergize CMDBf, SDD and SML. An SDD is an XML doc that defines resources being deployed and dependencies on resources that have already been deployed. The discussion was: How do we query resources to determine if the SDD reqs have been met, and how do we register resources that are being deployed by SDD? We already do query and registration. So, Mark's thought was that we could use the CMDBf API and either query the federating CMDB or query some other repository if a federating CMDB is not present.
• The requirement driving this is for SDD to maintain a set of things that it installs as a result of processing the SDD. That is a local storage mechanism of some sort, may or may not be local to the machine or the image that was installed (may choosed to install something down to a blade but not persist that I installed it on a blade, but may persist it somewhere else). The requirement is also that there may need to be integration at various points in the lifecycle: when updates happen, when you want to decommission the machine, or other cases where we want to access the information. So, we need a well-understood API on top of this repository. Given that we have the requirements to have the information persisted and to develop a set of APIs, and since the use case is similar to a configruation management use case, can we leverage the CMDBf?
• We want to run this use case by the CMDBf folks to make sure this makes sense. Mark will get this set up.

• If we position the Pascal P2 work as a subset of SDD, we can better drive adoption. There would be value for P2 as well since the XML format they've invented is not standardized. Mark and Jason should meet with Pascal to come up with a roadmap. Mark will set this up.
• We don't have an end date on SDD 1.1 yet. We will likely have a date next week.

COSMOS Post-June Plans:

• We should target 1.0 for November 14 (With iteration drivers around: August 8 and September 26)
• Tania and Ruth should build the release plan. We should add a bullet to the plan that says we are truly ready to graduate if and only if we have had some successful adopters of COSMOS. That is one of the graduation criteria.