Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 31, 2015, 10:58 a.m.) Status -- This change has been discarded. Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- This review has been moved to gerrit: https://gerrit.asterisk.org/#/c/18/ When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Babs' scenario: tests the situation where a channel is originated under normal conditions and then the channel is hungup. For this case, the test verifies that Stasis correctly assigns SUCCESS to STASISSTATUS. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/monitor.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 31, 2015, 10:58 a.m.) Review request for Asterisk Developers. Changes --- Noted in the description that the review has been moved to gerrit. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description (updated) --- This review has been moved to gerrit: https://gerrit.asterisk.org/#/c/18/ When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Babs' scenario: tests the situation where a channel is originated under normal conditions and then the channel is hungup. For this case, the test verifies that Stasis correctly assigns SUCCESS to STASISSTATUS. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/monitor.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:02 a.m.) Review request for Asterisk Developers. Changes --- Changed reference to STASIS_STATUS to STASISSTATUS Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description (updated) --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 1:15 p.m., Kevin Harwell wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py, lines 351-352 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72742#file72742line351 I would opt for the python convention of easier to ask forgiveness... and wrap this in a try/except block instead. I updated the on_channeldestroyed function also. - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14800 --- On March 27, 2015, 10:02 a.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:02 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14902 --- ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py https://reviewboard.asterisk.org/r/4520/#comment25524 This function is very similar (if not the same) as the function on line 184. - Ashley Sanders On March 27, 2015, 10:02 a.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:02 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 11:23 a.m., Matt Jordan wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py, lines 20-26 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72750#file72750line20 You may want to consider moving this class back into runtest. While pulling other classes out of the runtest 'module' may be good, particularly since some of those could act as infrastructure for other tests, the typical approach in the testsuite is to put the class that orchestrates a test into that module. Ashley Sanders wrote: For this, I would argue that the test_case introduced by this test is actually a new, generalized variant of the base type of TestCase (the name needs to be modified a bit, though). I think that it would make more sense to move the test_scenario_factory back into run-test, considering that is where all the specialized logic lives. Thoughts? I don't disagree that this *could* go in that direction. But for it to be truly generic, you'd want to: (a) As you noted, change some of the naming and place it in lib/python/asterisk (b) Have it be a test object in the pluggable framework, which would have to take some careful thought about how it could be configured to look at a particular set of scenarios. Generally, once we have a 'generic' piece of functionality, we'd want for it to be instantiated via the TestRunner, and then have either other pluggable modules attach into it, or have small Python modules provided by the test attach to it. I do think having the scenario factory function get put into here would be fine. Overall, once you've got a reason to pull it out of run-test, I'm not against it - but I'm not sure this review is at that point. The other direction you could take would be fully pull it out in this review, make it generic, and put it in lib/python/asterisk. But that might be more work than is necessary at this point, and since we don't have a second test (yet!) that would make use of it, I'm not sure it is warranted. - Matt --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14783 --- On March 27, 2015, 10:58 a.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:58 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises two scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 2) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/monitor.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/sip.conf PRE-CREATION
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:56 a.m.) Review request for Asterisk Developers. Changes --- Applied updates according to the review comments. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs (updated) - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/monitor.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:58 a.m.) Review request for Asterisk Developers. Changes --- Modified the description to depict the revisions applied following the review feedback. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description (updated) --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises two scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 2) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/monitor.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 1:15 p.m., Kevin Harwell wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py, lines 22-23 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72750#file72750line22 A lot of the code in this object as well as others (AriClient, ObservableObject) looks similar to much of the code found in the AriTestObject or AriBaseTestObject. I'm thinking you can inherit instead from one of those two ARI test objects and simplify things greatly, overriding/adding methods where needed. You might even be able to get away with using the WebSocketEventModule and handling things like adding a channel to a bridge or disconnecting the websocket in raised callbacks. At least for a couple of these scenarios. For that though you would have to break the scenarios into separate tests. The issue with using the AriBaseTestObject (or any of its derived types) was that there are certain events that I must intercept to start monitoring for the channel variable in unusual ways. Also, I have the need to exercise ARI after I blow away the websocket out from underneath it. Having said that, there are many things in these classes that could be pulled up into one of the generalized classes (e.g. the observer logic, the channel variable monitor, the base test scenario class and the test case itself - assuming I change its name to something more generic.) At this point, I think I am going to defer to Matt's comment from another issue in this review (in a nutshell, he stated that pulling everything up at this point is overkill): --- mjordan comment begin here --- I don't disagree that this *could* go in that direction. But for it to be truly generic, you'd want to: (a) As you noted, change some of the naming and place it in lib/python/asterisk (b) Have it be a test object in the pluggable framework, which would have to take some careful thought about how it could be configured to look at a particular set of scenarios. Generally, once we have a 'generic' piece of functionality, we'd want for it to be instantiated via the TestRunner, and then have either other pluggable modules attach into it, or have small Python modules provided by the test attach to it. I do think having the scenario factory function get put into here would be fine. Overall, once you've got a reason to pull it out of run-test, I'm not against it - but I'm not sure this review is at that point. The other direction you could take would be fully pull it out in this review, make it generic, and put it in lib/python/asterisk. But that might be more work than is necessary at this point, and since we don't have a second test (yet!) that would make use of it, I'm not sure it is warranted. --- mjordan comment end here --- - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14800 --- On March 27, 2015, 10:58 a.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:58 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises two scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 2) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 1:15 p.m., Kevin Harwell wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py, lines 22-23 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72750#file72750line22 A lot of the code in this object as well as others (AriClient, ObservableObject) looks similar to much of the code found in the AriTestObject or AriBaseTestObject. I'm thinking you can inherit instead from one of those two ARI test objects and simplify things greatly, overriding/adding methods where needed. You might even be able to get away with using the WebSocketEventModule and handling things like adding a channel to a bridge or disconnecting the websocket in raised callbacks. At least for a couple of these scenarios. For that though you would have to break the scenarios into separate tests. Ashley Sanders wrote: The issue with using the AriBaseTestObject (or any of its derived types) was that there are certain events that I must intercept to start monitoring for the channel variable in unusual ways. Also, I have the need to exercise ARI after I blow away the websocket out from underneath it. Having said that, there are many things in these classes that could be pulled up into one of the generalized classes (e.g. the observer logic, the channel variable monitor, the base test scenario class and the test case itself - assuming I change its name to something more generic.) At this point, I think I am going to defer to Matt's comment from another issue in this review (in a nutshell, he stated that pulling everything up at this point is overkill): --- mjordan comment begin here --- I don't disagree that this *could* go in that direction. But for it to be truly generic, you'd want to: (a) As you noted, change some of the naming and place it in lib/python/asterisk (b) Have it be a test object in the pluggable framework, which would have to take some careful thought about how it could be configured to look at a particular set of scenarios. Generally, once we have a 'generic' piece of functionality, we'd want for it to be instantiated via the TestRunner, and then have either other pluggable modules attach into it, or have small Python modules provided by the test attach to it. I do think having the scenario factory function get put into here would be fine. Overall, once you've got a reason to pull it out of run-test, I'm not against it - but I'm not sure this review is at that point. The other direction you could take would be fully pull it out in this review, make it generic, and put it in lib/python/asterisk. But that might be more work than is necessary at this point, and since we don't have a second test (yet!) that would make use of it, I'm not sure it is warranted. --- mjordan comment end here --- That's fair enough. It looked like for the couple of test cases you had implemented you could get away with using one of the current ARI test objects as you can register to receive various events and you should also have access to the websocket in order to disconnect it when needed, but it sounds like you are still adding scenarios that might not fit as neatly. So I agree with Matt that merging that functionality (making it generic) for those changes into the current classes can be done later. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14800 --- On March 27, 2015, 10:58 a.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 27, 2015, 10:58 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises two scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 28, 2015, 12:37 a.m.) Review request for Asterisk Developers. Changes --- Updated the description to depict the Babs case that was re-added. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description (updated) --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises two scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Babs' scenario: tests the situation where a channel is originated under normal conditions and then the channel is hungup. For this case, the test verifies that Stasis correctly assigns SUCCESS to STASISSTATUS. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/monitor.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 28, 2015, 12:39 a.m.) Review request for Asterisk Developers. Changes --- changed 'two' to 'three' in the description field. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description (updated) --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASISSTATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASISSTATUS channel variable: 1) The 'Babs' scenario: tests the situation where a channel is originated under normal conditions and then the channel is hungup. For this case, the test verifies that Stasis correctly assigns SUCCESS to STASISSTATUS. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/monitor.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasisstatus/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 11:23 a.m., Matt Jordan wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py, lines 25-29 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72747#file72747line25 Rather than injecting a name down into the base class, how about having a method on the class that derived classes should override to provide the name? This would let you do something like: class ObservableObject(object): def get_name(self): return '' def __format__(self, format_spec): return self.__class__.__name__ + '[' + self.get_name() + ']' class ConcreteObserver(ObservableObject): def get_name(self): return self.__class__.__name__ While this would be cleaner - it's not going to make much sense for the more generalized classes (ari_client, monitor, abstract test_scenario) - which is where the 'name' property actually matters. I would still have to inject the value of name as a ctor parameter to get it to the overridden property in the generalized class. From your example above: class ObservableObject(object): def get_name(self): return '' def __format__(self, format_spec): return self.__class__.__name__ + '[' + self.get_name() + ']' class AriClient(ObservableObject): def get_name(self): return Scenario Name == What does this mean in terms of a generalization, though? class BabsTestScenario(ObservableObject): def get_name(self): return Babs == This makes a lot of sense for situations like this, though. As it is, I need to take the most conservative approach when dealing with generalized and specialized types implementing the same base type. The names, as redundant as it is, are injected all the way through the construction as a means of creating the logs with messages that are easier to decipher when dealing with multiple test cases running concurrently. Name is really just an 'id'. It is incredibly redundant on the concrete instance of TestScenario, that already prints NameTestScenario. Also, from the example, the value returned by ObservableObject.self.__class__.__name__ (the base type) is equal to ConcreteObserver.self.__class__.__name__ (the derived type). - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14783 --- On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 11:23 a.m., Matt Jordan wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py, lines 20-26 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72750#file72750line20 You may want to consider moving this class back into runtest. While pulling other classes out of the runtest 'module' may be good, particularly since some of those could act as infrastructure for other tests, the typical approach in the testsuite is to put the class that orchestrates a test into that module. For this, I would argue that the test_case introduced by this test is actually a new, generalized variant of the base type of TestCase (the name needs to be modified a bit, though). I think that it would make more sense to move the test_scenario_factory back into run-test, considering that is where all the specialized logic lives. Thoughts? - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14783 --- On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 1:15 p.m., Kevin Harwell wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf, lines 1-20 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72746#file72746line1 Convert this to use pjsip instead. Since technically, I did not need pjsip for this test, and that would have required an extra thing for me to get up and running, Matt informed me that I could use chan_sip instead. - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14800 --- On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 11:23 a.m., Matt Jordan wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py, lines 53-55 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72752#file72752line53 Rather than injecting a name, you can actually use the object type and - from it - use the name of the class as a unique way to identify the scenario: for scenario in [BabsTestScenario, BugsTestScenario, BusterTestScenario]: client = AriClient(host, port, credentials, scenario.__name__) obj = scenario(client, ami) scnearios.append(obj) This lets you remove the name parameter passed to the TestScenario objects. Based on my comment above regarding the get_name() function, I think the cleanest way is to keep this pattern (for now). Also, in the code above, the AriClient instance is created and then injected into the ctor for the TestScenario. So, the overriden value of 'name' is not available when the value is requested by the AriClient ctor, because the instance of TestScenario has not yet been created. - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14783 --- On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 11:23 a.m., Matt Jordan wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py, lines 195-198 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72752#file72752line195 I'm curious why you needed to check self.stopping/self.finished here. If you've already told the scenario to stop, then you are either: (a) Getting additional VarSet events, which you should be able to filter out by checking the Variable (b) Have some other logic error and have stopped too early, which feels like a problem with the test logic This is a moot point after the above comment. All of this is gone - I want the test to blow up if it finds itself in a wonky state. - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14783 --- On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 11:23 a.m., Matt Jordan wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py, lines 98-106 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72751#file72751line98 Since this isn't really an event handler, I'd rename it to 'finish_strategy' or something similar. Generally, this is always called by concrete implementations of the TestScenario, as opposed to something that this has subscribed to. This was an artifact remaining from one of the 213ish refactors... Originally, there was a separate concept of 'strategy' versus 'scenario'. At a certain point, I realized that all the strategy really is, is a specialized variant of the scenario. So, the concepts were combined but I failed to update this function signature. - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14783 --- On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
On March 24, 2015, 11:23 a.m., Matt Jordan wrote: ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test, lines 18-20 https://reviewboard.asterisk.org/r/4520/diff/1/?file=72748#file72748line18 Since the StasisStatusTestCase is located in the local test_case module, you don't need either of these variables. That was a mistake - I added the logger and my own flavor of 'DEBUG' when I was debugging the dependency injection of the factory. Those were supposed to be removed during cleanup before pushing to review. - Ashley --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14783 --- On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/run-test PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/http.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/extensions.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/ari.conf PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4520/diff/ Testing --- Thanks, Ashley Sanders -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/#review14800 --- ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py https://reviewboard.asterisk.org/r/4520/#comment25395 Is this method used someplace? If so I just missed it, if not then it can be removed. ./asterisk/trunk/tests/rest_api/applications/stasis_status/ari_client.py https://reviewboard.asterisk.org/r/4520/#comment25396 I would opt for the python convention of easier to ask forgiveness... and wrap this in a try/except block instead. ./asterisk/trunk/tests/rest_api/applications/stasis_status/configs/ast1/sip.conf https://reviewboard.asterisk.org/r/4520/#comment25404 Convert this to use pjsip instead. ./asterisk/trunk/tests/rest_api/applications/stasis_status/observable_object.py https://reviewboard.asterisk.org/r/4520/#comment25399 This function seems unused. If it is not needed it can be removed. ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml https://reviewboard.asterisk.org/r/4520/#comment25400 Looks like there are 5 ways :-) ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml https://reviewboard.asterisk.org/r/4520/#comment25401 13.3.0-rc1 was just release, so I believe this should be 13.4.0 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml https://reviewboard.asterisk.org/r/4520/#comment25402 A dependency needs to be added for the asterisk channel driver you are using so a conflict won't occur. ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py https://reviewboard.asterisk.org/r/4520/#comment25403 A lot of the code in this object as well as others (AriClient, ObservableObject) looks similar to much of the code found in the AriTestObject or AriBaseTestObject. I'm thinking you can inherit instead from one of those two ARI test objects and simplify things greatly, overriding/adding methods where needed. You might even be able to get away with using the WebSocketEventModule and handling things like adding a channel to a bridge or disconnecting the websocket in raised callbacks. At least for a couple of these scenarios. For that though you would have to break the scenarios into separate tests. - Kevin Harwell On March 22, 2015, 11:34 p.m., Ashley Sanders wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4520/ --- (Updated March 22, 2015, 11:34 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24802 https://issues.asterisk.org/jira/browse/ASTERISK-24802 Repository: testsuite Description --- When an error occurs while writing to a web socket, the web socket is disconnected and the event is logged. A side-effect of this, however, is that any application on the other side waiting for a response from Stasis is left hanging indefinitely (as there is no mechanism presently available for notifying interested parties about web socket error states in Stasis). This patch introduces a new channel variable: STASIS_STATUS to give outside applications context when errors occur in Stasis that interrupt normal processing. This test exercises three scenarios to elicit updates to the STASIS_STATUS channel variable: 1) The 'Babs' scenario: tests a nominal path of Stasis to verify the 'ACTIVE' state is correctly applied. For this test, a call is originated under normal conditions and then the system is polled for the value of STASIS_STATUS before the channel is hung up. 2) The 'Bugs' scenario: tests the situation where a call is originated requesting an app that was never registered in Stasis to verify the 'FAILED' state is correctly applied. 3) The 'Buster' scenario: tests the situation where an app that was registered in Stasis when call A was originated (and while call A is still active) but is no longer registered when call B is originated. Determines if the 'FAILED' state is correctly applied. ***Note*** This is a test. It is only a test. The review for the Asterisk source can be found at: https://reviewboard.asterisk.org/r/4519/ Diffs - ./asterisk/trunk/tests/rest_api/applications/tests.yaml 6547 ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario_factory.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_scenario.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py PRE-CREATION ./asterisk/trunk/tests/rest_api/applications/stasis_status/test-config.yaml PRE-CREATION
