All,
I
have opened ER 216210 to address this email trail below. I have marked
this for i10.
Thanks,
Jimmy Mohsin
Cell +1-609-635-1703
From:
cosmos-dev-bounces@xxxxxxxxxxx [mailto:cosmos-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mohsin, Jimmy
Sent: Tuesday, January 22, 2008 6:00 PM
To: Cosmos Dev
Subject: [cosmos-dev] COSMOS 1.0 - Recommended operational guidelines
fromboth hardware & software perspectives
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