[Hawkular-dev] Resource Path view in UI

[Jay Shaughnessy]

On 9/15/2015 6:46 AM, Lukas Krejci wrote:
> On Monday, September 14, 2015 15:46:28 Liz Clayton wrote:
>> Hi,
>>
>> On Thu, Sep 10, 2015 at 4:07 PM, John Mazzitelli <mazz at redhat.com> wrote:
>>> Correct me if I'm wrong, but doesn't the agent store the resource "name"
>>> in the inventory's properties? I thought each resource has a set of
>>> properties associated with it and the agent will populate a "name"
>>> property
>>> with the name of the resource in there. If so, you could use that to
>>> display the name of the resource.
>> So we can refer to the resource by "name," in the Alert center summary
>> view?
>>
> Well, yes and no. The name of a resource describes what the resource is in a
> human readable way but doesn't place it in a hierarchy. For example if you
> have a deployment "app.war", that name is not enough to distinguish between 5
> such deployments, each on a different server. If more of them end up in the
> summary view, the user wouldn't be able to tell them apart.
>
> The resources are hierarchical and that hierarchy is expressed in the resource
> path. The problem is that resource path is essentially an internal
> representation, using slash-separated, type-annotated IDs, not names (which
> are editable, unlike IDs).
>
> In RHQ, this was solved by a showing an "ancestry" of a resource - the
> ancestry would start by the name of the resource itself and would also show
> the names of all the resources "above it" in the hierarchy, separated by a
> "<". E.g. "app.war < EAP15". On hover, this was further expanded to include
> the types of the individual resources in the ancestry to futher help with
> resolving possible name duplicates.
>
> To remain performant, this would probably need some support in the backend
> (the same way it had support in RHQ) that would pre-compute those
> "hierarchical names" so that the UI wouldn't need to query for them every time
> it needed it for every row in the summary.

+1, I think a pre-computed value is the way to go.   For details on the 
RHQ approach, see here:

https://docs.jboss.org/author/display/RHQ/Disambiguation+API#DisambiguationAPI-RHQ4Changes

I'm not sure we'd need all of the type info, etc, but certainly the 
hierarchy of resource names.  It depends on whether we want to offer 
links to the ancestry resources.

>>> Of course, you would need to query inventory for those properties and
>>> you'd need to do the same query for each ancestor (parent, grandparent,
>>> etc) if you want to show the names in an ancestry field.
>> And the details view would/could show the path, or the name:value for each
>> item in the path?
> I think I sort of answered this already above.
>
>> Thanks,
>> Liz
>>
>>> ----- Original Message -----
>>>
>>>> Now that we have switched to Resource Paths (canonical paths from
>>> Inventory)
>>>
>>>> it has come up that displaying the resource path is not very readable
>>>> and
>>>> requires parsing to make sense of it.
>>>>
>>>> Please see the current use case as example:
>>>> https://issues.jboss.org/secure/attachment/12392747/AlertCenter2.jpg
>>>> https://issues.jboss.org/secure/attachment/12392582/Alert-detailsnu.jpg
>>>> An example resource path:
>>> /t;28026b36-8fe4-4332-84c8-524e173a68bf/e;test/f;localhost/r;localhost~Loc
>>> al~~>
>>>> To further break the above example into its pieces:
>>>> tenantId : /t;28026b36-8fe4-4332-84c8-524e173a68bf
>>>> environment : test
>>>> feed : localhost
>>>> resourceId : localhost
>>>>
>>>>
>>>>
>>>> The following snippet explaining the resource path was extracted from:
>>>> http://www.hawkular.org/docs/components/inventory/index.html
>>>>
>>>> Canonical Paths
>>>>
>>>> A canonical path follows the contains relationships from a tenant down
>>> to the
>>>
>>>> entity in question.
>>>>
>>>>
>>>> The canonical path has a form illustrated by the following example:
>>>> /t; tenant-id /e; env-id /r; resource-id
>>>>
>>>>
>>>> The above example is a canonical path to a resource with ID resource-id
>>> which
>>>
>>>> is located in environment env-id which is inside a tenant tenant-id .
>>>>
>>>> The type specifiers in the individual path segments can be these:
>>>>      *
>>>>
>>>> t - tenant
>>>>
>>>>      *
>>>>
>>>> e - environment
>>>>
>>>>      *
>>>>
>>>> rt - resource type
>>>>
>>>>      *
>>>>
>>>> mt - metric type
>>>>
>>>>      *
>>>>
>>>> f - feed
>>>>
>>>>      *
>>>>
>>>> r - resource
>>>>
>>>>      *
>>>>
>>>> m - metric
>>>>
>>>> And as I understand it, the resource path also contains the parent
>>> resource
>>>
>>>> prepended to this. So one can always figure out where the resource came
>>> from
>>>
>>>> and can uniquely identify a resource.
>>>> A resource path is just one kind of canonical path (the others are given
>>> in
>>>
>>>> the above except).
>>>>
>>>>
>>>>
>>>> What fields should we parse out and display in the UI as individual
>>> fields?
>>>
>>>> I’ll start this conversation by assuming that the environment and tenant
>>> are
>>>
>>>> not very useful to display. Then what about feed? And since resource is
>>> what
>>>
>>>> we are after that one is obvious as needed.
>>>> WDYT?
>>>>
>>>> And then there is the question of how Ancestry path should be viewed —
>>> but
>>>
>>>> for now lets just stick to the above question of how should resources be
>>>> viewed in the UI?
>>>> Ancestry Path is another topic for later.
>>>>
>>>>
>>>> Please refer to Jira: https://issues.jboss.org/browse/HAWKULAR-605
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>> _______________________________________________
>>> hawkular-dev mailing list
>>> hawkular-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev