11:27 a.m.
I am working in my own branch, but am about to introduce resource configuration and
operations to the resource type metadata. This was in part due to the UI folks needing the
hostname to show in the GUI.
I wanted to let people know what this looks like - speak now if you see problems.
The resourceType will now have as part of its attached metadata a list named
"resourceConfiguration" which consists of config property types (today, there is
only "name" associated with resource config property types, but you can envision
other things like "dataType" (for boolean, integers, etc)).
There is also a list of operations (today, consists of only a name and optional
"operationName").
The JSON for resourceType looks like this inside inventory (this is for the top level
"WildFly Server" type):
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"id": "WildFly Server",
"version": "0.1",
"properties":
{
"name": "WildFly Server",
"operations":
[
{
"name": "Reload Server",
"operationName": "reload"
}
],
"resourceConfiguration":
[
{
"name": "Hostname"
},
{
"name": "Max Heap"
},
{
"name": "Version"
}
]
}
A resource of this type would look like:
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"environment": "test",
"feed": "mazztower",
"id": "[Local Host~/]",
"type": <<<what I showed above>>>,
"properties":
{
"name": "WildFly Server [Local Host] [mazztower]",
"resourceConfiguration":
[
{
"name": "Version",
"value": "8.2.0.Final"
},
{
"name": "Hostname",
"value": "mazztower"
},
{
"name": "Max Heap",
"value": "477626368"
}
]
}
12:03 p.m.
What are the distinctions between config, trait, and metric?
On Jun 8, 2015, at 12:27 PM, John Mazzitelli <mazz(a)redhat.com>
wrote:
I am working in my own branch, but am about to introduce resource configuration and
operations to the resource type metadata. This was in part due to the UI folks needing the
hostname to show in the GUI.
I wanted to let people know what this looks like - speak now if you see problems.
The resourceType will now have as part of its attached metadata a list named
"resourceConfiguration" which consists of config property types (today, there is
only "name" associated with resource config property types, but you can envision
other things like "dataType" (for boolean, integers, etc)).
There is also a list of operations (today, consists of only a name and optional
"operationName").
The JSON for resourceType looks like this inside inventory (this is for the top level
"WildFly Server" type):
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"id": "WildFly Server",
"version": "0.1",
"properties":
{
"name": "WildFly Server",
"operations":
[
{
"name": "Reload Server",
"operationName": "reload"
}
],
"resourceConfiguration":
[
{
"name": "Hostname"
},
{
"name": "Max Heap"
},
{
"name": "Version"
}
]
}
A resource of this type would look like:
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"environment": "test",
"feed": "mazztower",
"id": "[Local Host~/]",
"type": <<<what I showed above>>>,
"properties":
{
"name": "WildFly Server [Local Host] [mazztower]",
"resourceConfiguration":
[
{
"name": "Version",
"value": "8.2.0.Final"
},
{
"name": "Hostname",
"value": "mazztower"
},
{
"name": "Max Heap",
"value": "477626368"
}
]
}
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
12:08 p.m.
there is no distinction between config or trait in this new stuff. In this new stuff, they
are one and the same. I store these values inside inventory, not metrics. Have we come up
with a design for traits? Are they handled separately and distinctly in inventory and
h-metrics?
Metrics are different. Metric definitions and Metric Types definitions are first-class
concepts and are stored in inventory separately (resource types have explicit
relationships to metric types, and resources have explicit relationships to metrics).
There is no such thing for configuration properties. So I store config props definitions
as properties directly on the resource type and config prop values directly on the
resource as properties (these are stored in inventory). The metric data (the actual values
collected) are obviously stored in h-metrics.
----- Original Message -----
What are the distinctions between config, trait, and metric?
> On Jun 8, 2015, at 12:27 PM, John Mazzitelli <mazz(a)redhat.com> wrote:
>
> I am working in my own branch, but am about to introduce resource
> configuration and operations to the resource type metadata. This was in
> part due to the UI folks needing the hostname to show in the GUI.
>
> I wanted to let people know what this looks like - speak now if you see
> problems.
>
> The resourceType will now have as part of its attached metadata a list
> named "resourceConfiguration" which consists of config property types
> (today, there is only "name" associated with resource config property
> types, but you can envision other things like "dataType" (for boolean,
> integers, etc)).
>
> There is also a list of operations (today, consists of only a name and
> optional "operationName").
>
> The JSON for resourceType looks like this inside inventory (this is for the
> top level "WildFly Server" type):
>
> "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
> "id": "WildFly Server",
> "version": "0.1",
> "properties":
> {
> "name": "WildFly Server",
> "operations":
> [
> {
> "name": "Reload Server",
> "operationName": "reload"
> }
> ],
> "resourceConfiguration":
> [
> {
> "name": "Hostname"
> },
> {
> "name": "Max Heap"
> },
> {
> "name": "Version"
> }
> ]
> }
>
> A resource of this type would look like:
>
> "tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
> "environment": "test",
> "feed": "mazztower",
> "id": "[Local Host~/]",
> "type": <<<what I showed above>>>,
> "properties":
> {
> "name": "WildFly Server [Local Host] [mazztower]",
> "resourceConfiguration":
> [
> {
> "name": "Version",
> "value": "8.2.0.Final"
> },
> {
> "name": "Hostname",
> "value": "mazztower"
> },
> {
> "name": "Max Heap",
> "value": "477626368"
> }
> ]
> }
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
3:15 a.m.
I am not 100% sure it is a good idea to store maps or other "rich" types as
property values in inventory as that may have influence on their indexability
or (altogether the ability to persist such objects).
There are for sure performance implications for doing so but we need to wait
for those until we have Titan running in dist. The in-memory database we're
using atm should be taken with a grain of salt for any supported features -
for one - transactions are only simulated using locks and property values are
just java-serialized.
On Monday, June 08, 2015 12:27:52 John Mazzitelli wrote:
I am working in my own branch, but am about to introduce resource
configuration and operations to the resource type metadata. This was in
part due to the UI folks needing the hostname to show in the GUI.
I wanted to let people know what this looks like - speak now if you see
problems.
The resourceType will now have as part of its attached metadata a list named
"resourceConfiguration" which consists of config property types (today,
there is only "name" associated with resource config property types, but
you can envision other things like "dataType" (for boolean, integers,
etc)).
There is also a list of operations (today, consists of only a name and
optional "operationName").
The JSON for resourceType looks like this inside inventory (this is for the
top level "WildFly Server" type):
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"id": "WildFly Server",
"version": "0.1",
"properties":
{
"name": "WildFly Server",
"operations":
[
{
"name": "Reload Server",
"operationName": "reload"
}
],
"resourceConfiguration":
[
{
"name": "Hostname"
},
{
"name": "Max Heap"
},
{
"name": "Version"
}
]
}
A resource of this type would look like:
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"environment": "test",
"feed": "mazztower",
"id": "[Local Host~/]",
"type": <<<what I showed above>>>,
"properties":
{
"name": "WildFly Server [Local Host] [mazztower]",
"resourceConfiguration":
[
{
"name": "Version",
"value": "8.2.0.Final"
},
{
"name": "Hostname",
"value": "mazztower"
},
{
"name": "Max Heap",
"value": "477626368"
}
]
}
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
5:38 a.m.
I am not 100% sure it is a good idea to store maps or other
"rich" types as
property values in inventory as that may have influence on their indexability
or (altogether the ability to persist such objects).
There are for sure performance implications for doing so but we need to wait
If this is true, then I *strongly* recommend you change the inventory API. Because in all
the inventory Blueprint objects that I've seen, they define properties as a Map of
Objects:
@JsonProperty("properties") Map<String, Object> properties)
When I saw this (and with lack of javadoc :)) I took this to mean I can store whatever I
want (and I took this to mean it is *OK* to store whatever I want).
If we want to discourage (or even not allow) the use of storing rich types, then that API
should be changed, to something like:
@JsonProperty("properties") Map<String, String> properties)
8:22 a.m.
On 8 Jun 2015, at 18:27, John Mazzitelli wrote:
I am working in my own branch, but am about to introduce resource
configuration and operations to the resource type metadata. This was
in part due to the UI folks needing the hostname to show in the GUI.
I wanted to let people know what this looks like - speak now if you
see problems.
The resourceType will now have as part of its attached metadata a list
named "resourceConfiguration" which consists of config property types
(today, there is only "name" associated with resource config property
types, but you can envision other things like "dataType" (for boolean,
integers, etc)).
There is also a list of operations (today, consists of only a name and
optional "operationName").
The JSON for resourceType looks like this inside inventory (this is
for the top level "WildFly Server" type):
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"id": "WildFly Server",
Are we sure that for the same thing (e.g. 'WildFly 8.2") we want to
have potentially different and/or duplicate definitions per tenant?
"version": "0.1",
"properties":
{
"name": "WildFly Server",
"operations":
[
{
"name": "Reload Server",
"operationName": "reload"
We need to add some security level to each operation
from the very start. None vs required may be enough
though.
}
],
"resourceConfiguration":
[
{
"name": "Hostname"
},
{
"name": "Max Heap"
},
{
"name": "Version"
}
]
}
A resource of this type would look like:
"tenant": "28026b36-8fe4-4332-84c8-524e173a68bf",
"environment": "test",
"feed": "mazztower",
"id": "[Local Host~/]",
"type": <<<what I showed above>>>,
Is that a "link" or embedded?
3488
days inactive
3489
days old
5 comments
4 participants
participants (4)
-
Heiko W.Rupp -
John Mazzitelli -
John Sanda -
Lukas Krejci