Talk:COSMOSSummit-11-Apr-08

Attendees:

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

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 with JAX-RPC using the Axis2 implementation. Legal approval for Axis2 is in progress.

• 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, make Milestone 3 available 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.

• We have no plan for an SDD GUI or web interface at this point, but console/command line UI is ok. If P2 produces a UI and we leverage P2, we can exploit what they do.
• Why are we opposed to have a simple user interface? It could be viewed as competing with things like InstallShield. There is already a lot of competition in this space. If we position this as a reference implementation and do it within Eclipse, we shouldn't have a problem.
• A UI makes it appear that we are building a management application. We are not building a management application, we are building an SDD Runtime.
• Conclusion: We will limit our user interface to a command line interface.

Early adopter experiences:

• CA has some adopters that will go live in November. We need to make sure that nothing will break when they move from M3 (June) to the November release. We should have QA implement some tests to confirm this.
• Early adopters are genearally pleased, they especially like the query builder in i10.
• There are some obvious holes. The one big thing that keeps coming up is that if something goes wrong in COSMOS it is very difficult to determine the source of the error. It would be nice to give better feedback to the user when there is an error.
• There is also a lot of time spent to resolving version conflicts. Hopefully, SDD will help with the version conflict problems.
• We are looking to use the i10 integration build. When can we expect to have a stable i10 weekly build?
• We need to revisit/confirm the metadata API and the APIs for the process with how the MDR registers with the broker because those are not defined in the spec.
• We should view API change post-June as critical only. We may need to use i11 to restructure our API.
• We should keep i11 very narrowly scoped. We should not bring in new function, but focus on stabilization, cleanup and bug fixes.
• We need an understanding of the security requirements from CA.
• Jimmy will target the 4/18 i10 integration build.

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.

• Will COSMOS one day have an information model, perhaps using CML? Previously we have said that model reconciliation is a federating CMDB feature that would be in commercial products. COSMOS does not have a pervue to try to standardize those models, but we can provide working examples of them.
• Some adopters are saying that COSMOS is providing the transport, but are not providing any mappings across those models.

Future Technology Direction:

• What strategy do we want to use to manage the COSMOS infrastructure? We made the mistake of blending the management side with the functional side of things. Because we've been focused on the functional aspect of the API, we don't have support for WSDM at this point. We tried to put stateful semantics on top of a stateless API.
• Right now there is limited management protocol on the broker and the MDR. We don't start/stop/shutdown/ask for operational status.

CA input:

• We need a well-defined position on WSDM/MUWS by year-end.
• We have no requirements from JAX-WS.
• We definitely have a requirement for security. We have lost interest of some adopters when we told them security was not in scope.
• There is a fair bit of interest in the management capabilities.
• We don't have much input on OSGi.

CompuWare:

• CompuWare is going down an OSGi path, and is also interested in JAX-WS and JAX-B.

• We need to close on what programming model we are going to support for COSMOS users. Mark things JAX-WS and JAX-B is where we want to end up. It would probably be March 2009 before we could fully align with these. It would be nice to have a preview of the JAX-WS technology for the 1.0 release.
• Joel should figure out how we do a tech preview and line it up with release plans.

• Does CA want to manage eHealth or the CCMDB through a stateful web service protocol? Yes, but how can we do that?

• Don: Initial goal was to be able to leverage pre-existing sensor networks as a way of fostering ease of adoption for some of our customers of some our products. For example, we have a Tivoli adapter that takes data feeds from Tivoli...being able to have a standard adapter that would allow us to share eventing would mean we wouldn't necessarily have to have a Tivoli adapter...it would be more generic.
• SDD is also of interest.

• We need to revisit our use cases. We will schedule that as a follow-on discussion.

• Domain - We descoped this from 1.0 because we ended up having 2 levels of indirection, which was confusing. So, we tried to simplify what we were doing. The broker became the main entry point of the system. Whether or not the CMDBf spec defines it or not, there will be multiple ways to find these MDRs. We should evaluate use cases where we have multiple brokers. We think what we have currently should be sufficient for current adopters. If not, we should address it immediately.

• Are there plans for COSMOS to address the non-configuration (non-CMDBf) data? We haven't done any work in this space in about a year. There are no existing standards for event data that we are looking to support. There is a lot of potential here, but we would have to agree on the business value of the use cases. Not being able to settle on an appropriate standard in this space makes it difficult to converge on a solution.

Logging and Messaging:

• We are not doing logging in a consistent way.
• Before i11, we should close on what we would like to do because it touches all of the components. We should try to clean up some of the logging and messaging in i11.
• Do we agree on using log4j as our mechanism? Let's confirm this on the next architecture call.

Next Steps: Identify schedules, themes and necessary steps we need to have for 1.0 by Wednesday for Community Call - Tania & Ruth

• i11 - Maturation
• i12 - Hardening of the API
• i13 - Graduation