devel:irc-meetings:2016b
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| devel:irc-meetings:2016b [2016/11/07 17:12] – [IRC Devel Meeting - 2016-11-09] miconda | devel:irc-meetings:2016b [2016/11/08 18:28] (current) – [Minutes] qxork | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== IRC Devel Meeting - 2016-11-09 ====== | + | ====== IRC Devel Meeting - 2016-11-08 ====== |
| Date: | Date: | ||
| Line 60: | Line 60: | ||
| ===== Minutes ===== | ===== Minutes ===== | ||
| + | |||
| + | * 07:00 miconda: hello! | ||
| + | * 07:01 qxork: @miconda - hello | ||
| + | * 07:01 miconda: we will start the discussions soon … let’s allow 1-2 minutes more | ||
| + | * 07:01 qxork: ACK | ||
| + | * 07:01 miconda: hope everyone is doing well! | ||
| + | * 07:02 miconda: I know some are busy voting todate, so I hope not to keep this long | ||
| + | * 07:02 miconda: s/ | ||
| + | * 07:02 abalashov: Guten Nachmittag! | ||
| + | * 07:02 carstenbock: | ||
| + | * 07:03 miconda: abalashov: berlin had a perfect weather for your taste this autumn … you should have come around this time | ||
| + | * 07:03 qxork: I guess that means no humidity | ||
| + | * 07:03 carstenbock: | ||
| + | * 07:04 miconda: carstenbock: | ||
| + | * 07:04 abalashov: miconda: Berlin nearly always has perfect weather for my taste, except the warmer times in summer. | ||
| + | * 07:05 miconda: abalashov: quite often it’s not much summer around anyhow | ||
| + | * 07:05 miconda: ok — I guess we can start | ||
| + | * 07:05 qxork: =) | ||
| + | * 07:05 miconda: as usual, first are the major issues | ||
| + | * 07:05 miconda: if there is someting that people feel is not working as it should | ||
| + | * 07:05 miconda: code or admin wise | ||
| + | * 07:06 miconda: ok … so nothing reported here | ||
| + | * 07:06 miconda: I spent some time with code analyzers lately, in preparation to relocate files for 5.0, thinking that backporting later might be more dificult | ||
| + | * 07:07 miconda: I usually do it during the testing period, but this time I did another session earlier | ||
| + | * 07:07 abalashov: I have something I wanted to discuss, but I did not manage to put it on the agenda. | ||
| + | * 07:07 abalashov: It relates to mhomed=1 behaviour. | ||
| + | * 07:07 abalashov: I can also just post about it later if now is not the appropriate time. | ||
| + | * 07:08 miconda: abalashov: you can describe it shortly, let’s see if we can get someting now | ||
| + | * 07:08 miconda: if not, later ... | ||
| + | * 07:09 abalashov: Basically, if an interface has a primary and a secondary IP both on the same subnet. | ||
| + | * 07:09 abalashov: mhomed doesn' | ||
| + | * 07:09 abalashov: Even if the appropriate constraints are set in the routing table. | ||
| + | * 07:10 eschmidbauer: | ||
| + | * 07:10 abalashov: Or, let me rephrase that. | ||
| + | * 07:10 abalashov: Multiple _interfaces_ with IPs on the same subnet. | ||
| + | * 07:10 abalashov: As sometimes happens in complex topologies. | ||
| + | * 07:10 miconda: eschmidbauer: | ||
| + | * 07:11 eschmidbauer: | ||
| + | * 07:11 abalashov: The interface detection algorithm should set the source IP to each of the registered listener addresses. Otherwise you could potentially get a completely different address on one of those interfaces in the utility function that figures out the interface to use. | ||
| + | * 07:11 miconda: abalashov: afaik, mhomed triggers creation of tmp sockets to see if the kernel complains for routing | ||
| + | * 07:11 qxork: abalashov: even with setting a $fs or similar? | ||
| + | * 07:11 abalashov: qxork: No, the intent here is to avoid explicit steering with $fs as it would be too labourious. | ||
| + | * 07:12 qxork: abalashov: understood | ||
| + | * 07:12 abalashov: miconda: So, in other words, if you try to route to $SOME_REMOTE_SUBNET that's not directly connected in the local routing table, Kamailio gets confused because that remote subnet is not in the listener list. | ||
| + | * 07:12 miconda: abalashov: but this will require a more detailed description of the interfaces setup, what happens and what should happen | ||
| + | * 07:12 abalashov: Even though the local system' | ||
| + | * 07:13 abalashov: Okay, I'll take it to the lists later with a more detailed description. | ||
| + | * 07:13 miconda: abalashov: ok, I think it requires code investigation, | ||
| + | * 07:13 abalashov: Okay. | ||
| + | * 07:13 abalashov: Sorry, I figured it might be a bit too esoteric for this meeting. | ||
| + | * 07:14 miconda: we tried ;-) | ||
| + | * 07:14 miconda: something else - anyone?!? | ||
| + | * 07:15 abalashov: qxork: Imagine a system with like 5 IPs on 3 interfaces. You don't want to guide everything with $fs there. | ||
| + | * 07:15 qxork: just good feedback =) | ||
| + | * 07:15 miconda: next will be (again) if anyone here has interest in becoming maintainer of (or helping with) rpm packaging | ||
| + | * 07:15 qxork: abalashov: understood completely and looking forward to following this | ||
| + | * 07:15 abalashov: qxork: The desire would be to have Kamailio just do the right thing magically, assisted by the local routing table' | ||
| + | * 07:15 miconda: there was a pull requiest recently on updating the rpm specs for centos | ||
| + | * 07:15 abalashov: qxork: Becomes important in a lot of weird " | ||
| + | * 07:15 miconda: so I guess people use rpms | ||
| + | * 07:16 abalashov: miconda: They do, even though they really shouldn' | ||
| + | * 07:16 miconda: I package them, but don’t use, so it might not be the best outcome (e.g., hard to see if something get’s broken) | ||
| + | * 07:17 miconda: and to finish with the admin part — anyone wanting something new to be used for collaboration within the project | ||
| + | * 07:18 miconda: or we are fine with the mailing lists and irc channel, plus the github.com tools for bugs and pull requests ... | ||
| + | * 07:18 abalashov: To my own surprise, Github has proven fairly adequate for this, at least in my eyes. | ||
| + | * 07:18 abalashov: If nothing else, the integration with the repo and the rest of the workflow is valuable. | ||
| + | * 07:18 abalashov: cresl1n: Privet! | ||
| + | * 07:18 iZverg: I had same schema: Asteridk registered on K. Call came on K. with "To: NUMBER@KAMAILIOIP" | ||
| + | * 07:18 qxork: seen a lot more recent activity on irc... | ||
| + | * 07:18 miconda: abalashov: indeed, at least handling contributions is easier | ||
| + | * 07:18 cresl1n: abalashov: You're on IRC! | ||
| + | * 07:19 cresl1n: Dobroye utro :-) | ||
| + | * 07:19 carstenbock: | ||
| + | * 07:19 abalashov: iZverg: That can be accomplished with the uac module' | ||
| + | * 07:19 miconda: qxork: good to hear that, I was a lot of time traveling in the past months, so not much active on irc | ||
| + | * 07:19 abalashov: iZverg: But it works well. | ||
| + | * 07:20 carstenbock: | ||
| + | * 07:20 miconda: carstenbock: | ||
| + | * 07:21 carstenbock: | ||
| + | * 07:21 iZverg: abalashov: ok, thank you. I don't know why, but A. regged on K. has ugly context in rare cases... | ||
| + | * 07:21 abalashov: miconda: I agree, there' | ||
| + | * 07:21 miconda: ok, if no new suggestion for project collaboration, | ||
| + | * 07:21 abalashov: miconda: I am certainly | ||
| + | * 07:22 miconda: abalashov: :-) | ||
| + | * 07:22 miconda: abalashov: I thought there were no issues to report, not lack of knowing where :-) | ||
| + | * 07:22 abalashov: :D | ||
| + | * 07:23 miconda: ok then — kamailio 5.0 | ||
| + | * 07:23 miconda: first — some update from my side | ||
| + | * 07:23 abalashov: Live config reloading is of course a hot topic, and I understand the complexities of reloading the native route script given how deeply its actions and state are seeded in runtime. | ||
| + | * 07:23 abalashov: But I wonder if perhaps there is some means of " | ||
| + | * 07:23 miconda: kemi framework is implemented for lua and python | ||
| + | * 07:24 abalashov: Making it " | ||
| + | * 07:24 abalashov: Or maybe that would require rewriting Kamailio. :-) | ||
| + | * 07:24 qxork: I'm torn on reload (live reload) | ||
| + | * 07:24 miconda: for those not familiar - kemi is the framework that allows writing routing logic in different scripting languages | ||
| + | * 07:25 miconda: now supported for native kamailio.cfg, | ||
| + | * 07:25 abalashov: qxork: It would be genuinely _complicated_. You'd have to figure out what to do with existing open transactions, | ||
| + | * 07:25 qxork: I see the request side... but at the same time, there are many tools/ | ||
| + | * 07:25 miconda: I guess we need also javascript to match today’s world expectations :-) | ||
| + | * 07:25 abalashov: miconda: Oh god. | ||
| + | * 07:25 qxork: My thought would be a better approach to ones config would eliminate most needs of a live reload. | ||
| + | * 07:26 abalashov: qxork: I generally agree, but sometimes it just can't be helped, i.e. things get hard-coded for performance reasons. | ||
| + | * 07:26 abalashov: miconda: The true holy grail would of course be live reloading of native kamailio.cfg in entirety. | ||
| + | * 07:26 abalashov: miconda: But I think you ruled this out in the past. | ||
| + | * 07:26 qxork: abalashov: agreed... which is a design consideration =) | ||
| + | * 07:27 miconda: abalashov: with a certain level of rewriting (maybe 99% of the config interpreter), | ||
| + | * 07:27 abalashov: qxork: Also keep in mind there are very complex kamailio.cfg' | ||
| + | * 07:27 abalashov: miconda: That's a pretty high level of rewriting. ;-) | ||
| + | * 07:27 volga629_: I think kamailio need live console | ||
| + | * 07:27 volga629_: like freeswitch or asterisk | ||
| + | * 07:27 miconda: abalashov: but the thing I see more important is performance of an interpreter with static pre-compilation, | ||
| + | * 07:28 abalashov: volga629_: It kind of has that, in the form of its management/ | ||
| + | * 07:28 qxork: miconda/ | ||
| + | * 07:28 abalashov: miconda: I agree with that strongly. | ||
| + | * 07:28 miconda: because if we lose too much of the performance, | ||
| + | * 07:28 abalashov: miconda: And that necessarily requires stuff deeply embedded into runtime. | ||
| + | * 07:28 abalashov: miconda: Stuff that can't be easily reloaded like that. | ||
| + | * 07:29 miconda: maybe in the future, we can write a second kamailio.cfg interpreter, | ||
| + | * 07:29 abalashov: Yep -- the native config script exists because it's the fastest approach, it simply beats any other config approach. | ||
| + | * 07:29 abalashov: And that is a value-add that should stay. | ||
| + | * 07:29 qxork: agree strongly | ||
| + | * 07:30 miconda: at the end, if we look only at routing blocks, we need to work around the fixup of the parameters | ||
| + | * 07:30 abalashov: miconda: I just wanted to hear you say it would take 99% rewrite. :) | ||
| + | * 07:30 abalashov: Yeah, there' | ||
| + | * 07:30 miconda: abalashov: that’s about the config interpreter, | ||
| + | * 07:30 abalashov: There' | ||
| + | * 07:30 abalashov: miconda: Yeah, I know. | ||
| + | * 07:31 abalashov: That's what I meant. | ||
| + | * 07:31 miconda: abalashov: it will be more of taking each config function and be sure it can deal ok with doing fixups at runtime | ||
| + | * 07:31 osas: another option would be to have the ability to reload a route (when a small change is done inside an existing route) | ||
| + | * 07:31 abalashov: osas: But calls to e.g. module functions have fixups there too. | ||
| + | * 07:32 qxork: Well, if they switch to using lua lets say... this eliminates a lot of need for the reload, no? | ||
| + | * 07:32 abalashov: qxork: As long as they' | ||
| + | * 07:32 miconda: qxork: you can do reload of lua script that has the routing blocks | ||
| + | * 07:32 qxork: abalashov: and eating | ||
| + | * 07:32 miconda: useful links: https:// | ||
| + | * 07:33 osas: abalashov: yes, but probably does not require a new cfg interpreter | ||
| + | * 07:33 volga629_: console will give ability reload separate module and with it configuration or reload all. Also you can control visually what is go in on when reload in progress | ||
| + | * 07:33 iZverg: K. 5.x still has unfixed CPU issues on FreeBSD... | ||
| + | * 07:33 abalashov: volga629_: Well, a console cannot provide functionality that isn't otherwise there simply because it is a console. :-) A "live console" | ||
| + | * 07:33 miconda: kemi: https:// | ||
| + | * 07:34 qxork: I can see some fun performance testing of taking existing configs and testing as .cfg, lua, python, etc. | ||
| + | * 07:34 abalashov: miconda: Has any pictre emerged of what a continuous integration pipeline might look like? | ||
| + | * 07:35 abalashov: qxork: Well, if fun is what you call that ... | ||
| + | * 07:35 miconda: abalashov: lua is calling kamailo functions directly (no complex layer in between) | ||
| + | * 07:35 miconda: the only difference is on parameter evaluation | ||
| + | * 07:35 abalashov: Ahh. | ||
| + | * 07:35 abalashov: That's good to know. | ||
| + | * 07:35 miconda: in kamailio.cfg is done through the fixup system | ||
| + | * 07:35 abalashov: So perhaps Lua config is not as slow as I imagine it. | ||
| + | * 07:35 miconda: in lua.cfg is done by lua operations | ||
| + | * 07:35 abalashov: My mental picture was somewhere on par with app_perl. | ||
| + | * 07:35 qxork: abalashov: it's taken me years to appreciate lua | ||
| + | * 07:35 miconda: but in both cases a parameter reslves to an integer or a string | ||
| + | * 07:36 miconda: and calls the base function in c | ||
| + | * 07:36 miconda: so for kamailio.cfg interpreter we have wrapper functions that evaluate the parameters from fixup form to these int or string values | ||
| + | * 07:36 abalashov: miconda: If that's the case, then why is it easier to reload? | ||
| + | * 07:37 miconda: because lua doesn’t pre-compiles parameters in pkg | ||
| + | * 07:37 abalashov: miconda: Just because the execution is still a call out to a reloadable Lua codebase in the end, not " | ||
| + | * 07:37 abalashov: Ah, so it's all got to do with the fact that the parameters are all left floating/ | ||
| + | * 07:38 miconda: abalashov: more or less yes | ||
| + | * 07:38 abalashov: But how is the handling of existing in-flight transactions and dialogs and other state accomplished? | ||
| + | * 07:38 miconda: abalashov: writing a new interpreter might be easier that just making the old one in dual mode | ||
| + | * 07:38 miconda: the code can be even simpler | ||
| + | * 07:38 miconda: I mean a new interpreter for kamailio.cfg with reload capability | ||
| + | * 07:39 miconda: abalashov: it will have to do lookup at the moment it needs to execute the routing block | ||
| + | * 07:39 abalashov: So what happens if I have a message that's in the middle of winding its way through a worker at the time the reload is issued? | ||
| + | * 07:39 miconda: for example: right now we resolve a failure_route[xyz] to its pointer in memroy | ||
| + | * 07:39 abalashov: Or am waiting on an fr_timer and a pending failure_route? | ||
| + | * 07:40 miconda: for lua (via key), we keep the name of the function to be executed | ||
| + | * 07:40 abalashov: Ahhh. | ||
| + | * 07:40 miconda: that can be done also with a c interpreter | ||
| + | * 07:40 abalashov: Well, you'd still have to deal with the target function simply going away. | ||
| + | * 07:40 miconda: but don’t optimize at startup | ||
| + | * 07:40 abalashov: And things like that. | ||
| + | * 07:40 miconda: that’s ok, even now it works if the failure route block is not found | ||
| + | * 07:41 miconda: but I think we have some check at startup | ||
| + | * 07:41 abalashov: You do. | ||
| + | * 07:41 abalashov: I can't get Kamailio to start with a nonexistent failure_route armed. | ||
| + | * 07:41 abalashov: So I assumed that was quite ' | ||
| + | * 07:41 miconda: but we can print a log message at runtime if the routing block is not found by interpreter | ||
| + | * 07:42 hughw: Hello. | ||
| + | * 07:42 miconda: we ca still check when we parse the config file, so we can (always) do some optimizations | ||
| + | * 07:42 abalashov: miconda: So what is the prospectus for a new native cfg interpreter that works on the principle of keying functions and other referents by key rather than by memory address? | ||
| + | * 07:42 miconda: like keeping versions of the config file and along he name keep the version and a pointer in memory to the routing block, then when executing, if the version is the same, run directly, otherwise, lookup again | ||
| + | * 07:42 abalashov: miconda: Is it something you might be willing to do for 5.0? | ||
| + | * 07:43 hughw: If we are upgrading individual routing blocks at runtime, do we need to keep the old version of the block until all references to it (transactions) have gone | ||
| + | * 07:43 miconda: still extra checks will be done, so it will not be same kind of complexity at runtime like with old interpreter | ||
| + | * 07:43 abalashov: hughw: That could get complicated quickly. | ||
| + | * 07:43 abalashov: hughw: Endless reference counts for an increasingly large number of entities... | ||
| + | * 07:43 hughw: e.g. is someone sets t_on_failure(MY_ROUTE) and then the route is changed before the reply comes back | ||
| + | * 07:43 miconda: hughw: the current approach with lua configs (via kemi) is to keep names instead of pointers, with lookup at runtime | ||
| + | * 07:44 abalashov: hughw: What do you do with things like event_route[xhttp: | ||
| + | * 07:44 abalashov: Version and refcount absolutely everything? | ||
| + | * 07:44 abalashov: What if xhttp module is unloaded and this event_route is no longer provided? :) | ||
| + | * 07:44 miconda: hughw: actually in the lua, there is no failure_route concept, but providing a callback function name to be executed | ||
| + | * 07:44 hughw: True | ||
| + | * 07:44 miconda: abalashov: reloading the modules will make it a lot more complex | ||
| + | * 07:45 abalashov: I mean if it's simply not loaded in the new config. | ||
| + | * 07:45 abalashov: But we have referents going to custom routes provided by modules. | ||
| + | * 07:45 miconda: we are targeting reloading the runtime active parts — the routing blocks | ||
| + | * 07:45 miconda: because for modules, they create connections to backends, load data at startup, etc … | ||
| + | * 07:45 abalashov: Sounds like a real mess. Hard to reason about. Maybe easier for you -- if so, that is very fortunate ... | ||
| + | * 07:45 miconda: this may be ng-ng-ng version | ||
| + | * 07:46 miconda: so to summarize ... | ||
| + | * 07:46 abalashov: Well, the other thing you have to consider is, if the approach to reloading taken is to drop lots of state altogether, then at some point you have to ask what is the benefit of live reloading versus restarting. | ||
| + | * 07:46 abalashov: In other words, what is " | ||
| + | * 07:46 miconda: getting an interpreter that can reload routing blocks might not be that complex, but it requires a lot of walk through the exiting functions and adapt them to work in both modes | ||
| + | * 07:47 miconda: changing the current interpreter might not be the easiet option, so writing an alternative can be better | ||
| + | * 07:47 abalashov: miconda: What is your level of eagerness to write such a new alternative on a scale of 1 to very eager? | ||
| + | * 07:47 miconda: but I don’t expect to add much more performance than a lua interpreter, | ||
| + | * 07:48 qxork: I'd love to see this put off to Kamailio 6 | ||
| + | * 07:48 miconda: abalashov: probably I can get one as core framework, but I don’t want to walk all the kamailio mdules to be sure the functions are safe to be used there | ||
| + | * 07:48 abalashov: qxork: KamailioWorks R13 you mean? | ||
| + | * 07:49 qxork: ;) | ||
| + | * 07:49 miconda: we have the fixup + fixeup_free functions, they are used by python/lua (oldstyle, not via kemi) | ||
| + | * 07:49 abalashov: miconda: I'd say let's shelve that idea for KamailioWorks R13 then. | ||
| + | * 07:49 abalashov: Not everything that can be done is worth doing just because it can be done. We're not OpenSIPS. | ||
| + | * 07:50 miconda: for example: app_python can call any module function doing fixup before execution, then free fixup after return | ||
| + | * 07:50 qxork: I truly believe that what we have is great in terms of performance / function | ||
| + | * 07:50 miconda: but I expect some of the functions don’t have the free fixup | ||
| + | * 07:50 abalashov: qxork: You mean to say ... we've Made Kamailio Great Again? | ||
| + | * 07:50 qxork: some changes must require either a loss of a call or a maintenance window | ||
| + | * 07:50 miconda: as a matter of fact, right now there is insignificant difference between lua (kemi) and native interpreters | ||
| + | * 07:50 carstenbock: | ||
| + | * 07:51 qxork: We're going to build a great big reload. Beautiful. | ||
| + | * 07:51 qxork: It's going to be huuuuge. | ||
| + | * 07:51 miconda: as i said, what they do different is how they build the int/string parameter values | ||
| + | * 07:51 miconda: the execution of the base c functions is done the same | ||
| + | * 07:52 abalashov: qxork: Can we get Oracle to pay for it? | ||
| + | * 07:52 miconda: the lokup of failure/ | ||
| + | * 07:52 miconda: because typically a kamailiocfg has only few of them | ||
| + | * 07:52 abalashov: nods | ||
| + | * 07:52 miconda: say 5-10 failure route blocks | ||
| + | * 07:52 abalashov: That's way more failure_route blocks than I ever had. | ||
| + | * 07:53 miconda: abalashov: it’s not about route blocks, but failure route … do you have lot more? | ||
| + | * 07:53 miconda: they are anyhow indexed by hash id (iirc) | ||
| + | * 07:53 miconda: some of the modules even do runtime lookup for event_routes … | ||
| + | * 07:54 miconda: anyhow, let’s get to a conclusion here | ||
| + | * 07:54 abalashov: New interpreter not needed at this time. | ||
| + | * 07:54 abalashov: But intriguing discussion and worth keeping in mind for future. | ||
| + | * 07:54 abalashov: That would be my interpretation. | ||
| + | * 07:54 qxork: agreed. new interpreter not needed at this time. | ||
| + | * 07:54 miconda: my approach is to have lua and python on pair if the most of available config functions (I mean most relevant modules) | ||
| + | * 07:55 abalashov: nods | ||
| + | * 07:55 miconda: because then it will be easier to write a kemi interpreter in c | ||
| + | * 07:55 abalashov: If someone really values reloadability that much ... use kemi. | ||
| + | * 07:55 qxork: thumbs up | ||
| + | * 07:55 abalashov: OH. I just remembered something ... this may not be the right part of the discussion for it ... | ||
| + | * 07:55 abalashov: But I was very surprised to discover recently that I can't drop replies in transaction-affiliated (TM) onreply_routes. | ||
| + | * 07:56 abalashov: Only in the global onreply_route. | ||
| + | * 07:56 abalashov: But I don't want to drop all replies, only some. | ||
| + | * 07:56 abalashov: This has led to the need for a complex and somewhat imperfect htable-based statekeeping mechanism to know for which Call-IDs to drop which replies. | ||
| + | * 07:56 miconda: other benefits I see when using lua/ | ||
| + | * 07:56 abalashov: Any chance this can be addressed? | ||
| + | * 07:57 miconda: abalashov: open an issue on tracker to discuss it | ||
| + | * 07:57 miconda: afaik is only the 2xx that cannot be dropped | ||
| + | * 07:57 abalashov: Okay. The reason I brought it up here is I wondered if there is some technical obstacle. | ||
| + | * 07:57 abalashov: Yes, that's right. But it is precisely 2xx replies I need to drop. :/ (It pertains to transactions for which I've already sent 2xx replies from Kam, and then suspended to wake up later...) | ||
| + | * 07:57 miconda: it’s open source, if someting is not there, then a PR was not received :-) | ||
| + | * 07:58 miconda: I am sure it can be addressed | ||
| + | * 07:58 abalashov: So is there some technical reason why 2xx replies cannot be dropped that goes deeper than if(reply_code >= 200 && reply_code <= 299) { disallow drop for arbitrary reasons }? | ||
| + | * 07:58 abalashov: That was the real question. | ||
| + | * 07:58 miconda: eventuall with another event route pre-transaction status update | ||
| + | * 07:59 abalashov: Ah, but I want the received 2xx reply to close out the transaction. I just don't want to send it back to the UAC. | ||
| + | * 07:59 miconda: the thing to see is where the onreply route is executed | ||
| + | * 07:59 miconda: if it’s executed before updating the state of transaction, | ||
| + | * 07:59 miconda: but maybe right now is after | ||
| + | * 08:00 miconda: 3xx+ codes are easy to drop, becaue we drop anyhow some of them in case of serial/ | ||
| + | * 08:00 abalashov: I would want the 2xx reply received from UAS to affect transaction state, but just suppress its forwarding to the UAC. | ||
| + | * 08:01 abalashov: If there were something like an onsend_route or something low-level where I can just block it before it goes out on the transport level... | ||
| + | * 08:01 miconda: abalashov: isn’t that working with onsend_route for replies? | ||
| + | * 08:01 abalashov: miconda: Can I drop stuff there? And aren't those global, not transaction-associated? | ||
| + | * 08:01 miconda: I think I told you about | ||
| + | * 08:01 abalashov: That may be, and the fault may entirely be mine. | ||
| + | * 08:01 miconda: they are global | ||
| + | * 08:01 miconda: but you can still check avps/flags there | ||
| + | * 08:01 miconda: which are per transactions | ||
| + | * 08:02 hughw: In the cfg, there is a check to ensure you are allowed to call certain functions in the route type. Or the function behaves differently (internally) depending on which route it was called from. | ||
| + | * 08:02 hughw: Does the same check work when calling functions from LUA? | ||
| + | * 08:02 abalashov: iZverg: How would I check transaction-affiliated flags or AVPs there if the onsend routes for replies are not transaction-bound? | ||
| + | * 08:02 abalashov: Sorry, miconda: How would I check transaction-affiliated flags or AVPs there if the onsend routes for replies are not transaction-bound? | ||
| + | * 08:03 miconda: hughw: afaik, before executing a failure_route, | ||
| + | * 08:03 miconda: this hasn’t changed | ||
| + | * 08:03 miconda: instead of executing the native failure_route, | ||
| + | * 08:03 miconda: but setting the routing block type is done before, not changed | ||
| + | * 08:04 miconda: abalashov: it’s still in the context of that sip message | ||
| + | * 08:04 abalashov: miconda: OH | ||
| + | * 08:04 abalashov: miconda: It seems I misunderstood this. | ||
| + | * 08:04 hughw: (I've been away from kamailio development for a bit - probably should do some revision) | ||
| + | * 08:04 miconda: onsend_route is executed inside t_relay() | ||
| + | * 08:04 abalashov: miconda: That may be an elegant and simple solution to the problem then, will test. | ||
| + | * 08:04 abalashov: miconda: Oh! I thought it was global similarly to onreply_route global. | ||
| + | * 08:05 miconda: hughw: you are very welcome back! I expect you will like the kemi approach, afaik, you use a lot of lua with kamailio.cfg | ||
| + | * 08:07 qxork: what's next? | ||
| + | * 08:08 miconda: next will be restructuring the location of the code | ||
| + | * 08:08 miconda: I think we decided that | ||
| + | * 08:08 miconda: the question is if anyone knows any too/script that can help with that | ||
| + | * 08:08 miconda: we will aim at: | ||
| + | * 08:08 miconda: src/ | ||
| + | * 08:08 miconda: src/core/ | ||
| + | * 08:08 abalashov: startledmarmot: | ||
| + | * 08:08 miconda: src/ | ||
| + | * 08:08 miconda: src/libs/ | ||
| + | * 08:09 miconda: the root folder should have the docs/, maybe etc/ and test/ | ||
| + | * 08:09 miconda: plus a single master Makefile | ||
| + | * 08:09 abalashov: miconda: Would it be asinine to suggest Bash as a tool for this endeavour? :-D | ||
| + | * 08:09 miconda: all the other makefiles moved to src/ | ||
| + | * 08:10 qxork: I think I was supposed to look at a perl script for this and dropped the ball | ||
| + | * 08:10 miconda: also in root folder have the main README and INSTALL … | ||
| + | * 08:10 miconda: so the root folder looks a bit cleaner | ||
| + | * 08:11 miconda: also, we will get all core related components in a place where is easy to spot them (i mean heare the mem, parser, … folders — they will be moved in the src/core/) | ||
| + | * 08:11 miconda: abalashov: waiting for that bash script now :-) | ||
| + | * 08:12 hughw: don't forget /pkg for the RPM spec files | ||
| + | * 08:12 miconda: well, I guess one can do it with perl. sed. awk, etc … I was more looking to see if anyone is aware of an existing tool | ||
| + | * 08:13 miconda: where one ca say: file x.h moved from . to src/core/ — update all the exiting includes :-) | ||
| + | * 08:13 miconda: hughw: sure, there are several folders to be still kept there | ||
| + | * 08:14 miconda: so no one knows such tool, we will have to write one | ||
| + | * 08:14 miconda: or use vim+keyboard | ||
| + | * 08:14 miconda: next topic | ||
| + | * 08:14 abalashov: nods | ||
| + | * 08:14 abalashov: That follows well-understood UNIX src project structure. | ||
| + | * 08:14 abalashov: Do module docs stay in the modules' | ||
| + | * 08:14 abalashov: Or go in docs/ ? | ||
| + | * 08:15 miconda: abalashov: docs for modules will stay in the same folder, like now | ||
| + | * 08:15 startledmarmot: | ||
| + | * 08:16 miconda: back to next topic | ||
| + | * 08:16 miconda: anyone knowing a document format (markup language) for defining function prototypes | ||
| + | * 08:17 miconda: it may be useful to use one to be able to get the list of exported functions | ||
| + | * 08:17 miconda: not thinking only of kemi functions as I emailed a while ago, but this can be useful for rpc commands as well | ||
| + | * 08:18 abalashov: You mean something that can analyse code and retrieve a list of all function prototypes, despite complex multiline formatting and so on? | ||
| + | * 08:18 miconda: as osas noticed, rpc commands are not well indexed and documented | ||
| + | * 08:18 miconda: abalashov: more the other way around | ||
| + | * 08:18 miconda: have a spec file and then generate c code to be included by module | ||
| + | * 08:18 abalashov: Ahh. Like stubs. | ||
| + | * 08:18 abalashov: Can't generate implementations obviously. ;) | ||
| + | * 08:19 miconda: abalashov: what you say it’s done for extracting rpc commands | ||
| + | * 08:19 miconda: but requires some patches to a perl module plus a specific compiler mode | ||
| + | * 08:19 qxork: brb | ||
| + | * 08:19 miconda: abalashov: yep, like stubs | ||
| + | * 08:19 abalashov: So you're looking for something that can generate rpc functions consistently for all modules ... do these functions have a body of some kind, or just empty stubs? | ||
| + | * 08:19 miconda: abalashov: or only the prototypes | ||
| + | * 08:20 miconda: abalashov: only function prototypes and interface structures | ||
| + | * 08:20 miconda: I don’t want to go that far in defininf function stubs | ||
| + | * 08:21 abalashov: Ah. | ||
| + | * 08:21 carstenbock: | ||
| + | * 08:21 osas: maybe a custom awk script? | ||
| + | * 08:21 miconda: something that I can use to generate c code with the ptototypes and the interface structures, as well as documentation index | ||
| + | * 08:21 abalashov: But what's the use in a prototype if the functions are not implemented? | ||
| + | * 08:21 miconda: I don’t see it as a replacement for existing docs | ||
| + | * 08:22 miconda: but something that can be easily checked to see if a function is not documented | ||
| + | * 08:22 carstenbock: | ||
| + | * 08:22 abalashov: Ahhh. | ||
| + | * 08:22 miconda: carstenbock: | ||
| + | * 08:22 osas: I would say we should use it to generate both prototypes and xml docs | ||
| + | * 08:23 abalashov: So it does pull stuff out of existing code. The idea is to discover RPC functions which exist and display them in some format? | ||
| + | * 08:23 miconda: osas: maybe parts of xml docs | ||
| + | * 08:23 miconda: but I don’t want to have examples there | ||
| + | * 08:23 osas: miconda: yes :) | ||
| + | * 08:23 osas: only the RPC part | ||
| + | * 08:23 abalashov: I find system.listMethods to be pretty insightful. Most stuff is fairly obvious. But yes, in cases where parameters are required, not always. | ||
| + | * 08:24 eschmidbauer: | ||
| + | * 08:24 miconda: abalashov: let me give some example | ||
| + | * 08:24 miconda: when adding a new function, instead of writing c code to define it’s prototype and add it to the module exports structure | ||
| + | * 08:24 abalashov: miconda: Please. :-) It seems I am a bit confused about the direction of the analysis. | ||
| + | * 08:24 miconda: just write in a spec file | ||
| + | * 08:25 osas: and add the actual code for it :) | ||
| + | * 08:25 miconda: run a tool on that spec file that will re-generate a .h file and a .c file | ||
| + | * 08:25 eschmidbauer: | ||
| + | * 08:25 abalashov: So where does the actual code for it come from? ") | ||
| + | * 08:25 abalashov: Is that in the spec file too, or is that up for you to write between the curly braces of the stubs? | ||
| + | * 08:25 miconda: it will be generated by the tool | ||
| + | * 08:26 miconda: the implementation will be in another c file | ||
| + | * 08:26 abalashov: Is that based on the theory that most RPC operations are really simple? | ||
| + | * 08:26 abalashov: Oh. | ||
| + | * 08:26 miconda: so the module exports will include the h file and only the generated structure | ||
| + | * 08:26 miconda: implementation will be in another c file | ||
| + | * 08:26 miconda: all linked at compile time | ||
| + | * 08:26 abalashov: But to be clear, the implementation is still up to you to write... you're not talking about partly generating implementations of any kind, just signatures? | ||
| + | * 08:26 miconda: so the mod exports c file will be only with exported structures | ||
| + | * 08:27 miconda: abalashov: yes | ||
| + | * 08:27 abalashov: cresl1n: Know of anything like this? | ||
| + | * 08:27 abalashov: mjordan: Or you? | ||
| + | * 08:27 osas: while generating the .h files, we should generate the includes in the xml doc file too | ||
| + | * 08:28 miconda: iirc, Henning Westerholt proposed something like that in the past | ||
| + | * 08:28 miconda: osas: right | ||
| + | * 08:28 abalashov: miconda: If nobody has any suggestions, | ||
| + | * 08:28 abalashov: miconda: j2cli just provides a CLI wrapper for it. | ||
| + | * 08:29 osas: BTW, when are we going to drop the mi interface? | ||
| + | * 08:29 miconda: abalashov: ok, I will look into it | ||
| + | * 08:29 abalashov: miconda: " | ||
| + | * 08:29 miconda: I wanted to get some leads | ||
| + | * 08:29 miconda: abalashov: it will be used only by devs, I think that’s ok | ||
| + | * 08:29 abalashov: https:// | ||
| + | * 08:29 abalashov: I've been very happy with it. | ||
| + | * 08:29 abalashov: I got into Jinja because of SaltStack. | ||
| + | * 08:30 abalashov: It's just very easy ... {% for f in rpcFuncs %}dothings{% endfor %} | ||
| + | * 08:30 abalashov: YAML - | ||
| + | * 08:30 abalashov: rpcFuncs: | ||
| + | * 08:30 abalashov: | ||
| + | * 08:30 abalashov: | ||
| + | * 08:30 abalashov: | ||
| + | * 08:30 abalashov: You get the idea. | ||
| + | * 08:30 miconda: yep | ||
| + | * 08:30 miconda: ok, we have a lead | ||
| + | * 08:31 abalashov: Just really simple if you don't want to learn something complicated and esoteric. | ||
| + | * 08:31 abalashov: It's become my favourite templating tool because of its simplicity. | ||
| + | * 08:31 abalashov: It's like the opposite of m4. | ||
| + | * 08:31 miconda: and people got the idea, so they can email if they have new suggestions | ||
| + | * 08:31 abalashov: osas: Never! | ||
| + | * 08:32 miconda: abalashov osas :-) | ||
| + | * 08:32 miconda: regarding the mi, the main concer is getting kamctl on pair when using rpc | ||
| + | * 08:32 mjordan: abalashov: apologies, trying to catch up. What opinion were you soliciting? :-) | ||
| + | * 08:32 miconda: we have kamctl, maybe that’s a way to push further | ||
| + | * 08:33 abalashov: mjordan: Opinion on a tool that can take list of functions from a spec file --> generate function signatures/ | ||
| + | * 08:33 mjordan: we use jinga2 templates | ||
| + | * 08:33 abalashov: mjordan: jinja2 you mean? | ||
| + | * 08:34 abalashov: mjordan: By coincidence, | ||
| + | * 08:34 mjordan: Ah, I'm actually wrong - we used that elsewhere. For ARI, we use Swagger for the specification, | ||
| + | * 08:34 miconda: otherwise I am using more rpc because of better structured format, so not much tied to old mi | ||
| + | * 08:34 abalashov: mjordan: https:// | ||
| + | * 08:34 abalashov: miconda: I've switched to rpc entirely. | ||
| + | * 08:35 mjordan: Really, though, something like mustache or jinja should be sufficient. We generate some relatively complex binding files from the HTTP server to the ARI logic | ||
| + | * 08:35 abalashov: Any particular reason you didn't go with Jinja but instead what sounds like a house-brand Python script? | ||
| + | * 08:35 miconda: mjordan: thanks, I will check those as well | ||
| + | * 08:36 mjordan: example of a generated file: http:// | ||
| + | * 08:37 mjordan: abalashov: yeah, we use j2cli to manipulate configuration files in Docker containers. Long story :-) | ||
| + | * 08:37 abalashov: mjordan: The world is small. | ||
| + | * 08:37 qxork: was hoping to go another 10 min before hearing about docker ;) | ||
| + | * 08:37 abalashov: mjordan: I didn't think anyone else thought jinja2 was cool. | ||
| + | * 08:37 mjordan: abalashov: does this mean we're both hip now? | ||
| + | * 08:38 abalashov: qxork: Docker is dead, long live RKT. | ||
| + | * 08:38 abalashov: mjordan: Oh no, you actually _use_ Docker ... you're much more hip. | ||
| + | * 08:38 qxork: abalashov: oh my testing as fun is not cool, but your jinja2 is ... I see how you are. =) | ||
| + | * 08:38 abalashov: Testing is fun when it's miconda' | ||
| + | * 08:39 abalashov: (for off-topic blather) | ||
| + | * 08:39 qxork: smiles loudly | ||
| + | * 08:39 miconda: abalashov: I only test (I cannot afford to have another server to run production) | ||
| + | * 08:39 miconda: :-) | ||
| + | * 08:40 miconda: so … let’s move to the last topic | ||
| + | * 08:40 qxork: production is just another form of testing | ||
| + | * 08:40 scv: lol | ||
| + | * 08:40 miconda: roadmap to 5.0 | ||
| + | * 08:40 abalashov: qxork: Glad someone else agrees. | ||
| + | * 08:41 miconda: I was thinking of freezing just before Christmas holidays | ||
| + | * 08:41 miconda: or sometime in January | ||
| + | * 08:41 miconda: a matter of how code restructuring goes on | ||
| + | * 08:41 miconda: because I want to do it just before freezing | ||
| + | * 08:41 miconda: to have fixes still backported in an easy way | ||
| + | * 08:42 miconda: afterwards I will expect conflicts and not that easy to backport | ||
| + | * 08:42 miconda: after freezing, go with the ususal 1-1.5 months of testing | ||
| + | * 08:42 miconda: and release | ||
| + | * 08:42 miconda: not sure if we will make it with 5.0 in the next debian stable | ||
| + | * 08:43 qxork: with git, we make all distros | ||
| + | * 08:43 abalashov: qxork: +1 | ||
| + | * 08:43 miconda: maybe linuxmaniac can shed more light when debian freezes the acceptance of new versions of packages | ||
| + | * 08:43 abalashov: miconda: That also implies that a next major .0 release of something is stable. ;) | ||
| + | * 08:44 miconda: abalashov: besides relocating the code, won’t be any major changes | ||
| + | * 08:44 abalashov: Sorry, it's a lot easier to make funny jokes than to submit PRs. | ||
| + | * 08:44 miconda: the kemi framework proved to be really not intrusive | ||
| + | * 08:45 miconda: abalashov: I like to hear more jokes than seeing new issues opened on the tracker :-) | ||
| + | * 08:45 linuxmaniac: | ||
| + | * 08:45 linuxmaniac: | ||
| + | * 08:46 miconda: so all this restructureing for 5.0 will be more like labor work, than rocket science | ||
| + | * 08:46 miconda: linuxmaniac: | ||
| + | * 08:47 miconda: and get 5.0.0 as it gets out, through the usual patch update? | ||
| + | * 08:48 linuxmaniac: | ||
| + | * 08:48 linuxmaniac: | ||
| + | * 08:48 linuxmaniac: | ||
| + | * 08:48 miconda: linuxmaniac: | ||
| + | * 08:49 linuxmaniac: | ||
| + | * 08:49 linuxmaniac: | ||
| + | * 08:50 linuxmaniac: | ||
| + | * 08:50 miconda: linuxmaniac: | ||
| + | * 08:50 linuxmaniac: | ||
| + | * 08:50 miconda: linuxmaniac: | ||
| + | * 08:51 abalashov: Unfortunately I've got to run ... | ||
| + | * 08:51 linuxmaniac: | ||
| + | * 08:51 miconda: I haven’t seen oej around, but I guess that idea of a face to face meeting was dropped | ||
| + | * 08:51 qxork: abalashov: always a joy to see you | ||
| + | * 08:51 abalashov: linuxmaniac: | ||
| + | * 08:51 miconda: abalashov: thanks, very useful input this time :-) | ||
| + | * 08:51 qxork: miconda: this time. ;) | ||
| + | * 08:51 linuxmaniac: | ||
| + | * 08:52 abalashov: :D | ||
| + | * 08:52 miconda: :-) | ||
| + | * 08:52 abalashov: Now I'm in pain ... have to recover. It hurts so much to give useful input. | ||
| + | * 08:52 abalashov: I'll see you next week | ||
| + | * 08:52 linuxmaniac: | ||
| + | * 08:52 miconda: I think I run though all my main topics | ||
| + | * 08:53 miconda: if anyone has anything else to discuss … you are welcome to step forward | ||
| + | * 08:53 qxork: what additional assistance do you need? | ||
| + | * 08:54 qxork: aka... how else can we help? | ||
| + | * 08:54 miconda: qxork: two more hands won’t be bad :-) | ||
| + | * 08:54 miconda: and a brain :-) | ||
| + | * 08:55 linuxmaniac: | ||
| + | * 08:55 qxork: =) | ||
| + | * 08:55 miconda: linuxmaniac: | ||
| + | * 08:55 linuxmaniac: | ||
| + | * 08:56 miconda: hopefully people will get involved in helping with relocation of code files | ||
| + | * 08:56 miconda: that would be very helpful | ||
| + | * 08:56 miconda: should not be anything complicated | ||
| + | * 08:56 linuxmaniac: | ||
| + | * 08:56 miconda: just wrting some scripts, with good regexps around | ||
| + | * 08:57 miconda: linuxmaniac: | ||
| + | * 08:57 miconda: some video conf? | ||
| + | * 08:57 linuxmaniac: | ||
| + | * 08:57 linuxmaniac: | ||
| + | * 08:58 linuxmaniac: | ||
| + | * 08:58 linuxmaniac: | ||
| + | * 08:58 linuxmaniac: | ||
| + | * 08:59 qxork: I can offer a server if you want for the conf, unless you plan on using jitsi meet, hangouts, or something else. | ||
| + | * 09:00 miconda: linuxmaniac: | ||
| + | * 09:00 linuxmaniac: | ||
| + | * 09:01 miconda: qxork: I guess will take us some time to setup the server, probably jitsi meet will do it if needed | ||
| + | * 09:01 miconda: we can use the time for writing the scripts | ||
| + | * 09:01 linuxmaniac: | ||
| + | * 09:01 qxork: miconda: ack. won't drop the ball this time. | ||
| + | * 09:01 cresl1n: abalashov: Sorry about the delay, just got off of a long call. What's up? | ||
| + | * 09:02 qxork: cresl1n: he had to run | ||
| + | * 09:02 cresl1n: ic ic | ||
| + | * 09:03 miconda: cresl1n: I guess mjordan answered what abalashov wanted | ||
| + | * 09:04 miconda: cresl1n: which was about tools used to generate function signatures/ | ||
| + | * 09:04 linuxmaniac: | ||
| + | * 09:04 cresl1n: thanks miconda | ||
| + | * 09:05 cresl1n: are you doing well? | ||
| + | * 09:05 miconda: linuxmaniac: | ||
| + | * 09:05 miconda: cresl1n: all good | ||
| + | * 09:05 linuxmaniac: | ||
| + | * 09:06 linuxmaniac: | ||
| + | * 09:06 miconda: linuxmaniac: | ||
| + | * 09:07 linuxmaniac: | ||
| + | * 09:07 linuxmaniac: | ||
| + | * 09:08 miconda: linuxmaniac: | ||
| + | * 09:08 linuxmaniac: | ||
| + | * 09:08 miconda: ok — last call for new topics, otherwise we can end this session | ||
| + | * 09:09 miconda: it was longer than expected, but with very good outcome to move forward towards 5.0 | ||
| + | * 09:09 miconda: especially for sync’ing — the last summer was rather chaotic for me, a lot of events in the family that I had to attend and required traveling | ||
| + | * 09:10 qxork: excited about the release | ||
| + | * 09:10 qxork: any thoughts on dates for Kamailio World? | ||
| + | * 09:10 linuxmaniac: | ||
| + | * 09:10 miconda: qxork: I hope to have the dates before end of November | ||
| + | * 09:11 miconda: targeting same timeframe, April-May | ||
| + | * 09:11 qxork: =-) | ||
| + | * 09:11 qxork: thank you for the great work! | ||
| + | * 09:11 miconda: I am waiting to see availabitly of the conferencing room | ||
| + | * 09:11 miconda: Fokus has its own one in rennovation | ||
| + | * 09:11 miconda: and they had another conference last week, all being too busy to follow my requests | ||
| + | * 09:12 qxork: Maybe we increase attendance (slightly) and move to Olympiastadion | ||
| + | * 09:12 miconda: :-) | ||
| + | * 09:13 miconda: if not hing available at a convenient time in Berlin, it will be in Germany anyhow | ||
| + | * 09:13 qxork: joran was pushing hard for their locale | ||
| + | * 09:13 qxork: Yeni doesn' | ||
| + | * 09:13 miconda: it’s indeed an option, but I am also constrained by the co-organized | ||
| + | * 09:14 miconda: … co-organizers | ||
| + | * 09:14 miconda: qxork: we will get you to berlin, anyhow | ||
| + | * 09:14 miconda: it’s a must visit place for kamailio :-) | ||
| + | * 09:15 linuxmaniac: | ||
| + | * 09:15 miconda: ok … so the devel meeting session is ended — as a marker for minutes | ||
devel/irc-meetings/2016b.1478538748.txt.gz · Last modified: 2016/11/07 17:12 by miconda