Talk:COSMOSSummit-13-June-08

From Eclipsepedia

Jump to: navigation, search

Contents

June 2008 part 1

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

June 2008 part 2

Att: Paul Martin Bill Rich Srinivas Ali Mark Domenica

Performance and stress testing in i12?

  • performance and stress testing. do we want to expand what QA do. They do some limited stress and load testing. build on that, expand it.
  • more a general question so that we can revisit it for i12. Based on the fact that we don't have benchmarks
  • we have enough on our plate now and we don't want to do work on something that we may or may not get.
  • don't feel the reason to expand the scope of the test efforts
  • Aperi MDR was a problem? The Aperi MDR has a lot of information in it? A heap space issue. Srinivas increased the heap space but even then there were problems. So that one we should add as a test. bugzilla 237454
  • Is this testing of the relational database connection part of the normal test pass? No because this is the first time that we had one.

New use cases?

  • notification use case? Jimmy to present the requirements for the use case?
  • 2.2.6 Use of notification events in a CMDBf environment. How do we distill the set of topics? Set of configuration items? How do we map or what is the pattern that we're doing the complete set of topics for an MDR? When I do a subscription, is this essentially I'm internested in a specific configuration or class of configuration item, when it changes do I need you to tell me?
    • How does registration and notification reconcile each other? We want to follow the notification outlined in the ?? standard. There's a substandard. One of the substandards is wstopics and one is notification broker. But Topics doesn't tell you what the topics are; up to the publisher to define the topics? Each MDR is going to be responsible for defining its topics. How do I avoid a mess of topics and inconsistencies among that? Publisher and subscriber must have pre-agreed on a common topic otherwise they'll never meet up. There could be some things on the metadata for example that we would be interested in publishing on. Configuration items on a machine. Could be patterns where we determine how to... what we would do once we get these things. What does a federating CMDB do when it gets the notification in? Do I do a registration? What do I do here? Otherwise I've got to do something with it because I subscribe to it, but what's the reason?
    • Should we add this to the existing broker or should we have a new broker?
    • Is there any dependency in here on MUSE? Problem with MUSE is that it's bound very tightly to the notion of a stateful model and that stateful model with the lack of advance of that in the industry is going to be difficult to take forward. Don't see that MUSE programming model going forward.
    • What do we need to do next with this one? Need to research more? Write something up? Answer the "how do we get a first pass at distilling topics?" and "what does a MDR do when it gets one of these things in" questions.
    • Add this to the next agenda of the architecture call (June 26)
    • ER 212293
  • three situations in that use case:
    • 1. doesn't provide a filter parameter and the web service returns the end points
    • 2. application provides general storage data
    • 3.
    • as long as we don't get into instance data, this behaviour makes sense. Tie this together with both the topic piece and with the notification. Question is what happens when something like this changes?
    • Mark is okay caching the metadata but as soon as we start federating... if we're doing this to avoid the performance overhead of constantly going out and querying the brokers, that would be one rationale. No federated query.
    • still wants something that sorts out the cached metadata? an API, yes.
    • Paul to update the use case and then potentially chew that over again in the architecture call

i12 plan

  • Each subproject to check if they're following the UI guidelines to see if we're deviating or not. Mandatory? Some acceptable deviation rate? Ruth & co to check with Bjorn.
  • Ruth to find the link to the old wiki page that listed all of the points that we need to pass Release review