Open Stack

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.afek at nokia.com<mailto:ifat.afek at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160901/17157797/attachment.html>