| 04:10.19 | *** join/#asterisk-dev tsearle (~tsearle@ptr-9d61wra7jtlf76208gt.18120a2.ip6.access.telenet.be) |
| 04:10.19 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 05:41.12 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.100) |
| 06:41.22 | *** join/#asterisk-dev elguero (~miguel323@74-95-21-41-Connecticut.hfc.comcastbusiness.net) |
| 07:28.11 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:5037:518b:d158:69a2) |
| 07:28.35 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:5037:518b:d158:69a2) |
| 07:34.13 | pchero_work | Hi team. :) |
| 07:34.26 | pchero_work | May I get some help for this? https://jenkins2.asterisk.org/job/asterisk-gatetests/job/master/1065/testReport/junit/channels/SIP/_____channels___acl_call/ |
| 07:34.38 | pchero_work | I'm not clear why it returns error... |
| 07:35.59 | pchero_work | Ah.. I can see it why.. -_-;;; |
| 08:06.37 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.62) |
| 08:33.14 | pchero_work | Could someone help me? I'd like to run the gatetest again for this one. To just see this is working or not.. |
| 08:33.15 | pchero_work | https://gerrit.asterisk.org/c/asterisk/+/13806 |
| 09:02.21 | jkroon | for interests sake, the "Build Unstable" stuff coming through on most submissions at +2 CR level ... are these generally expected or is there fault with one of the tests? |
| 09:03.22 | jkroon | Not sure how a change to res_rtp_asterisk can cause tests/channels/SIP/acl_call to get a 503 response when it's expecting a 100 ... i'm guessing that at that stage when 100 should be generated we've not even started to look at RTP related stuff ... |
| 09:08.14 | pchero_work | Thanks for answer me. :) Btw, it's not about rtp, it's about the res_pjsip_session |
| 09:09.07 | pchero_work | Because of my change didn't consider the role, it just return/reply the request before hits ACL. So, the test has failed - imho. |
| 10:25.41 | jkroon | bwahahaha, no, we're talking about different things here. |
| 10:27.39 | jkroon | gtjoseph, looking at the history of the referenced issue, looks like you're in a position to regate, as i'd be interested in this myself, is there a way to get jenkins to run the test suite prior to going to +2 on review so that those of us doing WIP can get the test suite to run before presenting our patches? |
| 10:28.02 | jkroon | i'm guessing we'd need to set up our own test environment for that? |
| 10:28.29 | file | anyone can comment "regate" |
| 10:28.43 | jkroon | thanks file. @pchero_work - there you have it. |
| 10:28.55 | file | and acl_call is a known flakey test |
| 10:29.38 | jkroon | test_acl.c <-- this one? |
| 10:29.54 | file | do you mean unit test? |
| 10:30.01 | file | if so, then no, all unit tests should pass |
| 10:30.46 | jkroon | looking for the acl_call test to see if i can do something about it, i'm assuming it's in a different tree then? |
| 10:31.02 | file | that's a testsuite test, and it's a known failing test |
| 10:31.08 | jkroon | not sure what pchero_work is trying to test actually. |
| 10:31.16 | file | so it's in the testsuite project/repo |
| 10:31.48 | jkroon | shot. might take a peek later. this corona thing has suddenly put a relative amount of free time on my desk. |
| 10:32.15 | file | you can, ultimately it's a bit of a shrug because chan_sip doesn't really change |
| 10:32.37 | file | and I think it's a first revision kind of test, which can have its own timing issues/conditions |
| 10:33.31 | jkroon | was wondering... i've seen off late that "core waitfullybooted" doesn't really wait until everything is ready ... had to adjust other pieces of integration code to be aware of this ... |
| 10:34.03 | file | that's dependent upon the underlying modules |
| 10:34.25 | file | if modules spawn threads and other things, many don't wait for those to complete |
| 10:36.42 | pchero_work | jkroon: file: Thanks. :) |
| 10:36.59 | jkroon | that's good to know. i'm assuming the inability to connect to ami is one of those (listening thread) |
| 10:37.22 | file | possibly. |
| 10:37.39 | pchero_work | I thought there's some button to executing the regate test. -_-;; |
| 10:37.49 | file | nope, never been a button |
| 10:37.52 | file | you just comment regate |
| 10:38.13 | pchero_work | Yes, just commented and checked that. I love 21st century. ;) |
| 10:38.17 | jkroon | like black magic |
| 11:03.07 | seanbright | well that settles it. i will never touch sorcery/realtime again. |
| 11:03.14 | seanbright | what a relief |
| 11:03.55 | file | seanbright: sorcery you can |
| 11:03.57 | file | realtime is just... |
| 11:04.00 | file | fickle. |
| 11:50.40 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:5037:518b:d158:69a2) |
| 12:21.02 | seanbright | it's whac-a-mole |
| 12:52.24 | jkroon | seanbright, this sounds interesting at the very least. care to share? |
| 12:53.04 | seanbright | what sounds interesting? |
| 12:54.05 | jkroon | this: well that settles it. i will never touch sorcery/realtime again |
| 12:54.18 | seanbright | why is that interesting? |
| 12:55.55 | jkroon | well, for larger setups more and more the recommendations seems to be going towards RT / Sorcery ... so if there are major issues to the point where you make a statement like "i will never touch sorcery/realtime again" I would love to know what that is. |
| 12:56.07 | seanbright | gotcha |
| 12:56.31 | seanbright | my not being interested in working on sorcery/realtime will have no impact on the future of sorcery/realtime. |
| 12:59.24 | jkroon | this be true. but both as a (sporadic) dev as well as user of asterisk i still am intrigued. but i'll let it rest, your reasons are yours. |
| 13:01.00 | jkroon | there is one question I'm really interested to understand though ... named_acl's vs ast_acl's ... it seems there is some duplication of effort between the two here ... named_acl's really are named_ha's, and ast_acl's are a beast of a different complexity (where ACLs can reference other ACLs). |
| 13:11.14 | jkroon | whether that referral import is static (ie, load time) or dynamic (ie, eval time) is currently unclear to me (I suspect load time, ie, no effective realtime) |
| 13:12.31 | file | it is load time. |
| 13:19.27 | jkroon | same for realtime? |
| 13:19.45 | file | I'm not sure to what you are referring |
| 13:20.22 | jkroon | named_acls can be realtime, so if I set "acl = some_realtime_name" elsewhere ... is that also evaluated at load time? |
| 13:20.26 | file | yes |
| 13:20.40 | file | specifically, when the consumer of it all asks for it |
| 13:20.53 | file | which is generally at the load time of the respective functionality |
| 13:20.56 | jkroon | seanbright, so there you have my newest "realtime" story. |
| 13:21.30 | jkroon | thanks file - i do appreciate the depth of your knowledge around things asterisk. |
| 13:21.56 | file | I have less of a qualm with realtime itself, although it's annoying, but my frustration is generally from users themselves and the expectations they have on it without understanding the consequences |
| 13:22.19 | file | it's not a magic bullet and doesn't make stuff magically scale with no cost |
| 13:23.25 | jkroon | yea, i would really have loved if the answers to your questions were "dyanamic", and that realtime ACLs gets cached for a certain time ... but alas, as you say, the cost could potentially be severe. |
| 13:24.18 | file | sorcery has caching functionality, but even with that it requires understanding by the user and tweaking based on deployment and usage pattern |
| 13:24.20 | jkroon | my *experience* has been that barring reloads non-realtime actually outperforms realtime. however, once you start hitting larger volumes of peers then the reload times do become an issue, especially if processing blocks for that specific module. |
| 13:24.43 | jkroon | eg ... chan_sip :( |
| 23:14.56 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 23:14.56 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 23:27.16 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 23:27.37 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:5037:518b:d158:69a2) |