[jira] [Assigned] (ARIA-180) Convert many-to-many for parameter models to one-to-many
[
https://issues.apache.org/jira/browse/ARIA-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avia Efrat reassigned ARIA-180:
---
Assignee: Avia Efrat
> Convert many-to-many for parameter models to one-to-many
>
>
> Key: ARIA-180
> URL: https://issues.apache.org/jira/browse/ARIA-180
> Project: AriaTosca
> Issue Type: Task
>Reporter: Tal Liron
>Assignee: Avia Efrat
>Priority: Minor
>
> We must first discuss this as a team to see if we agree that this is the best
> solution. (There was an early discussion between Tal and Maxim.)
> First let's point out that one-to-many is a special case of many-to-many, so
> that everything works fine now and continue to work fine.
> However, logically our code right now treats them as one-to-many: there is no
> case in which a {{Parameter}} model belongs to more than one model.
> Parameters are always copied to the new model, for example during
> instantiation, or during task creation.
> There are cons to using many-to-many in our case:
> * We generate lots of extra secondary tables, one for each potential
> relationship
> * Crawling back from a {{Parameter}} to its containing model is quite costly,
> as it involves a new SQL query to check for each possible relationship
> * Logical confusion: if we do not write our code to support one parameter
> belonging to one model, and yet a user can create such a relationship, what
> would happen?
> * Slower
> The one advantage of many-to-many is that we *could* potentially optimize in
> some cases where the parameter has an identical value and we know would never
> change, and thus could safely link it multiple times instead of copying it.
> This optimization, however, requires us to be 100% sure that the parameter is
> immutable: otherwise, if a user changes it (for example in a task) it would
> change for all other containers. The questions are: 1) are we ever sure of
> immutability? and 2) is this optimization worth the effort of implementing
> it? The optimization would only seem to save some disk space.
> Another advantage is that it's much easier to add new models that use
> {{Parameter}} by adding an extra table (many-to-many) rather than adding fk
> columns to an existing table. To that there is a simple answer: new models
> can definitely create many-to-many relationships to anything else. Using
> one-to-many for our own models doesn't preclude that. (And we can even add
> code that automatically tries to look through such many-to-many relationships
> in order to find a container.)
> If we decide to switch to one-to-many, we have two approached:
> * Straightforward: one foreign key in {{Parameter}} per each possible
> containing relationship. Pros: naturally supported in SQL, cons: we will have
> lots of fk columns per row in the {{Parameter}} table, whereby only one will
> be non-null.
> * Polymorphic one-to-many (type-and-id joins): {{Parameter}} only has a
> single general-purpose fk column and another column specifying the type of
> the fk (node, interface, task, etc.). Cons: we would need to investigate how
> to accomplish this in SQLAlchemy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (ARIA-250) Sporadic Appveyor failures even if all tests pass
Avia Efrat created ARIA-250:
---
Summary: Sporadic Appveyor failures even if all tests pass
Key: ARIA-250
URL: https://issues.apache.org/jira/browse/ARIA-250
Project: AriaTosca
Issue Type: Bug
Affects Versions: 0.1.0
Reporter: Avia Efrat
Priority: Minor
Sometimes, even if all the tests pass, we still get a failure from Appveyor:
{{ERROR: InvocationError:
'C:\\projects\\incubator-ariatosca\\.tox\\pywin\\Scripts\\pytest.EXE tests
--ignore=tests/end2end --cov-report term-missing --cov aria'}}
For reference, see:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-ariatosca/build/1.0.1484
compared to:
https://ci.appveyor.com/project/ApacheSoftwareFoundation/incubator-ariatosca/build/1.0.1485
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (ARIA-157) CLI unit tests for storing service-templates fail on appveyor
[ https://issues.apache.org/jira/browse/ARIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat resolved ARIA-157. - Resolution: Fixed Fix Version/s: 0.1.0 > CLI unit tests for storing service-templates fail on appveyor > - > > Key: ARIA-157 > URL: https://issues.apache.org/jira/browse/ARIA-157 > Project: AriaTosca > Issue Type: Bug >Reporter: Avia Efrat >Assignee: Avia Efrat > Fix For: 0.1.0 > > > The failing tests are: > test_store_no_exception > test_store_raises_exception_resulting_from_name_uniqueness > test_store_raises_exception > They pass on Travis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (ARIA-157) CLI unit tests for storing service-templates fail on appveyor
[ https://issues.apache.org/jira/browse/ARIA-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat reassigned ARIA-157: --- Assignee: Avia Efrat > CLI unit tests for storing service-templates fail on appveyor > - > > Key: ARIA-157 > URL: https://issues.apache.org/jira/browse/ARIA-157 > Project: AriaTosca > Issue Type: Bug >Reporter: Avia Efrat >Assignee: Avia Efrat > > The failing tests are: > test_store_no_exception > test_store_raises_exception_resulting_from_name_uniqueness > test_store_raises_exception > They pass on Travis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ARIA-210) Relative paths may cause issues in `aria service-templates` commands
[
https://issues.apache.org/jira/browse/ARIA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avia Efrat resolved ARIA-210.
-
Resolution: Fixed
Fix Version/s: 0.1.0
> Relative paths may cause issues in `aria service-templates` commands
>
>
> Key: ARIA-210
> URL: https://issues.apache.org/jira/browse/ARIA-210
> Project: AriaTosca
> Issue Type: Bug
>Reporter: Ran Ziv
>Assignee: Avia Efrat
> Fix For: 0.1.0
>
>
> The CLI commands {{aria service-templates store}} and {{aria
> service-templates create-archive}} use the {{os.path.dirname}} method to get
> the directory of the main service-template file.
> In the former ({{store}} command) this causes errors when the user is already
> in the directory of the main service-template file and passes the file
> directly (e.g. {{aria service-templates store service-template.yaml
> my-service-template}})) - It'll fail when trying to copy the
> service-template's resources like so:
> {{cannot copy tree '': not a directory}}
> In the latter ({{create-archive}}), any relative path usage will result in an
> error claiming the file does not exist.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (ARIA-210) Relative paths may cause issues in `aria service-templates` commands
[
https://issues.apache.org/jira/browse/ARIA-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Avia Efrat reassigned ARIA-210:
---
Assignee: Avia Efrat
> Relative paths may cause issues in `aria service-templates` commands
>
>
> Key: ARIA-210
> URL: https://issues.apache.org/jira/browse/ARIA-210
> Project: AriaTosca
> Issue Type: Bug
>Reporter: Ran Ziv
>Assignee: Avia Efrat
>
> The CLI commands {{aria service-templates store}} and {{aria
> service-templates create-archive}} use the {{os.path.dirname}} method to get
> the directory of the main service-template file.
> In the former ({{store}} command) this causes errors when the user is already
> in the directory of the main service-template file and passes the file
> directly (e.g. {{aria service-templates store service-template.yaml
> my-service-template}})) - It'll fail when trying to copy the
> service-template's resources like so:
> {{cannot copy tree '': not a directory}}
> In the latter ({{create-archive}}), any relative path usage will result in an
> error claiming the file does not exist.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (ARIA-156) Workflow runner continues to run when exception is raised on task_started event
[ https://issues.apache.org/jira/browse/ARIA-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat reassigned ARIA-156: --- Assignee: Avia Efrat > Workflow runner continues to run when exception is raised on task_started > event > --- > > Key: ARIA-156 > URL: https://issues.apache.org/jira/browse/ARIA-156 > Project: AriaTosca > Issue Type: Bug >Affects Versions: 0.1.0 >Reporter: Avia Efrat >Assignee: Avia Efrat > > If an exception is raised during _task_started, the engine continues to run, > but it finds no executable tasks or ended tasks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARIA-157) CLI service-template store tests fail on appveyor
Avia Efrat created ARIA-157: --- Summary: CLI service-template store tests fail on appveyor Key: ARIA-157 URL: https://issues.apache.org/jira/browse/ARIA-157 Project: AriaTosca Issue Type: Bug Reporter: Avia Efrat The failing tests are: test_store_no_exception test_store_raises_exception_resulting_from_name_uniqueness test_store_raises_exception They pass on Travis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARIA-156) Workflow runner continues to run when exception is raised in _task_started
Avia Efrat created ARIA-156: --- Summary: Workflow runner continues to run when exception is raised in _task_started Key: ARIA-156 URL: https://issues.apache.org/jira/browse/ARIA-156 Project: AriaTosca Issue Type: Bug Affects Versions: 0.1.0 Reporter: Avia Efrat If an exception is raised during _task_started, the engine continues to run, but it finds no executable tasks or ended tasks. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-143) Cancelling of workflow execution
[ https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-143: Description: Make the process of cancelling execution more robust: - Identify possible pitfalls and corner cases. - Implement force cancelling. ** *Conclusions:* Unhandled execution status transitions resulting from cancelling an execution via the CLI, that we indentified and tried to address: TERMINATED -> CANCELLING You cancel the execution, but by the time we try to set the status to CANCELLING, the execution thread had already finished, and therefore, in SUCCEEDED status. FAILED -> CANCELLING You cancel the execution, but by the time we try to set the status to CANCELLING, the execution thread had already encountered an error, and therefore, in FAILED state. TERMINATED -> CANCELLED Similar to #1, but with CANCELLED instead of CANCELLING. FAILED -> CANCELLED Similar to #1, but with CANCELLED instead of CANCELLING. In all of the above cases (#1-#4), we skip updating the execution status, and log that the execution already succeeded/failed before we were able to cancel it. CANCELLING -> STARTED You cancel the execution while it is still in pending state. Meanwhile, while the execution status was already set to CANCELLING, we try to set the execution status CANCELLED -> STARTED Similar to #5, but after the status is set to CANCELLING, it also gets set to CANCELLED before attempting to set it to STARTED. In cases #5-#6, we skip updtating the execution status, and nothing is logged. was: Make the process of cancelling execution more robust: - Identify possible pitfalls and corner cases. - Implement force cancelling. > Cancelling of workflow execution > > > Key: ARIA-143 > URL: https://issues.apache.org/jira/browse/ARIA-143 > Project: AriaTosca > Issue Type: Story >Affects Versions: 0.1.0 >Reporter: Avia Efrat >Assignee: Avia Efrat > > Make the process of cancelling execution more robust: > - Identify possible pitfalls and corner cases. > - Implement force cancelling. > ** > *Conclusions:* > Unhandled execution status transitions resulting from cancelling an > execution via the CLI, that we indentified and tried to address: > TERMINATED -> CANCELLING > You cancel the execution, but by the time we try to set the status to > CANCELLING, the execution thread had already finished, and therefore, in > SUCCEEDED status. > FAILED -> CANCELLING > You cancel the execution, but by the time we try to set the status to > CANCELLING, the execution thread had already encountered an error, and > therefore, in > FAILED state. > TERMINATED -> CANCELLED > Similar to #1, but with CANCELLED instead of CANCELLING. > FAILED -> CANCELLED > Similar to #1, but with CANCELLED instead of CANCELLING. > In all of the above cases (#1-#4), we skip updating the execution status, > and log that the execution already succeeded/failed before we were able > to cancel it. > CANCELLING -> STARTED > You cancel the execution while it is still in pending state. Meanwhile, > while the execution status was already set to CANCELLING, we try to set > the execution status > CANCELLED -> STARTED > Similar to #5, but after the status is set to CANCELLING, it also gets > set to CANCELLED before attempting to set it to STARTED. > In cases #5-#6, we skip updtating the execution status, and nothing is logged. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (ARIA-143) Cancelling of workflow execution
[ https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat resolved ARIA-143. - Resolution: Fixed > Cancelling of workflow execution > > > Key: ARIA-143 > URL: https://issues.apache.org/jira/browse/ARIA-143 > Project: AriaTosca > Issue Type: Story >Affects Versions: 0.1.0 >Reporter: Avia Efrat >Assignee: Avia Efrat > > Make the process of cancelling execution more robust: > - Identify possible pitfalls and corner cases. > - Implement force cancelling. > ** > *Conclusions:* > Unhandled execution status transitions resulting from cancelling an > execution via the CLI, that we indentified and tried to address: > TERMINATED -> CANCELLING > You cancel the execution, but by the time we try to set the status to > CANCELLING, the execution thread had already finished, and therefore, in > SUCCEEDED status. > FAILED -> CANCELLING > You cancel the execution, but by the time we try to set the status to > CANCELLING, the execution thread had already encountered an error, and > therefore, in > FAILED state. > TERMINATED -> CANCELLED > Similar to #1, but with CANCELLED instead of CANCELLING. > FAILED -> CANCELLED > Similar to #1, but with CANCELLED instead of CANCELLING. > In all of the above cases (#1-#4), we skip updating the execution status, > and log that the execution already succeeded/failed before we were able > to cancel it. > CANCELLING -> STARTED > You cancel the execution while it is still in pending state. Meanwhile, > while the execution status was already set to CANCELLING, we try to set > the execution status > CANCELLED -> STARTED > Similar to #5, but after the status is set to CANCELLING, it also gets > set to CANCELLED before attempting to set it to STARTED. > In cases #5-#6, we skip updtating the execution status, and nothing is logged. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ARIA-143) Cancelling of workflow execution
[ https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat closed ARIA-143. --- > Cancelling of workflow execution > > > Key: ARIA-143 > URL: https://issues.apache.org/jira/browse/ARIA-143 > Project: AriaTosca > Issue Type: Story >Affects Versions: 0.1.0 >Reporter: Avia Efrat >Assignee: Avia Efrat > > Make the process of cancelling execution more robust: > - Identify possible pitfalls and corner cases. > - Implement force cancelling. > ** > *Conclusions:* > Unhandled execution status transitions resulting from cancelling an > execution via the CLI, that we indentified and tried to address: > TERMINATED -> CANCELLING > You cancel the execution, but by the time we try to set the status to > CANCELLING, the execution thread had already finished, and therefore, in > SUCCEEDED status. > FAILED -> CANCELLING > You cancel the execution, but by the time we try to set the status to > CANCELLING, the execution thread had already encountered an error, and > therefore, in > FAILED state. > TERMINATED -> CANCELLED > Similar to #1, but with CANCELLED instead of CANCELLING. > FAILED -> CANCELLED > Similar to #1, but with CANCELLED instead of CANCELLING. > In all of the above cases (#1-#4), we skip updating the execution status, > and log that the execution already succeeded/failed before we were able > to cancel it. > CANCELLING -> STARTED > You cancel the execution while it is still in pending state. Meanwhile, > while the execution status was already set to CANCELLING, we try to set > the execution status > CANCELLED -> STARTED > Similar to #5, but after the status is set to CANCELLING, it also gets > set to CANCELLED before attempting to set it to STARTED. > In cases #5-#6, we skip updtating the execution status, and nothing is logged. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-143) Improve cancelling of workflow execution
[ https://issues.apache.org/jira/browse/ARIA-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-143: Summary: Improve cancelling of workflow execution (was: Improve cancelling workflow execution) > Improve cancelling of workflow execution > > > Key: ARIA-143 > URL: https://issues.apache.org/jira/browse/ARIA-143 > Project: AriaTosca > Issue Type: Story >Affects Versions: 0.1.0 >Reporter: Avia Efrat >Assignee: Avia Efrat > > Make the process of cancelling execution more robust: > - Identify possible pitfalls and corner cases. > - Implement force cancelling. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARIA-143) Improve cancelling workflow execution
Avia Efrat created ARIA-143: --- Summary: Improve cancelling workflow execution Key: ARIA-143 URL: https://issues.apache.org/jira/browse/ARIA-143 Project: AriaTosca Issue Type: Story Affects Versions: 0.1.0 Reporter: Avia Efrat Assignee: Avia Efrat Make the process of cancelling execution more robust: - Identify possible pitfalls and corner cases. - Implement force cancelling. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (ARIA-133) Add status-related properties to Execution, Task and Node models
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat closed ARIA-133. --- > Add status-related properties to Execution, Task and Node models > > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > Fix For: 0.1.0 > > > We are adding those properties so it will be easier to filter these models > from storage according to their status, and to not make use of the their > `status` constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add status-related properties to Execution, Task and Node models
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Summary: Add status-related properties to Execution, Task and Node models (was: Add status-related methods to Execution, Task and Node models) > Add status-related properties to Execution, Task and Node models > > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding those properties so it will be easier to filter these models > from storage according to their status, and to not make use of the their > `status` constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add status-related methods to Execution, Task and Node models
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Summary: Add status-related methods to Execution, Task and Node models (was: Add status-related methods to the Execution, Task and Node models) > Add status-related methods to Execution, Task and Node models > - > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding those methods so it will be easier to filter these models from > storage according to their status, and to not make use of the their `status` > constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add status-related methods to the Execution, Task and Node models
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Description: We are adding those methods so it will be easier to filter these models from storage according to their status, and to not make use of the their `status` constants outside of the models themselves. (was: We are adding these methods so it will be easier to filter these models from storage according to their status, and to not make use of the their `status` constants outside of the models themselves.) > Add status-related methods to the Execution, Task and Node models > - > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding those methods so it will be easier to filter these models from > storage according to their status, and to not make use of the their `status` > constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add status-related methods to the Execution, Task and Node models
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Summary: Add status-related methods to the Execution, Task and Node models (was: Add status-related methods to the Execution and Task models) > Add status-related methods to the Execution, Task and Node models > - > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding these methods so it will be easier to filter these models from > storage according to their status, and to not make use of the their `status` > constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add status-related methods to the Execution and Task models
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Description: We are adding these methods so it will be easier to filter these models from storage according to their status, and to not make use of the their `status` constants outside of the models themselves. (was: We are adding these methods so it will be easier to filter executions and tasks from the storage according to their status, and to not make use of the their `status` constants outside of the models themselves.) > Add status-related methods to the Execution and Task models > --- > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding these methods so it will be easier to filter these models from > storage according to their status, and to not make use of the their `status` > constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add status-related methods to the Execution and Task models
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Summary: Add status-related methods to the Execution and Task models (was: Add is_active and is_ended methods to the Execution and Task model) > Add status-related methods to the Execution and Task models > --- > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding these methods so it will be easier to filter executions and > tasks from the storage according to their status, and to not make use of the > their `status` constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add is_active and is_ended methods to the Execution model
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Description: We are adding these methods so it will be easier to filter executions and tasks from the storage according to their status, and to not make use of the their `status` constants outside of the models themselves. (was: We are adding these functions so it will be easier to filter executions from the storage according to their status, and to not make use of the `status` constants outside of the Execution model.) > Add is_active and is_ended methods to the Execution model > - > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding these methods so it will be easier to filter executions and > tasks from the storage according to their status, and to not make use of the > their `status` constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-133) Add is_active and is_ended methods to the Execution and Task model
[ https://issues.apache.org/jira/browse/ARIA-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-133: Summary: Add is_active and is_ended methods to the Execution and Task model (was: Add is_active and is_ended methods to the Execution model) > Add is_active and is_ended methods to the Execution and Task model > -- > > Key: ARIA-133 > URL: https://issues.apache.org/jira/browse/ARIA-133 > Project: AriaTosca > Issue Type: Task >Reporter: Avia Efrat >Assignee: Avia Efrat >Priority: Minor > > We are adding these methods so it will be easier to filter executions and > tasks from the storage according to their status, and to not make use of the > their `status` constants outside of the models themselves. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARIA-133) Add is_active and is_ended methods to the Execution model
Avia Efrat created ARIA-133: --- Summary: Add is_active and is_ended methods to the Execution model Key: ARIA-133 URL: https://issues.apache.org/jira/browse/ARIA-133 Project: AriaTosca Issue Type: Task Reporter: Avia Efrat Assignee: Avia Efrat Priority: Minor We are adding these functions so it will be easier to filter executions from the storage according to their status, and to not make use of the `status` constants outside of the Execution model. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (ARIA-124) The 'simple topologies' of the tests are not tosca complient
Avia Efrat created ARIA-124: --- Summary: The 'simple topologies' of the tests are not tosca complient Key: ARIA-124 URL: https://issues.apache.org/jira/browse/ARIA-124 Project: AriaTosca Issue Type: Bug Reporter: Avia Efrat Priority: Minor We often use create_simple_topology_two_nodes and create_simple_topology_three_nodes in our tests. Thing is, the dependent node has both the requirement and the capability, while actually the requirement should be a part of the dependent node, and the capability a part of the dependency nodes. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (ARIA-96) Dependency versions strictness / conflicts
[ https://issues.apache.org/jira/browse/ARIA-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Avia Efrat updated ARIA-96: --- Description: When ARIA is used by another project, it might lead to dependency versions conflicts. Dependency versions should be made less strict (i.e. ranges). Alternatively we could consider vendoring some of the more common dependencies inside ARIA. -- Our conclusions: 1. Currently, don't vendor any library. 2. Use pip-tools (specifically, pip-compile) to manage our dependencies / requirement files. 3. requirements.in: The requirements.in will be read into `install_requires`, and includes loose dependencies (as possible, and only direct dependencies), as is common when installing using a setup.py file. Since we haven't tested ARIA with many versions of our dependencies, our dependencies are not very loose, but we are hoping to improve this as our project matures. Currently, when we provide an upper bound, it is either because of python 2.6 compatibility, or according to a semantic versioning (i.e. future versions that could break the current API). Lower boundaries are usually the lowest version that we tested with ARIA, or because version before are lacking functionality we are using. 4. requirements.txt: The requirements.txt is generated from requirements.in via pip-compile, and includes fixed-version dependencies, including all transitive dependencies, in order to provide an stable environment that ARIA is ensured to work on. 5. python 2.6 compatible dependencies: As pip-compile currently does not provide support for conditional dependencies (https://github.com/jazzband/pip-tools/issues/435), we are adding these dependencies explicitly in the setup.py via `extras_require`, and manually in the generated requirements.txt. We are also mentioning this issue in a comment in requirements.in. was: When ARIA is used by another project, it might lead to dependency versions conflicts. Dependency versions should be made less strict (i.e. ranges). Alternatively we could consider vendoring some of the more common dependencies inside ARIA. > Dependency versions strictness / conflicts > -- > > Key: ARIA-96 > URL: https://issues.apache.org/jira/browse/ARIA-96 > Project: AriaTosca > Issue Type: Task >Reporter: Ran Ziv >Assignee: Avia Efrat > > When ARIA is used by another project, it might lead to dependency versions > conflicts. > Dependency versions should be made less strict (i.e. ranges). > Alternatively we could consider vendoring some of the more common > dependencies inside ARIA. > -- > Our conclusions: > 1. Currently, don't vendor any library. > 2. Use pip-tools (specifically, pip-compile) to manage our dependencies / > requirement files. > 3. requirements.in: > The requirements.in will be read into `install_requires`, and includes loose > dependencies (as possible, and only direct dependencies), as is common when > installing using a setup.py file. > Since we haven't tested ARIA with many versions of our dependencies, our > dependencies are not very loose, but we are hoping to improve this as our > project matures. > Currently, when we provide an upper bound, it is either because of python 2.6 > compatibility, or according to a semantic versioning (i.e. future versions > that could break the current API). Lower boundaries are usually the lowest > version that we tested with ARIA, or because version before are lacking > functionality we are using. > 4. requirements.txt: > The requirements.txt is generated from requirements.in via pip-compile, and > includes fixed-version dependencies, including all transitive dependencies, > in order to provide an stable environment that ARIA is ensured to work on. > 5. python 2.6 compatible dependencies: > As pip-compile currently does not provide support for conditional > dependencies (https://github.com/jazzband/pip-tools/issues/435), we are > adding these dependencies explicitly in the setup.py via `extras_require`, > and manually in the generated requirements.txt. We are also mentioning this > issue in a comment in requirements.in. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
