[cosmos-dev] COSMOS 1.0 - Recommended operational guidelines from both h

["Mohsin, Jimmy" <Jimmy.Mohsin@xxxxxx>]

Title: COSMOS QA strategy - Operational criteria and the impact

All,

 

Which is the right page to capture information that addresses the scenario painted below?  Specifically, I assume we need to publish the following information for COSMOS 1.0:

1.    Recommended hardware configuration(s)

2.    Recommended non-COSMOS software configuration(s)

3.    Recommended COSMOS software guidelines

 

Should this info go on http://wiki.eclipse.org/COSMOS_M2_Dependencies?

 

Thanks,

Jimmy Mohsin

Cell   +1-609-635-1703

 

From: cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On Behalf Of Mohsin, Jimmy
Sent: Monday, January 14, 2008 3:57 PM
To: Cosmos Dev
Subject: [cosmos-dev] COSMOS QA strategy - Operational criteria and theimpact

 

Team,

As you know, we have been talking about the QA Criteria and strategy for a while now…  I had a question that came up internally in this regard…  Please consider the following points:

1.      We are yet to define / finalize our operational criteria for COSMOS 1.0.

2.      We are also yet to specify any kind of bounds on COSMOS 1.0, e.g. .. consider the following possibility:

a.      An adopter takes the COSMOS 1.0 code and deploys a Domain and Broker

b.      She then ties in TEN or so MDRs each with GIGABYTES worth of data

c.      She then executes a plethora of queries, each of which returns MEGABYTES of data. I paint this worst case scenario as we all know that there is NO shortage of LARGE existing data sources…

d.      Everything comes crashing down, and the adopter gets the impression that COSMOS has issues…

3.      In view of preventing the above from happening, let us say we have the operational criteria in place for i9; and then we discover that the code does not meet these criteria and has deficiencies that result in operational inefficiency

4.      In this (hopefully unlikely ???) scenario, re-factoring work would need to be done, which will result in downstream implications for our release timeframes.

How do we deal with this situation?  What else can we do to mitigate this risk, other than defining Operational Criteria?  Should we specify guidelines and operational best practices? Should we define hardware configurations? Anything else we should be thinking about?

Or am I being hopelessly pessimistic on a dark, rainy Monday and the adopter will never stress our system in any way shape or form?

Thanks,

Jimmy Mohsin

Cell   +1-609-635-1703

_____________________________________________
From: Mohsin, Jimmy
Sent: Monday, January 14, 2008 3:10 PM

All,

COSMOS is going to be addressing this; anything obvious missing from your perspective in the left column?  The “Details” column is something COSMOS will provide.

Operational Criteria specification

Quality expectations for specific items related to COSMOS operating in production:     
Acceptance Criteria     Details        
Availability    There are no Availability quality expectations 
Capacity        There are no Capacity quality expectations     
Concurrency     How many queries / clients may run simultaneously? Should there be any other concurrency considerations?       
Data Volumes    Are there any restrictions on the amount of data that may be returned by a query? How many queries / clients may run at a time?        
Performance     The Data Managers and MDRs should not degrade the performance of Data Adapters by more than 15%        
Scalability     COSMOS 1.0 will support a single Data Manager and Management Domain. How many MDRs and Data Managers may be added? Should there be any other scalability considerations?       
Stability       There are no Stability quality expectations    
Stress  There are no Stress quality expectations       

Thanks,

Jimmy Mohsin

Cell   +1-609-635-1703