Talk:COSMOSSummit-16-May-08

Attendees: Jimmy, Don, Joel, Mark W, Martin, Leonard, Charlie, Hubert, Paul, Sheldon, Bill, Srinivas, David, Ruth, Jason, Ali

Security implementation requirements

Net: we have an internal adopter and we have a goal for that for the coming November. For that product a key requirement is if it uses COSMOS one of the thing it needs for its web services to function in addition to the query information we also need a simple login and password. Can be encrypted but does not have to be. Decision: do we use Higgins for this purpose or do we use an interim solution?

To meet these particular requirements there doesn't seem a need to employ Higgins. The aim is to provide a user & password and do the authentication in the MDR itself. That means that the client and query have to adapt. And then the UI has to present a dialog for the user name and password to be entered. Bill has done some work as a proof of concept for this.

Bill: this falls under the use case of a non-COSMOS MDR and we want COSMOS MDR to interact with it. Changed the COSMOS CMDBf query service client to be able to accept the basic security tokens and to stuff them inside the SOAP header so that it would be received in the MDR. That changes the client API. And then the user name & password is now passed into the client. The particular MDR was running on Axis1, not Axis2, so there was a small change to the header to change it to say SOAP 1 instead of SOAP 2. Implements simple implementation.

Dilemma: none of us knows Higgins too well.

Mark: was the design doc on the wiki page?

• No design doc on the wiki page yet.
• Bill did it in less than a day.
• No formal design or implementation process but the requirement was so simple Bill was just able to get it going.
• Go back and fill in some of the bullet points for us. Not clear, for example, break this down into 3 pieces: UI, potentially broker, MDR. Need the right hooks in the MDR framework to authenticate that against whatever product is under the covers. Not sure how exactly that's supposed to work. Mark thought that Higgins had a set of those APIs? Yes it does. If we can agree upon those APIs then that's a significant chunk. We get security and use Higgins, and Higgins plugs into commercial stuff like LDAP. That's the piece from the MDR side of it and that probably covers the broker piece too.
• Mark will ask Tony to present. Have this documented as a PoC, maybe we can check that into the sandbox to look at it, help us out we think that Higgins is a fit for part of that.

Paul: the fear is that if we start to pull in Higgins we won't get this done.

Bill:

• the piece that Mark is referring to is referring to the use case where you're using COSMOS to build an MDR.
• Broker authentication. That probably makes more sense to do that with Higgins.

Sheldon:

• didn't really cover the user management work. Talked about hooking in some kind of security. Didn't explore hooking in a user management component for the UI.

Mark: not quite sure how this all would come together at the UI piece. If we were to say we need to do some basic authentication in the broker and domain that's fine because it's all headless. Having it in the UI is a little bit more involved.

• Tony's calendar first that he has available is Thursday next week. That means that he's probably at the Pulse conference.

Don: if we're talking about authentication, that's something that Higgins would just call you impl anyway. Don't think there's a conflict here. Need to define the roles. Leave a Higgins-size hole.

Mark: sounds like we're all trying to agree. Just want to make sure that we don't clobber anything as we go forward.

Jimmy: This is for CA World in November and we want to do something for that.

Paul: Higgins isn't the only game in town. Tomcat might be able to do something.

Martin: without changing any code was to be able to use Tomcat's authentication mechanism. Tomcat already comes with an XML file that has roles in it. Changed the XML in the Axis2 web service and then put in a security constraint, "/services/broker". When you start up the UI see an authentication error saying that you're not authenticated. Almost out-of-the-box solution just by changing the XML but you've got to have that challenge at the beginning with the user id and password. Can do the authentication in the MDR data manager or send a call outside. All we would end up doing would be to create the hooks. Difference between the Tomcat and the MDR way is that it's the application server stops you accessing the services vs. getting to the MDR and then you decide. Distinct difference and not sure if one way is better than another.

Mark: Does the single sign-on still work in that scenario? Sign in to one web based application and then through a URL invoke a COSMOS application and then click on that am I going to be forced to log in to COSMOS again or can we login once and then not need to sign in again?

Martin: No, that's another use case.

Jimmy: That's a heavy-duty thing for a long term perspective. This is a short term approach to help us get going for November.

Action items

• we have enough on the table to start to put together a design doc for early next week
• talk to Tony next week (Mark already sent the invitation)

Organizing the Downloads page

• two bullets, current download page and wiki page
• We have a demo zip file. It's for people to evaluate the project.
• Second zip file is the SDK. For developers: source plug-ins etc.
• SML editor and validator
• Data Reporting

