[
https://issues.apache.org/jira/browse/ARIA-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tal Liron updated ARIA-344:
---------------------------
Description:
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?).
3) Merge tests/instantiation into a new tests/topology.
4) Create a ReST documentation page for the topology module and test the
documentation.,
was:
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?).
> Improve topology module
> -----------------------
>
> Key: ARIA-344
> URL: https://issues.apache.org/jira/browse/ARIA-344
> Project: AriaTosca
> Issue Type: Task
> Reporter: Tal Liron
> Priority: Minor
>
> 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?).
> 3) Merge tests/instantiation into a new tests/topology.
> 4) Create a ReST documentation page for the topology module and test the
> documentation.,
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
