 Yeah, I think this is going to be really quick. It's a really small tool, but I think it's rather useful and I think some wider audience is deserved, but just to make sure who does know what Osmo conflict merge is and what it does. Okay, so that's exactly two people, well, a third one. And I know Nils also knows it, but he's not here, but okay, so it's worth to very quickly look at it. So, what's the problem that he tries to solve? Well, we have, particularly in our testing, we have tons of config files that are used all around and of course, every test needs some changes in a config file. And particularly in the DCN3 case, we end up having copies of the, like we copy the default config file from the doc examples directory of a given Osmo Com program and then we change some bits here and there. And particularly during development, maybe we change the config file syntax or we add some new commands. I'm not releasing breaking in the sense that we break compatibility, but breaking in the sense that there are additional lines or lines change order or things like that in the examples. So manually updating all those copies is not nice and in most cases that test really only wants to modify very few settings. Now in Osmo GSM tester, we use a template mechanism for that because we need to change really so many things about the configs, which is fine. This is not what this is trying to solve, but it's in other situations. And well, of course, the obvious is, oh, why don't we use a diff? Well, because diffs have context and the context is what is volatile in this particular problem and it means that diffs end up not applying anymore because of this, well, some changes in the context before or after the hunk in the patch. And so basically it doesn't work because diff assumes a, well, a textual structure of some sort and VTY has a different structure, which is organized on the node hierarchy. And the idea of Osmo config merge is basically to have some special patch format for config files in the Osmo comp style, which exploits this hierarchical structure by simply adding lines to the nodes of the tree. So, and if you think of the BSC, everybody knows there is like the network node and then there's the BTS node and there's a TRX node underneath and the time slot nodes. You basically need to specify the path of that node in the tree and then you can add some lines at the end of that node. The syntax is rather simple. You say Osmo config merge, the original config file, then any number of additional arguments that each specify those patches and there's a dash dash debug which will give you some output on what it does. So how does the patch look like? That's the simple patch example. So you basically say network beta zero tier Xero max power red 12. And that's your patch file that gets added to the original config file. And you hear some echo at times. So the result of this example then looks like this if you do a diff, right? So assuming that foo.diff is basically that file that I present here on this slide, then on the next slide, this is the result you get. Basically it iterates into that node and it adds that line at the bottom. Keep in mind that it adds it to the bottom, which is a nice way of not having to find if there are any other max power reduction commands further up in the VTY file and having to replace that or modify that, which would be more complex, it just adds it to the bottom because the file is parsed from top to bottom and if there is another power reduction earlier on, it will just be overwritten by the maximum power reduction at the end of the line. And if you do that three times, the last one will always prevail in the end. So it also exploits that particular way of how the VTY config files are parsed. Yeah, I could do a demo. Not sure if it's really necessary. Does anyone want to see a demo? No. Daniel wants to see a demo. Well, you will not see it over there, Daniel. You have to come here. Yeah, so I mean, it's pretty obvious what it does. It's really straightforward and as I said, I think it can be useful. Oh, sorry. So I see you're actually not replacing the line, but just adding it at the end. So that means if there's some kind of configuration which actually has some kind of state, which means if you're running twice, then it may not be the desired effect that you know what they mean. And I cannot think of any option like that, but I'm quite sure we probably have some. You cannot create new entire nodes that way. But that wouldn't, yeah, so that would, well, yes, you can actually. Yeah, but I'm thinking like some option which adds some new item into a list, for instance. Yes. Yeah, yeah. So it doesn't work for that. That's clear. The point about not replacing the original string line is that you need more context information. Of course, if you just have the text knowledge, this program doesn't know what kind of options are registered with the parser. So it doesn't know what is a fixed part of the command and what's an additional argument. So it doesn't have any context, but the text. So you cannot reliably replace any line in the text because you don't really know whether they might be identical or whether that's a different command. So let's say you have a line in the file that only has one command and an additional argument. And then you have a new line that has two arguments. Then you don't really know if that one is supposed to replace the first one or if it's really a different line. So do you need more knowledge about the? Well, in that case, I think we could have some parameters on flag to the program, which actually makes it replace or add it depending on what you look for. Yeah, well, patches are always welcome. I mean, the use case didn't, I mean, if there's a use case, yes. I mean, an existing use case that wasn't really needed. And I just thought this is a very quick hack to solve this. So related is that there have been a few times that the config file reading and writing process is broken in that if you load a valid config and write it out and then try to reload it, the program won't start because it doesn't like what it's written. Yes. So we should also test that. But it could also be a way of, if you load this modified config in to the program and write it, it would replace these double lines in the correct, in quotes, place, right? So is there a way to actually do that without starting the program as such? You know, like, you know, so Osmo VSC, for example, wouldn't start if it can't bind to its VTY port, so you wouldn't actually be able to. But would that be an idea to have some kind of a routine using the same code that's in the daemon to just say, read and rewrite this config file and then see if you can reread it? Not reliably. I mean, in theory, you can do it, but then there are things that, for example, create. So if you have a line that says control interface at that port, that line will actually make the control interface bind to that port. And if that's not available at the time, then it fails. Or if you configure an SS7 link or something, then an AS or whatever, it will actually, again, bind that port and want to allocate that resource. And you can't really separate that. I mean, OK, so an invalid command or something, a typo in your diff would also stop the program from starting. Of course, yeah. But the general problem of not writing, not being able to read what it writes, I think it should be possible to script or automatize the task to some extent. So basically, you would need some code that understands the way how we describe the possible arguments, the VTY syntax, basically. And then you can generate all kinds of files within that syntax, and then try to read it, and then write it out, and then you read it back. Or actually, even interactively, you could start it up, and then there could be a script that over the VTY, like over the telnet interface, actually changes things and writes it, and then you try to restart it or something like that. So I think it's certainly not ideal, but I think if somebody wanted to improve the situation, that would be, to some extent, it would be possible. I mean, the proper solution is, of course, to have a proper MIP, but that's another, for another time. I mean, to really, that's the, whatever, VTY 2.0 discussion that we had some time ago, but it's not likely to happen any time soon. What about restarting the program from within it, from within itself? Is that difficult to do? Restarting the program. Like just say, sort of, go back to startup time from within, so you would start the program, open VTY, write, and restart. Well, of course, you can exit yourself, I mean, if that's what you want, but then, of course, you lose all the stage, that's clear. That means you, you know, all the file descriptors, you would close, so all the Terranet, whatever, all the connections are gone. I mean, that's the same as having system D restarted when you kill it, basically. It's just without the system D involvement, or in it, D, or whatever. I mean, you know, so essentially, like typing, typing into the configuration terminal is the same as reading the configuration file, so it would be possible to just also tell the program to reread the configuration file at some point. That is, I think, is more realistic, though you then have the same problem about all the resources that already exist, so will you update them then? I mean, I think it's possible to do, I mean, the result will probably not reflect what most people expect at that point, because as you know, some things take immediate effect, some others don't, and that sort of, that problem still persists, but ignoring that, I think it should be possible to do it, because as you say, it's more or less the same thing that as if you enter it on the VTY, so why not reread the file? It will look up all the elements based on the nodes, and it will change all the settings. I said it's just those things that won't become active while interactively issuing VTY commands also won't become active at that point. Yeah, but that can be like something left up to the operator, but it is something I sort of deal with in terms of I want to make a change, but I don't want to restart, but I know that this change is possible without restarting, so then I can change it in the configuration terminal and maybe it requires resend system information and maybe it requires a restart of the VTS, but then I also have to go and edit the configuration file, otherwise I would lose that on the next restart, when I don't want to write because I never, I don't trust that anymore. Really? Having been bitten a couple of times by the non-re-reading of the written config. Of course, I mean, I can just verify that, I suppose on each version and then feel okay with it and then just write, use write, but... Maybe we should put some git integration there that you have a pre-write hook and a post-write hook that you can actually, so you can put the results under revision control. Then at least you know what has changed after the write, so you can look at the diff nicely. Maybe that's, it could be as easy as having whatever shell command that is issued before and after the write of the file. But we do make a backup copy one write, correct? Yes, but it's only one and it's not really a history. Okay.