I think you have a point. We can indeed use the templates definitions for the
static datasources as well.
BTW, I noticed we already have a blueprint for this issue:
https://blueprints.launchpad.net/vitrage/+spec/add-direction-to-physical-topology-relationships,
but nobody has handled it so far.
Best Regards,
Ifat.
From: Yujun Zhang
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Thursday, 1 September 2016 at 05:51
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [vitrage] relationship_type in static_datasources
Hi, Ifat,
The static configuration contains definitions of `entities` and their
`relationships while the scenario templates contains a definition section which
includes `entities` and `relationships` between them. An outline of these two
format are as below.
static configuration
- entities
- {entity}
- {entity}
for each entity
- name:
id:
relationship:
- {relationship}
- {relationship}
scenario templates
- definitions
- entities
- {entity}
- {entity}
- relationships
- {relationship}
- {relationship}
Though serving different purpose, they both
1. describe entities and relationships
2. use a dedicated key (id/template_id) to reference the items
3. include a source entity and target entity in relationship
The main differences between the two are
* scenario defines rules (entity and relationship matching), graph update
is triggered when entities are added by datasource.
* static configuration defines rules and also add entities to graph
The rule definition are common to these two modules. We may define the static
configuration using the same format as scenario template. And then simulate an
entity discovery from the same file.
By reusing the template parsing engine and workflow, we may reduce the work in
maintenance and bring in new features more easily.
We may discuss it further if anything unclear.
On Tue, Aug 30, 2016 at 11:07 PM Afek, Ifat (Nokia - IL)
<ifat.a...@nokia.com<mailto:ifat.a...@nokia.com>> wrote:
Hi Yujun,
From: Yujun Zhang
Date: Monday, 29 August 2016 at 11:59
entities:
- type: switch
name: switch-1
id: switch-1 # should be same as name
state: available
relationships:
- type: nova.host
name: host-1
id: host-1 # should be same as name
is_source: true # entity is `source` in this relationship
relation_type: attached
- type: switch
name: switch-2
id: switch-2 # should be same as name
is_source: false # entity is `target` in this relationship
relation_type: backup
I think that’s the idea, instead of making this assumption in the code.
But I wonder why the static physical configuration file use a different format
from vitrage template definitions[1]
[1]
https://github.com/openstack/vitrage/blob/master/doc/source/vitrage-template-format.rst
What do you mean? The purpose of the templates is to describe the
condition-action behaviour, wheres the purpose of the static configuration is
to define resources to be added to vitrage graph. Can you please explain how
you would make the formats more similar?
Best Regards,
Ifat.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
