Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "COSMOS Design 214143"

(New page: Back to Data Reporting Design = '''Change History''' = {|{{BMTableStyle}} !align="left"|Name: !align="left"|Date: !align="left"|Revised Sections: |- |Sheldo...)
 
 
(8 intermediate revisions by 3 users not shown)
Line 26: Line 26:
 
|-
 
|-
 
| align="left" | Code
 
| align="left" | Code
| 2
+
| 1
 
|
 
|
 
|-
 
|-
 
| align="left" | Test
 
| align="left" | Test
| 0.5
+
| 0.4
 
|
 
|
 
|-
 
|-
 
| align="left" | Documentation
 
| align="left" | Documentation
| 0.5
+
| 0.2
 
|
 
|
 
|-
 
|-
 
| align="left" | Build and infrastructure
 
| align="left" | Build and infrastructure
| 0.2
+
| .2
 
|
 
|
 
|-
 
|-
Line 46: Line 46:
 
|-
 
|-
 
! align="right" | TOTAL
 
! align="right" | TOTAL
| 3.4
+
| 2
 
|
 
|
 
|}
 
|}
Line 64: Line 64:
  
 
The following illustrates how the navigation tree will present predefined queries.
 
The following illustrates how the navigation tree will present predefined queries.
 
+
<pre>
 
+MDR (Asset Repository)
 
+MDR (Asset Repository)
 
+MDR (Monitoring Repository)
 
+MDR (Monitoring Repository)
Line 77: Line 77:
 
           + All Statistical data from 12/2/2004 to 12/2/2005
 
           + All Statistical data from 12/2/2004 to 12/2/2005
 
           + All Statistical data from 12/2/2005 to 12/2/2006
 
           + All Statistical data from 12/2/2005 to 12/2/2006
 
+
</pre>
 
+
 
Note the above shows a "query tree".  The "MDR (Statistical Repository)" contains two top level queries that will query for statistical data based on the server id.  In contrast, each of these queries contain nested queries that
 
Note the above shows a "query tree".  The "MDR (Statistical Repository)" contains two top level queries that will query for statistical data based on the server id.  In contrast, each of these queries contain nested queries that
 
filter the queries further by date.  Note that this query tree defines away to organize the queries for a particular mdr.  Developers would create the corresponding cmdf query files to construct this query tree.  A registration mechanism is required in the data visualization component to recognize these cmdbf file and present this queries in the navigator view.
 
filter the queries further by date.  Note that this query tree defines away to organize the queries for a particular mdr.  Developers would create the corresponding cmdf query files to construct this query tree.  A registration mechanism is required in the data visualization component to recognize these cmdbf file and present this queries in the navigator view.
  
 
Meta data information should be associated with a query file that describes the query.  Tagging this file would also be useful.  The meta data file should also contain management rules that will match the data manager that this query should apply to.
 
Meta data information should be associated with a query file that describes the query.  Tagging this file would also be useful.  The meta data file should also contain management rules that will match the data manager that this query should apply to.
 +
 
=Design=
 
=Design=
 +
This enhancement improves the existing navigation widget that initially shows a list of data managers and MDRs.  As a result the intial state of the tree will contain top level nodes.
 +
 +
In order to create this query tree for MDRs an expand query object should be configure for MDRs to call a query tree builder servie.  This service is required that produces a list of nodes that represent a list of queries given some meta data.  For example, consider the case where the top level node represent a statistical MDR and asset MDR.  Each MDR should contain their own queries.  When the user expands a node a request that contains meta data information signifing the MDR type.  The service will take this information and produce a JSON that represents a query node. 
 +
 +
The syntax of the query node should have the following JSON structure:
 +
 +
<pre>
 +
{title:'Get all statistics from 11/2/02 to 11/5/05', classNode:'statQuery', id:'query91234'queryParameters:{startDate:'11/2/02', endDate:'11/5/05', mdr:'ui_resolve'}}
 +
</pre>
 +
 +
Note that the query node is composed of the following attributes:
 +
 +
*title - display name of the node
 +
*classNode - tag that is used to configure the cosmetic attributes of the query node
 +
*id - unique id
 +
*queryParameters - parameters that are needed when constructing a request to execute the cmdbf query.  A request is executed when the user selects the node.
 +
 +