The history is when we had one zip for each subproject. How does SDD fit into this? We're still working through what the SDD for COSMOS will look like. In terms of a user interface we agree that we won't provide a GUI but rather a command line interface. Anyone who wants a GUI will not do it in the open. Various prerequisite components that need to be installed for COSMOS. Planning to post a new updated version. Our goal is to strive for a single download package. Packaging SDD itself? Yes, can bundle a runtime with the COSMOS installation so that if a runtime doesn't exist we bootstrap it. Need to have a separate download for all of the tooling work. Think it makes good sense to create a separate download for the runtime as well. Will the runtime be independent of the COSMOS framework? No completely independent but will be run in a stand-alone fashion. May want to integrate some SDD libraries in the COSMOS framework.

SDD runtime can be in its own section.

Divide up the COSMOS packages along the system management branches. Deployment management, resource management, and data integration. There also needs to be a core package for the framework code: broker, may also include the UI as well.

Ruth: Could have lots of zips. Don't want to overcomplicate it. Every zip that we provide we'll have to test.

• A single zip (all-in-one). Note from Ruth: we need to get our Legal ducks in a row to have an all-in-one including our 3rd party open source. Some of our IPZillas are for prereqs only.
• COSMOS Demo in a separate zip (CMDBf, data collection, data visualization) - is it a significant savings? Might need to add a demo for the SDD portion and the SML portion.
• Update Manager. Most Eclipse projects offer that as a zip as well?
• Demo separate. Has some files

Action items

• Jimmy to find out what zip CA needs
• Jason to find out what zip SAS needs
• Mark to find out what zip IBM needs
• Ruth to post to the dev list when we need to know what zips we need. Will speak to Saurabh to find out how long it will take to refactor the zips for version 0.9.

Capabilities and future directions for MDR toolkit

Today we allow you to generate the stubs to allow you to plug it into a COSMOS framework. Complete a well-formed data manager. Coming at it more from the "Am I ready to jump onto the COSMOS bandwagon perspective?" Huge variance. Will the MDR toolkit go just beyond the interface code or go beyond that.

The toolkit has a simple mission: make it easier to create MDRs.

Jimmy to open three bugzillas early next week.

Bill: wish you would do more validation in terms of the validation such as JRE level. Validation: how would it work?

In eclipse when we were using the toolkit, our JRE was pointing to an incorrect JRE version. However, there's two ways we could have solved this: upfront validation, or improved diagnostics (took us a while to figure out the problem).

Limited to the constraints of the facet framework.

Development and test environment. Closer integration with the source code so that Bill can step through the hooks that are being called in the core COSMOS pieces. Would the run on server help with that? One enh, run on server, let you select the MDR that's generated after you build out your stubs. Do have some pieces.

Jimmy to capture the details in a couple of bugzillas and David to go from there. Bill would like source code to be copied over as well to make the association. Plus to export to an EAR file as well would be terrific.

it should be easy to tell which enhancements David has been mentioning.

search bugzilla, the management enablement component, for all enh assigned to david whiteman.

Action items

• Jimmy to open some bugzillas early next week
• Bill and Jimmy to review the open enhancements:
  • Provide integration with Run on Server to launch web UI in Eclipse web browser
  • Tool for exporting axis archive for web serivces

Team restructuring

• collapse the existing subproject, become one COSMOS? get the new process in place soon so that we can say that we've run under it for a while
• cleaning up the committer list
• current data collection team has a variety of interests and does that team need to be two teams or not?
• project scope has wandered quite a bit for data collection
• renaming packages if we restructure projects

• not completely necessary for packaging renaming. wouldn't have to be done at the same time.
• being able to build an engine that could absorb and transform various kinds of management data. Could potentially persist that. Name itself was ill chosen?

• okay with keeping the CVS package structure essentially the same? => yes
• notion of a prototype project. Sandbox was for code that was going into the mainline stream but not yet ready to isolate breakage, damage, etc. For a prototype project, still need to have it under the guise as a corporation under open source. Don't want it to be a wide open space and check in whatever we want. Need it to go under an architectural review to ensure that it works well with the rest of COSMOS. Using Bill's security code as an example, Mark can see a sandbox area so that we can look at the code and see what it does.

• need to clean up the messaging around the subprojects and what they do.
• data collection team need to stay as one team
• cleaning up the committer list

If we're not going to be a top level project, need to clean up our web site to reflect that. It's one thing to be adoptable and have a good external image.

Summary:

1. No change to code structure
2. Update the web site
3. Clean up the committer list
4. Divide the data collection team into two?

