Difference between revisions of "Talk:COSMOSSummit-13-June-08"

Revision as of 10:33, 13 June 2008

Attendees: Bill Martin Rich David Srinivas Sheldon Leonard Jack Jimmy Hubert Paul Jason Domenica Ruth

iteration driver

Sheldon:

• two bugs:
• 236936 registration doesn't seem to work. Leonard to look into it. Whenever you register anything it partially wipes out the registry. Not sure why that's happening.
• 236966 NPE. Intermittent. But it looks like a data collection bug. Can Hubert verify that it's a DC bug? Sometimes it returns null from the services instead of an array. Because there are no services in that group. Return an empty array instead? Now Hubert knows when it happens; it's because of the database. Hubert to change to return an empty array.
• problem we were having with the COSMOS UI has to do with log4j conflicts because Eclipse is using a different log4J than the Axis2. Sheldon tried removing the Axis2 log4j and it didn't work.
• Ruth to contact Sheldon on Monday to see where we stand

Srinivas: COSMOS UI: logging data manager was not able to generate the reports (no class def error), repository is an empty query response. Both of those have been resolved. Second one is for the SML MDR. That's fixed.

COSMOS i11 demo wiki page not updated with the i11 features. Hubert did most of the coordinating most of the time. The part that's most out of date is in the UI.

• Martin and JT to update that. Martin to note where the changes need to go and then others can go and fix it. Srinivas to IM Martin the URL.
• Also the client, COSMOS client from the command line. Hubert to do that.
• Bill to add the instructions on how to set up that example database

DOJO situation

• can we prereq instead of redistribute? Eclipse Legal said to check with Bjorn. There's two types of prereq: exempt and non-exempt. We have to have a reason why it's impossible or impractical to go through the legal process with DOJO. Examples where there's exempt prereqs would be a browser or JDK. But we need a reason for exempting DOJO.
• 12:00 my conf #
• if there's a problem then Ruth to email Jimmy, Bill, Sheldon
• Ruth to send an email to prompt them for a list of files
• worst case: is there anything that prevents individual companies from using it without COSMOS getting clearance? -> need to ask Bjorn
• assuming DOJO no-go, what then?

Artifacts

• spent some time on the piece internally and spent some time with the CA folks. Report on what the overall landscape looks like in this regard. What do we have on the table? Resource Modeling work that has been done.
• proposing and pushing to do two things: further enh etc. for the SML tooling. Provide that input once a series of adopters have evaluated the tooling.
• working with the CML consortium. Some sort of information model.
• information model out of scope for COSMOS but in scope for CML consortium. Those are the overall directions and thoughts from the resource modeling SML/CML perspective from the CA end.
• table this and get Mark's input when he returns from vacation

Security Requirements

• overall COSMOS 216332, deferred to i12. We did get in the initial CA requirement for CA password: 234373, 234610. Addressed the immediate requirement.
• still need to generate some use cases around encryption. That's in progress. Guess the question is whether the other contributors have any requirements as far as security is concerned.
• tentatively no.
• Paul to create some use cases for next week to generate discussion on this

Logging strategy

• there was a discussion earlier in the week, link there in the email thread, as to if we need a common log or a log per component.
• bring it up to look at for i12
• we have one log per web service. users may not know which log to look at. what's the advantage to keeping the log per web service? if they're different applications, why would they want one file?
• is the issue a single log file or a single location? We have a single location. They all have a prefix "cosmos-SOMETHING"
• Jason: one of the things is that the SDD runtime has a use case of being run outside of the COSMOS framework. That that use case it requires its own logging mechanism. But in the case in Eclipse itself it would need some changes.
• even in the standalone case, if the logging libraries are small enough, could you use them? Yes. One set of code makes perfect sense.
• Jason to speak to Hubert to learn about the logging structure
• Paul to come up with the logging and messaging guide and Hubert was going to make sure that it was up to date. Yes it's up to date and Hubert has some new information, some messages.
• for the demo setup, if we define demo as the set of MDR that we provide, we don't need so many log file then we can put them all in one.
• go for one log because the usability. You've got timestamps in there it's useful to look at one log to see what was going on at one particular point. For separate logs you'll end up looking at all of them and have to come up with some mechanism for extracting log records around a particular point.
• similar point. many irrelevant log entries to note only the set of records that are in one MDR.
• if there's lots of different events all in a single log file the implication is providing a mechanism to extract the events that you care about, such as security. Even if we combine all of the events in a single log we still need.
• what is it that you have to do to get the information from the log or logs, and is it easily manageable?
• discussing the default setup that we ship with a demo.
• log viewer capability, which has a filter ability. also to log particular messages from particular components. by having separate log files we've increased the complexity of the administration. Every time install a new data manager, the log viewer properties has to be changed to add a few lines to activate that log file. And now you need to learn about the new log file. Alternatively if you have that you learn about it once.
• Hubert to define a new package prefix. Hubert to remove all of the finer-grained appenders for each MDR. We start with one simple one. So all Eclipse COSMOS package will be logged into one log file. If you create a new MDR, if you start with Eclipse COSMOS it will go to the same log.
• they can leave the default or specify a log file. Each COSMOS container would have its own log file.
• Hubert to open a bugzilla for the appenders, new package prefix, etc.

Use cases

• Ruth to contact Rich to ask that when he creates the checklist for a technical review of the documentation to ask developers to also check that every use case is covered in the documentation
• meeting next Wednesday we will continue to conversation that we're just having?
• Ruth to ask Rich to explain during the next Community call how the technical review will work
• do we expect the QA scope to change? Domenica to send the cosmos-dev that question to get people thinking about it. Ruth to add the item to the Summit.
• Ruth to set up an e-meeting for the use case for Wed next week
• Paul: think more about performance and stress testing
• ER that Jimmy opened to add data to our documentation. Every adopter asks, "since COSMOS will be implementing data managers, how much drag will that put on my line?". They don't care about footprint. Need metrics and benchmarks? They gave Jimmy some samples.
• Ruth to put performance and stress testing on next week's Summit agenda

MDR Enablement (Jimmy)

• 2.1.1 no issues here. 2.1.1.4 David to update. We have an enhancement that needs to be an i12 candidate. 2.1.1.5 run on server support? yes. complete pending some integration between Sheldon and David. Put links from these use cases to the documentation page? Design docs linked from the enhancement.
• 2.1.2 complete. nothing to add for Aperi.
• 2.1.3

Collection (Hubert)

• 2.2.1 archived. Anyone who wants this needs to put in information. It's empty right now.
• 2.2.2 Proprietary data store. Non-COSMOS data managers. This use case is fulfilled.
• 2.2.3 Report generation. CMDBf constructs to create a report? Valid use case but not going to impl in 1.0. This one came from Ali. Related to the notification. How does an incident differ from an event? Do we have a more generic use case for using reports with COSMOS? Yes, 2.2.5. report on CMDBf. This isn't events or the event broker.
• 2.2.4 Log or statistical data collection. Improve the wording; not doing the collection but working off a database.
• 2.2.5 Complete. Show the user how to create some reports.
• 2.2.6 part of i12. Sheldon to talk with Mark. Need to mark a target date for this one.
• 2.2.7 marked i8. Is this complete? Hubert to update this; state what's done. Focus on logging and remove what's irrelevant to other use cases.
• 2.2.8 Notification events. That's future.
• need a use case to describe how to integrate any BIRT report with the COSMOS UI and more generic reporting