==Registering a query==
 +
A developer will construct two files that registers a query with the COSMOS UI framework.  These files are as follows:
 +
*meta-data file
 +
*CMDBf query file
 +
 +
===Meta Data file===
 +
This file provides meta data information that describes the query.  The following are attributes defined in this file:
 +
*title - display name of the query
 +
*classNode - tag that is used to configure the cosmetic attributes of the query
 +
*id - unique id
 +
*queryParameters - parameters that are needed when constructing a request to execute the cmdbf query.  A request is executed when the user selects the node.
 +
Note: that the above attributes are the same attributes used to construct the query node.
 +
Therefore, the meta data file is as follows:
 +
<pre>
 +
{title:'Get all statistics from 11/2/02 to 11/5/05', classNode:'statQuery', id:'query91234'queryParameters:{startDate:'11/2/02', endDate:'11/5/05', mdr:'ui_resolve'}}
 +
</pre>
 +
<b>It is important to note that 'ui_resolve' is a keyword used to signify that the UI should resolve the value of the parameter by reading the information from the tree.  If the parameter can not be resolved by the current tree node the parent node will be read to resolve the parameter all the up to the root node.</b>
 +
==CMDBf query file==
 +
The CMDBf query file is a CMDBf query file template.  This is further explained in [https://bugs.eclipse.org/bugs/show_bug.cgi?id=214153| ER 214153]
 +
==Deploying the query files==
 +
The service will read the above two files from a specific directory.  The deployment mechanism is similar to the widget configuration mechanism used to configure the views in the COMSOS UI.  Specifically, a root directory will contain a directory tree that is grouped  by meta data tags.  These tags signify the type of MDRs each query files should be associated with.  For example, let's say the navigation tree displays two MDRs.  One MDR is tagged 'statistical' while the second MDR is tagged 'asset'.  The directory structure would be as follows:
 +
<pre>
 +
/statistical
 +
    /query1234.jprop
 +
    /query1234.xml
 +
/asset
 +
    /query364.jprop
 +
    /query364.xml
 +
</pre>
 +
 +
Note the above tree would add query nodes to the statistical and asset mdr.  The .jprop files contain the meta data information for the query and the .xml files define the cmdbf queries.
 +
 +
Now lets say we want to define sub queries under the query1234 we just defined.  Let say that the query1234.jprop file contains a nodeClass attribute set to 'mystatquery'.  The directory structure would be as follows:
 +
 +
<pre>
 +
/statistical
 +
    /query1234.jprop
 +
    /query1234.xml
 +
/asset
 +
    /query364.jprop
 +
    /query364.xml
 +
/mystatquery
 +
    /mysubquery.jprop
 +
    /mysubquery.xml
 +
</pre>
 +
 +
==Open Issues/Questions==
 +
 +
All reviewer feedback should go in the [[Talk:COSMOS_Design_214143|Talk page for 214143]].
 +
 +
 +
[[Category:COSMOS_Bugzilla_Designs]]

Latest revision as of 22:51, 4 March 2008

Back to Data Reporting Design

Change History

Name: Date: Revised Sections:
Sheldon Lee-Loy 01/07/2008
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 0.2 Sheldon Lee-Loy
Code 1
Test 0.4
Documentation 0.2
Build and infrastructure .2
Code review, etc.*
TOTAL 2

'* - includes other committer work (e.g. check-in, contribution tracking)

Purpose

Currently the navigation widget in the COMOSUI provides a mechanism to submit CMDBf queries to MDRs. These queries are constructed by the end user and are not persisted. As a result the queries are lost once the COSMOS UI application shutsdown.

Requirement

This enhancement proposes a mechanism for developers to register predefined cmdbf queries with the data visualization user interface.


The following illustrates a query that is useful against a statistical MDR: I want the memory usage data for the machine that is running the tomcat 59223 server?

A CMDBf query file would be created to capture the above query. A registry is needed to associate this query with a specific MDR that contains the information.

The following illustrates how the navigation tree will present predefined queries.

+MDR (Asset Repository)
+MDR (Monitoring Repository)
+MDR (Statistical Repository)
    + Tomcat Server 5912334
           + All Statistical data from 12/2/2003 to 12/2/2004
           + All Statistical data from 12/2/2004 to 12/2/2005
           + All Statistical data from 12/2/2005 to 12/2/2006
           + Memory Usage
    + Websphere Server 55224
           + All Statistical data from 12/2/2003 to 12/2/2004
           + All Statistical data from 12/2/2004 to 12/2/2005
           + All Statistical data from 12/2/2005 to 12/2/2006

Note the above shows a "query tree". The "MDR (Statistical Repository)" contains two top level queries that will query for statistical data based on the server id. In contrast, each of these queries contain nested queries that filter the queries further by date. Note that this query tree defines away to organize the queries for a particular mdr. Developers would create the corresponding cmdf query files to construct this query tree. A registration mechanism is required in the data visualization component to recognize these cmdbf file and present this queries in the navigator view.

Meta data information should be associated with a query file that describes the query. Tagging this file would also be useful. The meta data file should also contain management rules that will match the data manager that this query should apply to.

Design

This enhancement improves the existing navigation widget that initially shows a list of data managers and MDRs. As a result the intial state of the tree will contain top level nodes.

In order to create this query tree for MDRs an expand query object should be configure for MDRs to call a query tree builder servie. This service is required that produces a list of nodes that represent a list of queries given some meta data. For example, consider the case where the top level node represent a statistical MDR and asset MDR. Each MDR should contain their own queries. When the user expands a node a request that contains meta data information signifing the MDR type. The service will take this information and produce a JSON that represents a query node.

The syntax of the query node should have the following JSON structure:

{title:'Get all statistics from 11/2/02 to 11/5/05', classNode:'statQuery', id:'query91234'queryParameters:{startDate:'11/2/02', endDate:'11/5/05', mdr:'ui_resolve'}}

Note that the query node is composed of the following attributes:

  • title - display name of the node
  • classNode - tag that is used to configure the cosmetic attributes of the query node
  • id - unique id
  • queryParameters - parameters that are needed when constructing a request to execute the cmdbf query. A request is executed when the user selects the node.

Registering a query

A developer will construct two files that registers a query with the COSMOS UI framework. These files are as follows:

  • meta-data file
  • CMDBf query file

Meta Data file

This file provides meta data information that describes the query. The following are attributes defined in this file:

  • title - display name of the query
  • classNode - tag that is used to configure the cosmetic attributes of the query
  • id - unique id
  • queryParameters - parameters that are needed when constructing a request to execute the cmdbf query. A request is executed when the user selects the node.

Note: that the above attributes are the same attributes used to construct the query node. Therefore, the meta data file is as follows:

{title:'Get all statistics from 11/2/02 to 11/5/05', classNode:'statQuery', id:'query91234'queryParameters:{startDate:'11/2/02', endDate:'11/5/05', mdr:'ui_resolve'}}

It is important to note that 'ui_resolve' is a keyword used to signify that the UI should resolve the value of the parameter by reading the information from the tree. If the parameter can not be resolved by the current tree node the parent node will be read to resolve the parameter all the up to the root node.

CMDBf query file

The CMDBf query file is a CMDBf query file template. This is further explained in ER 214153

Deploying the query files

The service will read the above two files from a specific directory. The deployment mechanism is similar to the widget configuration mechanism used to configure the views in the COMSOS UI. Specifically, a root directory will contain a directory tree that is grouped by meta data tags. These tags signify the type of MDRs each query files should be associated with. For example, let's say the navigation tree displays two MDRs. One MDR is tagged 'statistical' while the second MDR is tagged 'asset'. The directory structure would be as follows:

/statistical
    /query1234.jprop
    /query1234.xml
/asset
    /query364.jprop
    /query364.xml

Note the above tree would add query nodes to the statistical and asset mdr. The .jprop files contain the meta data information for the query and the .xml files define the cmdbf queries.

Now lets say we want to define sub queries under the query1234 we just defined. Let say that the query1234.jprop file contains a nodeClass attribute set to 'mystatquery'. The directory structure would be as follows:

/statistical
    /query1234.jprop
    /query1234.xml
/asset
    /query364.jprop
    /query364.xml
/mystatquery
    /mysubquery.jprop
    /mysubquery.xml

Open Issues/Questions

All reviewer feedback should go in the Talk page for 214143.

Back to the top