Mark: keep data collection as one team for now. Don wants to investigate some of the normalization stuff but that would be looked at as we go towards Sept/Oct. For the rest of the year getting ready for graduation don't want to derail that. Don wants to reiterate that we have other objectives in data collection after other things are out of the way. Data collection doesn't have a lot of value that Compuware can adopt at this point and Don is feeling like he's not been a lead to the DC component.

• need to get the SAS logo on the dash page as well

Remove these people from the committer list:

• Valentina Popescu
• Oliver Cole
• Vsevolod Sandomirsky
• Marius Slavescu
• Balan Subramanian
• Craig Thomas

Action items

• Declare a new lead for the data visualization. By default that's been Sheldon.
• Declare a new lead for the resource modeling if Steve agrees. By default that's been David. Mark to check with Steve because he's been active behind the scenes.
• Declare a new lead for Management Enablement. Should be SDD and the CMDBf toolkit. New leader of Jason Losh.
• Declare a new lead for Data Collection. New leader of Jimmy Mohsin.
• Don and Mark to scope out the work that Compuware is interested in under data collection.
• Summit in October checkpoint from Don and Mark on where we stand for Compuware's items.
• Mark will email the inactive people and cosmos-dev to warn of impending committer status removal if they don't state within the next two weeks that they will become active.

FYI Mark can mark people "Active".

SDD Update

• making pretty good headway to work through some of those details. Been iterating quickly on SDD and it's changed quite a bit from that initial copy.
• Instead of adding it to the wiki page, add it to the enhancement as an attachment and then link to that attachment from the wiki page?
• No preconceived notion.
• Current script that exists that copies content around is tokenizing that script so that things we're going to query, where is tomcat installed, where is axis2, etc. Do we want to have a deep dive or do folks care? Mark would like to have that deep dive. Jason to schedule it in the morning about two weeks from now. He'll send Mark and Paul email offline to ensure that it's scheduled at a time that they both can attend, but it will be an active call.
• Also had a meeting this week on the runtime design. Beginnings of the design document. Created an ER for and a design attachment. Pretty sound design. Question around the design of the SDD runtime is how do we vet these designs as a team? Who ultimately gives thumbs-up? Is there a process in place? We can use the voting on the ER. Not sure if that's reserved for the PMC. Need a meeting to review the design. Once the designs are vetted, we'll get ERs opened up and each individual component may require.
• Reconcile the use cases
• Is there something that Paul can download to see? Not yet. Can share example SDD documents.
• investigate the SML as the profile
• How do we articulate this positioning (SDD/SML)? If you look at the design doc that was sent around, there's an interface for processing the SDD, mapping & registration of custom code, etc. Mark is driving at a level of detail that doesn't exist in the design document. We can add verbage that would reference SML etc. Can Jason add that level of detail because we get a number of questions on that. ("Here this is how it comes together; this is what's going to happen.")

Action items

• Jason to email Paul, Mark to ensure that the open discussion is at a time that both can attend
• Jason to review our dev process page to see if we need more detail about our iteration process for reviewing designs
• Jason to document SDD/SML: "Here this is how it comes together; this is what's going to happen."
• Jason to focus on next steps of resource handler interface, send out a meeting to the dev list to discuss the design.

Update on consumer requirements for use cases 2.1.5 and 2.1.6

Jimmy can answer this better than Paul?

• before we initiate a dialog from an MDR, can we ping it to see if it's alive? If something is wrong at the MDR end and we can't query it then people are going on a wild goose chase to figure out what broke and why it broke.
• that was on the caching of the stuff on the broker? No, that's different. the caching piece. Instead of the client going through all the MDRs one by one want to issue a call to the broker because the broker has information about the MDRs. But this one is bare-bones management. Already working with an MDR, before executing a massive query or series of queries, want to ask the MDR if it's okay then find out if it should proceed or not? why not ask the product itself if it was operational and the CMDBf APIs were part of the operation of this product? Could do it that way; are you saying that operational status is nothing to do with COSMOS? This gets back to what is the management of the COSMOS infrastructure. Initially we had the idea that the COSMOS stuff was essentially going to be management-independent. Because they were going to be independent we said that we needed more of this operational stuff. The management story hasn't really been updated to reflect that COSMOS has become more of an embeddable component.
• thinking of the logging web service monitoring what's been going on. find information on what data managers are up, what data managers have had problems etc.
• onus is on the adopter to leverage it however they want
• driven by a CA product. Somebody spent a lot of time and money that could have been avoided if they had this very simple check & balance. If there's something wrong, they have a checklist with ten things on it. With this item instead of going over that checklist 10 times a day then it might be 5 times a day. This is more than a lukewarm issue for the technical services group.

Action items

• Jimmy to come back in a couple of weeks and say how this will work from his perspective