[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[geclipse-dev] AW: [g-Eclipse] Benchmarking/Monitoring Meeting Minutes
|
Redirecting this discussion to the dev-list...
Hi Pawel, Hi All,
> Maybe we should discuss more during out meeting, but I would like to
add
> some comments.
I agree with Kasia, we should have a separate meeting. This discussion
will go far beyond the scope of our weekly meeting. But we will talk
about organising this dedicated meeting ;-)
> For me tests, benchmarking, monitoring and deployment has some common
> features.
You're definitely right here and I totally agree that we should find a
common architecture/model for all these use cases. To be more specific I
think we should not come up with a new model for them but with an
extension of our current Grid model covering these use cases.
> All of them needs to:
> 1. prepare some data,
> 2. run job,
> 3. monitor status of the job,
> 4. collect data
> 5. visualise collected data.
Reminds me strongly on an "ordinary" Grid job, right?!
1. Prepare job description
2. Run job
3. Monitor status
4. Access resulting output
5. and optionally visualize this output
> 1. run some wizard to prepare test description
Job Description Wizard
> 2. runs the test
Submit the job
> 3. grid job are automatically monitored and status is presented in
Tests
View
... or in the Job View with the details in the Job Details View. Why the
hell do we need two xtra views?!
> 4. data is collected and written into test description in the results
part
... or accessible via the connection elements (which can be ANY
EFS-implementation).
> 5. results are shown to the user in Tests History view
As said before -> Job Details View
> As running, monitoring and collecting results is already implemented
in
> test infrastructure
It should also in the Job infrastructure, right?! So ...
> I see no reason to repeat it by other modules.
... why do we already repeat everything in the test framework?
So why not extending the job framework in order to cover all the use
cases we have for benchmarks, tests, etc.?! And furthermore making use
of the Job and Job Details View instead of inflating the number of views
again?!
... and one further comment concerning the visualization. I strongly
vote (once again) for preparing our own visualization to cover the use
cases of displaying "graphical job results". We are really running into
deep water if we are developing some visualization but nevertheless make
use of other engines in order to visualize our own stuff! Of course this
would require to integrate the visualization as abstraction layer into
the model and to make VTK just one implementation of it, but this is
what g-Eclipse is all about, right?!
Cheers, Mathias
