Skip to content

Commit

Permalink
Example of dashboards/widgets (experimental)
Browse files Browse the repository at this point in the history
  • Loading branch information
@semancik
semancik committed Jan 28, 2019
1 parent 7f4b8a3 commit c5c773c
Show file tree
Hide file tree
Showing 3 changed files with 338 additions and 35 deletions.
131 changes: 131 additions & 0 deletions infra/schema/src/main/resources/xml/ns/public/common/common-core-3.xsd
View file
Expand Up @@ -15163,9 +15163,19 @@
</xsd:annotation>
</xsd:element>
<!-- Note: collection references such as domanin or baseCollection may point to collection or archetype. Maybe even to org or role. -->

<!-- TODO: domain (filter or reference to another collection) -->
<!-- TODO: tresholds (actions should be performed by policy rules) -->
<!-- TODO(maybe): default view specification, e.g. default set of columns, search, etc. -->

<xsd:element name="stats" type="tns:CollectionStatsType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:appinfo>
<a:since>4.0</a:since>
<a:experimental>true</a:experimental>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
Expand Down Expand Up @@ -15329,6 +15339,125 @@
</xsd:enumeration>
</xsd:restriction>
</xsd:simpleType>

<xsd:complexType name="CollectionStatsType">
<xsd:annotation>
<xsd:documentation>
<p>
Stats (statistics) setting and entries. This contains stats entries for collections.
Simply speaking, it contains data about number of objects in collection.
</p>
<p>
While counting collections is usually quite easy, we do not want to do that every
millisecond. Therefore we count the collection and keep the data in this structure
for a while. The data may not necessarily be persistent. This may be purely vitual data
that never get stored in the repository. Ot it may be cached data. Or some combination.
We also may want to store historical data about the collection for informational purposes.
</p>
<p>
EXPERIMENTAL. Do not rely on this data structure.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:container/>
<a:since>4.0</a:since>
<a:experimental>true</a:experimental>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<!-- TODO (later): configuration of stats collection: virtual/cached, caching freshness, number of stats, intervals, etc. -->
<xsd:element name="statEntry" type="tns:IntegerStatType" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Stat (statistic) entry. This entry contains stat value, together with domain value.
The purpose is that both absolute values and percentages can be determined.
</p>
<p>
Single-valued now. This represents the latest known value.
Will be changed to multi-valued later. Multi-valued stat entries
may contain historical values for informational purposes, e.g. displaying "trends"
in widgets and reports.
</p>
</xsd:documentation>
<xsd:appinfo>
<a:since>4.0</a:since>
<a:operational>true</a:operational>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="IntegerStatType">
<xsd:annotation>
<xsd:documentation>
Integer stat (statistic) entry. This entry contains stat value, together with domain value.
The purpose is that both absolute values and percentages can be determined. The entry contains
(optional) timestamp to determine freshness of the data and/or sort and plot them.
</xsd:documentation>
<xsd:appinfo>
<a:container/>
<a:since>4.0</a:since>
<a:experimental>true</a:experimental>
</xsd:appinfo>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="value" type="xsd:int" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Primary (absolute) value of that stat. This is the value that we are interested in.
E.g. this is the number of objects in collection.
</p>
<p>
Even though this is a primary value, it is optional. There may be rare cases
when we do not have primary value, we only have percentage data.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="domain" type="xsd:int" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Size of the domain. This is the value of "all things" used to compute percentage.
E.g. this is the number of object in collection domain.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="percentage" type="xsd:float" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Percentage value. This is usually not present, as it may be easily computed
from value and domain. But for rare cases there may be just the percentage and
the primary value may be missing.
</p>
<p>
Implementation note: Having percentage here also makes it easier for implementation.
The code can use the same data structure to store intermediate values, e.g.
stat with computed percentage. The collection-processing code can also fill
in the percentage value automatically, even if it is not stored in repository.
This is somehow simimar to the way provisioning code fills in the attributes
into the shadow.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="timestamp" type="xsd:dateTime" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<p>
Sampling timestamp. The timestamp of the moment when the value was
retrieved or computed.
</p>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>

<xsd:complexType name="InternalsConfigurationType">
<xsd:annotation>
Expand Down Expand Up @@ -22054,6 +22183,8 @@
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
<!-- TODO: color.
This color is different than icon color. It is the color of the thing itself. E.g. color of form or widget. Icon may have independent color. -->
<!-- style properties -->
<xsd:element name="cssStyle" type="xsd:string" minOccurs="0">
<xsd:annotation>
Expand Down
23 changes: 12 additions & 11 deletions samples/experimental/collection-resources-up.xml
View file
Expand Up @@ -33,13 +33,21 @@
<type>ResourceType</type>
</domainCollection>
<!-- TODO: maybe we would like to define default view here. E.g. default list of columns. -->


<!-- We really like to define default thresholds here.
We want to use thresholds in scanner tasks, notifications and so on.
We may want to send the notification when the widget turns red.
But the there may be also more specific thresholds. W.g. turn widget orange,
but do not send any notification about that. -->
<assignment>
<policyRule>
<policyConstraints>
<collection> <!-- or just <collection/> should be enough. Default interpretation should be explicit. -->
<interpretation>explicit</interpretation>
</collection>
<!-- The thresholds are defined as policy rules with a special constraint.
The <collection> constraint means, the the rule should not look at the collection definition.
The rule should look at the collected objects. -->
<collectionStats> <!-- or just <collectionStats/> should be enough. Default interpretation for ObjectCollectionType should be "explicit". -->
<collectionInterpretation>explicit</collectionInterpretation>
</collectionStats>
</policyConstraints>
<policyThreshold>
<lowerBound> <!-- lowWaterMark? -->
Expand All @@ -52,11 +60,4 @@
</policyRule>
</assignment>

<!-- TODO: Maybe we would like to define default thresholds here.
We want to use thresholds in scanner tasks, notifications and so on.
We may want to send the notification when the widget turns red.
But the there may be also more specific thresholds. W.g. turn widget orange,
but do not send any notification about that. -->
<!-- Maybe align with policy rules?
Reaching a threshold may cause an action that may be the same or similar to policy rule actions. -->
</objectCollection>

0 comments on commit c5c773c

Please sign in to comment.