You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ariatosca.apache.org by "Tal Liron (JIRA)" <ji...@apache.org> on 2017/08/11 20:48:00 UTC

[jira] [Created] (ARIA-344) Improve topology module

Tal Liron created ARIA-344:
------------------------------

             Summary: Improve topology module
                 Key: ARIA-344
                 URL: https://issues.apache.org/jira/browse/ARIA-344
             Project: AriaTosca
          Issue Type: Story
            Reporter: Tal Liron


This is a followup to ARIA-174.

1) Let's move the module to {{aria/topology}} from {{aria/orchestrator/topology}}. The module in fact is not related to orchestration, and many use cases for ARIA involve using parser+topology but not orchestration. This will produce a clean divide of ARIA's three major components: parser, topology manager, and workflow engine (orchestrator).

2) There are still parts of topology that exist in {{aria/parser}}, namely the consumers. We need to think here if we still want to keep the consumer API. If so, it should move to a more general location, so that both {{aria/parser}} and {{aria/topology}} would use the same API. That way all the parsing-related consumers will be in {{aria/parser}} and all the instantiation ones will be in {{aria/topology}}. Related to this, I see that currently we are creating a {{Topology}} instance for each consumer! There should be a shared one, perhaps sitting on a context. Thus, it may be worth looking at the relationship between consumers and context -- parser and topology would each have their own special contexts, although they would share a validation report mechanism (in a contained validation context?).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)