WEBVTT 00:30.000 --> 00:33.280 The next speaker is Antonio Torres. 00:33.280 --> 00:36.120 He watches as part of a creative project. 00:36.120 --> 00:37.840 He's going to talk about DNS. 00:37.840 --> 00:41.040 He's one of the services that we maintain 00:41.040 --> 00:43.800 and automate in the creative system. 00:43.800 --> 00:45.080 So Antonio, you're welcome. 00:45.080 --> 00:45.960 Thank you. 00:49.960 --> 00:52.160 So first of all, can you hear me in the back? 00:52.160 --> 00:55.000 It's OK, it's perfect. 00:55.000 --> 00:56.280 So yeah, I'm Antonio Torres. 00:56.280 --> 00:59.160 As to when you said, I work for Red Hat, 00:59.160 --> 01:01.680 the free IP project. 01:01.680 --> 01:05.400 And this is basically what I've been working in the last few months. 01:05.400 --> 01:10.400 So if you see this title, probably your first question, 01:10.400 --> 01:11.840 if you're not familiar with the project, 01:11.840 --> 01:14.280 is what is behind the end of the buildup 01:14.280 --> 01:16.360 and what's up with this weird name. 01:16.360 --> 01:20.040 So yeah, do we now understand 01:20.040 --> 01:22.120 soon what's the ring of the name 01:22.120 --> 01:25.200 because actually it's a pretty descriptive name? 01:25.200 --> 01:26.960 It's a bit weird, but it works. 01:26.960 --> 01:32.240 So first, before explaining what it is, 01:32.240 --> 01:36.560 I need for people that are not familiar with the IPA. 01:36.560 --> 01:38.440 I need to explain that to you. 01:38.440 --> 01:40.760 So it's basically an identity management service. 01:40.760 --> 01:46.200 So you can handle users, holes, groups, things like that. 01:46.200 --> 01:52.240 So it obviously depends on LDAP and we also provide service 01:52.240 --> 01:53.760 for DNS. 01:53.760 --> 01:58.520 So there is a very basic FAAP server here, actually, 01:58.520 --> 02:01.520 we provide a lot more services than those two. 02:01.520 --> 02:05.520 But those are some of the main ones. 02:05.520 --> 02:08.680 Yeah, so for DNS, where it is in Divine Server, 02:08.680 --> 02:11.200 the DNS server that is going to bind 02:11.200 --> 02:13.880 and we're also using LDAP. 02:13.880 --> 02:16.760 So now you can see two of the three parts of the name. 02:16.760 --> 02:17.960 It's bind, LDAP. 02:17.960 --> 02:20.880 Now I'll explain DINDB. 02:20.880 --> 02:26.440 So first of all, what it does is, it's a plugin 02:26.440 --> 02:29.560 that manages this inclination between LDAP and DNS. 02:29.560 --> 02:33.840 So this means that every time you use the IP server 02:33.840 --> 02:37.680 to, for example, manage DNS zone or whatever, 02:37.680 --> 02:40.760 this plugin makes sure that this information 02:40.760 --> 02:42.320 that you're having or you're modifying, 02:42.320 --> 02:45.960 it's synchronized between DNS and LDAP. 02:45.960 --> 02:48.120 So you have this information on both servers. 02:48.120 --> 02:53.680 Yeah, as I said, it's used mainly in FAAP, 02:53.680 --> 02:55.840 but you can use it in a separate project. 02:55.840 --> 02:57.840 In the end, it's just LDAP and DNS. 02:57.840 --> 03:01.320 So if you have or the usage for it, you can use that. 03:01.320 --> 03:06.320 And the main source for the main source of this presentation 03:06.320 --> 03:09.040 and the problem that I explained later, 03:09.040 --> 03:13.320 it's that since this is very low level on the DNS side, 03:13.320 --> 03:15.840 we need access to internal bind API. 03:15.840 --> 03:18.280 So we use exactly the same functions 03:18.280 --> 03:21.880 that the bind developers use on the software. 03:21.880 --> 03:24.480 So there are a few problems with that, 03:24.480 --> 03:26.400 that I'll explain now. 03:26.400 --> 03:27.080 Yeah. 03:27.080 --> 03:32.240 So first, I need to introduce you to the last part of the name. 03:32.240 --> 03:34.360 Finally, so it's the DINDB. 03:34.360 --> 03:37.920 It's just an API that is part of bind. 03:37.920 --> 03:40.920 That basically enables external plugins 03:40.920 --> 03:45.880 to be part of the internal bind server. 03:45.880 --> 03:49.320 So basically, it can be, it's a way to use blinds. 03:49.320 --> 03:54.840 So they behave like if they were part of the blind source code. 03:54.840 --> 03:58.320 So that's what we're using for having access to all those 03:58.320 --> 03:59.800 internal bind features. 03:59.800 --> 04:04.960 And you can see this plugin is really, really easy to use. 04:04.960 --> 04:08.800 Thanks to the really, you only specify the your library 04:08.800 --> 04:12.360 and then you pass your arguments for whatever things you need. 04:12.360 --> 04:12.960 And you are done. 04:12.960 --> 04:16.960 So finally, now we understand the DIN and your project is bind. 04:16.960 --> 04:20.320 DINDB, LDAPS, so DINDB is the thing 04:20.320 --> 04:21.320 when you're in between. 04:21.320 --> 04:23.360 And then you have all the two servers. 04:23.360 --> 04:26.200 Yeah. 04:26.200 --> 04:28.880 So first of all, some is that's about the project. 04:28.880 --> 04:31.200 This is actually a pretty old project. 04:31.200 --> 04:34.680 It's from 18 years ago now. 04:34.680 --> 04:38.080 So it has quite an history. 04:38.080 --> 04:41.000 So we're 15 lines of SQL. 04:41.000 --> 04:44.000 I'll show you some examples later. 04:44.000 --> 04:46.840 And yeah, it's package in multiple distributions. 04:46.840 --> 04:49.960 So as I said, it's a critical component for FAPA. 04:49.960 --> 04:52.960 So that means in every base where you have FAPA, 04:52.960 --> 04:58.520 or you will have bind and DINDB, that it's a critical piece. 04:58.520 --> 05:05.280 So first, I want to introduce you to some of the releases 05:05.280 --> 05:10.720 scheduled for bind because you will see why it's important. 05:10.720 --> 05:14.280 So basically, they have stable ranges, branches, 05:14.280 --> 05:18.080 and every two versions, there's a stable branch 05:18.080 --> 05:22.880 that takes lives for approximately 40 years, more or less. 05:22.880 --> 05:26.280 So the last one, the latest is 1920. 05:26.280 --> 05:28.640 And the one before was 1918. 05:28.640 --> 05:33.360 And that's the latest version that the plugin supports. 05:33.360 --> 05:35.280 So what's the problem with this? 05:35.280 --> 05:37.440 This version is about to become L. 05:37.440 --> 05:39.400 So that means we can not rely on it, 05:39.400 --> 05:42.640 and we need to adapt the plugin to this new server. 05:42.640 --> 05:48.040 You may think, OK, 1918, 20 doesn't seem like a huge change. 05:48.040 --> 05:50.320 It's just a minor version. 05:50.320 --> 05:52.080 So it's not that easy. 05:52.080 --> 05:56.360 So one day, we got a deep ticket. 05:56.360 --> 05:59.520 You can see it's not a very long. 05:59.520 --> 06:04.040 Basically, it's commenting that there was a change upstream, 06:04.040 --> 06:06.000 that removed some headers. 06:06.000 --> 06:10.120 So at first, you may think, OK, some headers. 06:10.120 --> 06:11.400 No biggie. 06:11.400 --> 06:14.720 But after you start looking into it, 06:14.720 --> 06:16.880 you will see that it's not that easy, 06:16.880 --> 06:21.120 because the five that they removed is all the headers 06:21.120 --> 06:23.440 that they had for 100 multi-threading. 06:23.440 --> 06:26.920 So basically, since this is a plugin that 06:26.920 --> 06:29.880 is connecting to server, you obviously need 06:29.880 --> 06:33.200 to need to handle multiple threads. 06:33.200 --> 06:36.800 So this was a critical part of the plugin, 06:36.800 --> 06:38.320 and it's completely removed. 06:38.320 --> 06:40.040 It's all over the code, and it's removed. 06:40.040 --> 06:42.480 It's not as simple header that you can. 06:42.480 --> 06:44.960 Maybe avoid the included, whatever. 06:44.960 --> 06:47.160 It's a very important change. 06:47.160 --> 06:50.240 So that was the first issue. 06:50.240 --> 06:52.400 You will see it's not the only one. 06:52.400 --> 06:57.760 So as I said, it's a very important change. 06:57.760 --> 07:01.520 So that's what the first problem, the second problem 07:01.520 --> 07:05.200 is that we can not forever live on 9-8 thing, 07:05.200 --> 07:08.680 not only because of it being out of support, soon, 07:08.680 --> 07:13.360 but also because we are already good luck to use 07:13.360 --> 07:15.680 some new features of bind 9-20. 07:15.680 --> 07:17.440 So for example, recently, in VAPA, 07:17.440 --> 07:19.760 we introduced a included in a support. 07:19.760 --> 07:24.320 This is so be-read, related to, 07:24.320 --> 07:27.720 obviously related to bind. 07:27.720 --> 07:31.520 But the bad thing is that we would like to use 07:31.520 --> 07:35.080 a file string DNS, included DNS for a wording, 07:35.080 --> 07:38.880 that is available in bind 9-20, but not in 9-8 things. 07:38.880 --> 07:41.160 So we had to do some work around for now. 07:44.560 --> 07:47.720 Yeah, the second problem, the bind 9-10 developed, 07:47.720 --> 07:50.240 as you showed, is a really old, 07:50.240 --> 07:51.960 and it's very difficult to maintain. 07:51.960 --> 07:55.560 So it's a C code that is, let's say, 07:55.560 --> 07:57.520 it's not the best written code. 07:57.520 --> 08:01.200 Yeah, there are some issues with it. 08:01.200 --> 08:04.200 I'll show you some examples later. 08:04.200 --> 08:06.920 There's maybe some of you may see already 08:06.920 --> 08:11.760 a problem here, and it's that we can adapt the plugin now 08:11.760 --> 08:15.120 for 9-4, version 9-20, but in the future, 08:15.120 --> 08:17.440 maybe we have this in problem again. 08:17.440 --> 08:20.480 With 9-22 or 24 or whatever. 08:20.480 --> 08:22.160 So yeah, I will talk about later. 08:23.560 --> 08:28.560 So whatever, the decision was to play widely completely. 08:29.200 --> 08:33.200 So there was this change for the opportunity 08:33.200 --> 08:38.200 to, since we have to completely replace all the, 08:40.200 --> 08:41.680 all the synchronous interface. 08:41.680 --> 08:44.240 There was this opportunity to actually 08:44.240 --> 08:49.240 re-organize the project, and try to make it more maintainable, 08:49.520 --> 08:51.200 more easy to understand. 08:51.200 --> 08:55.000 So yeah, we did that, or we're doing that. 08:56.560 --> 08:58.200 We're trying to adapt as much code, 08:58.200 --> 09:01.960 so I'm talking about the synchronous interface, 09:01.960 --> 09:05.520 but actually there were some multiple changes. 09:05.520 --> 09:09.720 Since we had using the internal bind 8-8 bind developers, 09:09.720 --> 09:12.880 changed the functions to whatever they need. 09:12.880 --> 09:13.800 That's fine. 09:13.800 --> 09:16.640 But that means that we also need to do those changes, 09:16.640 --> 09:21.400 and after trying to build with this new version, 09:21.400 --> 09:25.240 we found a lot of functions that were deprecated 09:25.240 --> 09:27.640 and then removed, or arguments change it, 09:27.640 --> 09:29.760 and whatever, and all those need fixes. 09:32.720 --> 09:35.320 And last of all, we actually took the opportunity 09:35.320 --> 09:37.240 to change the license of the project. 09:37.240 --> 09:38.560 I'll explain later. 09:38.560 --> 09:45.200 Okay, so I'm going to explain the new architecture, 09:45.200 --> 09:47.040 and you will see it's actually really simple, 09:47.040 --> 09:49.280 because we are looking for a really simple plugin 09:49.280 --> 09:50.440 that just works. 09:50.440 --> 09:54.720 So there will be one main thread that will run the plugin, 09:54.720 --> 09:56.800 and then you have multiple threads, 09:56.800 --> 10:00.760 only for reading or for writing, from and to elder, 10:00.760 --> 10:02.560 from and to DNS. 10:03.760 --> 10:05.720 So the main thread will run a logic, 10:05.720 --> 10:07.680 just synchronize the information. 10:07.680 --> 10:09.080 We do one thread on the other, 10:09.080 --> 10:11.360 and those threads are only readers or writers. 10:11.360 --> 10:13.040 So they only have one work, 10:13.040 --> 10:15.600 and they only need to do that, nothing else. 10:16.680 --> 10:19.640 And we are all doing this using this new interface. 10:19.640 --> 10:24.120 I'm mentioning, so this is actually a really nice feature 10:24.120 --> 10:26.880 from bind, so it's a good change, they did. 10:26.880 --> 10:30.600 It's too bad they broke out, but yeah, that's how it is. 10:30.600 --> 10:32.440 It's a really nice change, actually. 10:32.440 --> 10:34.600 So you will see it's really, 10:34.600 --> 10:37.160 the architecture is really simple, actually. 10:37.160 --> 10:41.840 So this is a show in the reading from LDAP. 10:41.840 --> 10:44.400 So you see, we are just reading, 10:44.400 --> 10:46.720 send it to the worker, 10:46.720 --> 10:50.560 do whatever we need, and then you have it in the main thread, 10:50.560 --> 10:53.440 and you can do Jordan, okay? 10:53.440 --> 10:56.920 And the other way around is exactly the same. 10:56.920 --> 10:59.720 You have the notification, you write it to LDAP, 10:59.720 --> 11:02.400 and you are done, it's really simple. 11:03.080 --> 11:08.080 So I'm going to show you some examples of changes with it, 11:08.080 --> 11:10.360 and where I'm talking about this, 11:10.360 --> 11:12.480 plugin being difficult to maintain. 11:12.480 --> 11:15.080 So for example, this is one example 11:15.080 --> 11:17.080 that actually most of the code, 11:17.080 --> 11:21.840 so I mentioned the code, it was about 15,000 lines long. 11:21.840 --> 11:27.360 So, 5000 of those was in one single file, 11:27.360 --> 11:29.560 so that's one third of the project in one file. 11:29.560 --> 11:32.320 And that's commonly not very good. 11:32.320 --> 11:36.280 So there was also the issue, this was a general issue 11:36.280 --> 11:38.760 with all the files, the source files, 11:38.760 --> 11:41.760 those were all in the same folder. 11:41.760 --> 11:45.880 So no file structure at all. 11:45.880 --> 11:48.760 So we actually managed to properly sort 11:48.760 --> 11:53.760 and divide all these different files into files that make sense. 11:53.760 --> 12:00.080 And other issue we had was the naming for the functions. 12:00.080 --> 12:07.080 So since this is acting as a plugin for bind, 12:07.080 --> 12:11.480 we need to be really careful with the naming for the functions 12:11.480 --> 12:15.320 to avoid any kind of collision or whatever. 12:15.320 --> 12:20.120 So there was this issue that really the naming 12:20.120 --> 12:23.120 for the functions had no convention at all. 12:23.120 --> 12:26.040 It was whatever the developer at the time 12:26.040 --> 12:27.360 decided at the moment. 12:27.360 --> 12:30.200 And you can see that is really no any. 12:30.200 --> 12:35.000 And there is no prefix and the names themselves 12:35.000 --> 12:36.480 are not really discrete. 12:36.480 --> 12:39.880 So we did a complete renaming of all the functions. 12:39.880 --> 12:44.400 We included this prefix BDL, so that's binding the VL app 12:44.400 --> 12:48.120 to make sure that there are no conflicts. 12:48.120 --> 12:50.520 And actually while doing this change, 12:50.520 --> 12:55.880 we actually had a bug that there was one of the functions. 12:55.880 --> 12:59.320 So first, we didn't use this BDL prefix. 12:59.320 --> 13:01.400 So we were just doing, for example, 13:01.400 --> 13:05.120 L app pool in it or L app new connection. 13:05.120 --> 13:07.880 And this actually there was actually one collision 13:07.880 --> 13:09.560 with the open L app library. 13:09.560 --> 13:14.520 And there was this difficult to find bug. 13:14.520 --> 13:17.560 So they were trying to avoid those kind of things. 13:17.560 --> 13:22.640 So we'll just use this BDL prefix. 13:22.640 --> 13:29.880 So other things we had in this old plugin 13:29.880 --> 13:34.040 was that since it was within 18 years ago, 13:34.040 --> 13:38.000 there's been a lot of different bind versions since then. 13:38.000 --> 13:40.560 So there was a lot of checks all over the code 13:40.560 --> 13:43.720 for obsolete versions that we are not going to support anymore. 13:43.720 --> 13:46.600 I have not been supporting for a long time now. 13:46.600 --> 13:48.480 So we can remove all that code, 13:48.480 --> 13:51.280 and just have a more tidy code base. 13:54.280 --> 13:56.560 Yeah, this is actually funny. 13:56.560 --> 14:01.560 So there were a lot of two new messages left a long time ago. 14:01.560 --> 14:05.440 And you can see some of them are not really difficult. 14:05.440 --> 14:07.280 No, no difficult things to implement, 14:07.280 --> 14:08.600 but they were just forgotten. 14:08.600 --> 14:12.040 So for example, to do lock something, 14:12.040 --> 14:13.520 to do verify this. 14:13.760 --> 14:15.920 You know, it's things that you really should do 14:15.920 --> 14:17.720 in a production environment, right? 14:17.720 --> 14:20.880 So yeah, we did take care of this, 14:20.880 --> 14:22.440 remove whatever was not needed, 14:22.440 --> 14:24.880 and address whatever we needed to fix. 14:27.360 --> 14:32.360 And lastly, I mentioned earlier the changes in the bind API. 14:35.040 --> 14:37.960 So as I said, apart from this big change, 14:37.960 --> 14:39.520 the synchronous interface, 14:39.520 --> 14:41.080 there were a lot of minor changes 14:41.080 --> 14:45.320 in the internal functions they used. 14:45.320 --> 14:47.480 And obviously we needed to fix a dose. 14:47.480 --> 14:51.240 So I'm going to give you some examples. 14:51.240 --> 14:54.840 So sorry. 14:54.840 --> 14:58.080 So since these are internal functions, 14:58.080 --> 15:03.080 they are understood by bind developers only, basically. 15:03.720 --> 15:09.000 So those are not to be supposed not supposed to be used 15:09.000 --> 15:12.160 by people, people outside the project, really. 15:12.160 --> 15:17.160 So in some cases, the only documentation 15:17.160 --> 15:20.280 available was the actual commit lock. 15:20.280 --> 15:25.280 So for I was just reading all the divs in the commits, 15:26.000 --> 15:28.680 looking at the code itself and the stand in the changes 15:28.680 --> 15:30.520 and then doing the changes in our applying. 15:30.520 --> 15:33.920 So there wasn't really much documentation 15:33.920 --> 15:35.800 about these changes. 15:35.800 --> 15:38.280 So the only way to do it was to really 15:38.320 --> 15:39.120 the code itself. 15:41.720 --> 15:47.000 So yeah, some people may think, okay, 15:47.000 --> 15:50.520 you're basically renaming functions, adapting code. 15:50.520 --> 15:53.880 That sounds like I would go to stage of IA. 15:53.880 --> 15:55.920 So yeah, why didn't you try it? 15:55.920 --> 16:00.920 So we tried and I'm going to show you some of our findings. 16:01.320 --> 16:03.520 I think you will have fun with this. 16:03.520 --> 16:09.640 So we use, we're using this prompt 16:09.640 --> 16:12.560 that is expanding the issue basically and just, 16:13.560 --> 16:18.520 so try to ask the A what was changed 16:19.240 --> 16:23.080 and how should we fix it, okay? 16:23.080 --> 16:26.840 So we're going to try with three different clients. 16:26.840 --> 16:30.080 One is chat, EPD. 16:30.160 --> 16:33.600 Gemini, I am finally on the most promising one. 16:33.600 --> 16:34.960 Cloth, so let's see. 16:36.800 --> 16:38.400 First, chat, GPD. 16:40.520 --> 16:44.680 It was actually somehow able to find 16:44.680 --> 16:48.480 that their sync library was changed it 16:48.480 --> 16:50.440 and we needed to adapt to that. 16:51.920 --> 16:55.400 And it was actually able to understand 16:55.400 --> 16:58.240 that it's not a trivial change. 16:58.280 --> 17:01.440 So it was able to detect that it was a typical change. 17:01.440 --> 17:05.080 But then what was the proposed solution? 17:08.160 --> 17:09.720 The move, whatever it's not working. 17:10.800 --> 17:12.760 Elab call back, Nul. 17:12.760 --> 17:14.440 There is no call back, no problem. 17:15.600 --> 17:18.120 Here there's the move, okay, remove the includes 17:18.120 --> 17:19.320 and it's fixed. 17:19.320 --> 17:21.520 So obviously this is not a proper solution. 17:23.240 --> 17:25.160 Next, we went with Gemini 17:25.160 --> 17:28.160 and this was funnier, I think, 17:28.160 --> 17:31.600 because it actually was mentioned 17:31.600 --> 17:35.080 in that where some commits in our plugin log messages 17:35.080 --> 17:37.440 that already fixed the issue. 17:37.440 --> 17:39.440 So basically we already fixed the issue 17:39.440 --> 17:42.680 but we forgot about it and it was proposed 17:42.680 --> 17:45.360 in some commit hashes for this change. 17:45.360 --> 17:50.360 So please tell me, it came up with three commits 17:50.360 --> 17:53.600 that obviously are completely fantasy. 17:53.600 --> 17:56.440 They don't exist, the commit message is invented. 17:56.440 --> 18:00.800 The hashes does not exist, it's completely fantasy. 18:00.800 --> 18:05.800 So yeah, I wish they existed but they do not. 18:05.800 --> 18:08.400 So yeah, finally Claude. 18:08.400 --> 18:12.080 So we have been told that Claude is the best AI 18:12.080 --> 18:14.760 for coding and for this kind of things. 18:14.760 --> 18:20.440 So we should really try and let's see if it can do 18:20.440 --> 18:23.080 whether that chatipity and Gemini. 18:23.080 --> 18:28.960 So this was fun because the other two took maybe a minute 18:28.960 --> 18:31.080 to reply so they were quick. 18:31.080 --> 18:34.960 But in the case of Claude, it actually looked like it was 18:34.960 --> 18:38.080 trying to understand the changes. 18:38.080 --> 18:42.200 So it took like 30 minutes asking questions. 18:42.200 --> 18:45.080 Hey, can I query this web page? 18:45.080 --> 18:46.720 Hey, can I do this change? 18:46.720 --> 18:48.080 Can I run this comment? 18:48.080 --> 18:49.640 Can I install this package? 18:49.640 --> 18:52.320 So it was like 30 minutes and it said, okay, 18:52.320 --> 18:54.160 I will prepare an analysis document 18:54.160 --> 18:55.800 without the things I found. 18:55.800 --> 18:58.120 And then you can follow these steps, 18:58.120 --> 19:00.320 so you can fix your issue. 19:00.320 --> 19:01.640 Yeah. 19:01.640 --> 19:09.040 So basically it had good news, apparently. 19:09.040 --> 19:12.480 And that's that most of the 1920 changes 19:12.480 --> 19:14.200 don't affect this code base. 19:14.200 --> 19:15.320 Obviously it's a lie. 19:15.320 --> 19:20.360 I wish that was the case but it says that the planning 19:20.360 --> 19:24.160 is an usage using those byte libraries 19:24.160 --> 19:27.680 and all the current IPA usage remains compatible. 19:27.680 --> 19:30.680 It's obviously lie. 19:30.680 --> 19:35.080 So it was actually found so misuse, 19:35.080 --> 19:38.360 but those are really not major issues. 19:38.360 --> 19:42.120 So there was an undefined autocomph macros, 19:42.120 --> 19:45.320 obviously minted but not no big deal. 19:45.320 --> 19:49.760 And also this one thing, it was actually able to identify 19:49.760 --> 19:51.680 and that's the for future proofing, 19:51.680 --> 19:54.360 the database transition to from air ready to keep it 19:54.360 --> 19:56.480 so that's actually something that we need to do 19:56.480 --> 19:59.520 in the future, but again, it's not the main issue. 19:59.520 --> 20:01.440 It's yes, nice to have in the future. 20:01.440 --> 20:06.280 So yeah, it's basically the same result of the other two, 20:06.280 --> 20:09.320 but wait in 30 minutes. 20:09.320 --> 20:13.600 We had actually, we had actually one team member 20:13.600 --> 20:16.800 tried to, we've got tried to give it more context. 20:16.800 --> 20:19.360 So it actually maybe understood better. 20:19.360 --> 20:22.200 The context. 20:22.200 --> 20:27.040 So and in the end, it did the same. 20:27.040 --> 20:29.120 Remove the old decode that was not working. 20:29.120 --> 20:34.840 So yeah, it's basically the same after the other two, 20:34.840 --> 20:36.720 but taking two hours more. 20:36.720 --> 20:39.280 Yeah. 20:39.280 --> 20:43.840 So anyways, forgetting about AI, 20:43.840 --> 20:46.000 we now have a version of the planning 20:46.000 --> 20:49.000 that is compiling and is some working. 20:49.000 --> 20:54.200 I mean, so how because we still need to do a lot of testing. 20:54.200 --> 20:57.400 So the good thing is that we actually have a lot of tests 20:57.400 --> 21:02.320 because of the IPA, so we have a lot of different scenarios 21:02.320 --> 21:06.520 to test and things to check. 21:06.520 --> 21:07.800 So that's what we're doing now. 21:07.800 --> 21:10.080 Just running the test, see where it's failing, 21:10.080 --> 21:12.280 where it's not, what it's working, and where it's not working, 21:12.280 --> 21:14.720 and just trying to address those issues. 21:14.720 --> 21:16.320 So this is something that is really helpful. 21:16.320 --> 21:21.320 Having that suite of tests to actually try to code all the code. 21:23.920 --> 21:27.920 In the future, we also want to make use of some performance testing. 21:27.920 --> 21:32.920 We have a project in VIPA that is able to run tests 21:33.240 --> 21:34.880 for almost everything in VIPA. 21:34.880 --> 21:38.560 So we can, for example, add 1,000 DNS zones 21:38.560 --> 21:40.800 and see how fast it is performing, 21:40.800 --> 21:41.960 compiling to the last version. 21:41.960 --> 21:45.640 I hope it's faster because of this new asynchronous interface. 21:45.640 --> 21:46.480 With it. 21:47.680 --> 21:51.080 So for the future, we have two options. 21:51.080 --> 21:53.240 So I'm going to actually explain the reason 21:53.240 --> 21:55.560 why we change the plugin license. 21:55.560 --> 21:59.840 So the change was to match the upstream bind. 21:59.840 --> 22:02.080 And the idea is that maybe in the future 22:02.080 --> 22:04.600 this plugin can be part of the upstream bind 22:04.600 --> 22:09.240 to the repository, I think this can be useful for both sides. 22:09.240 --> 22:12.360 So for bind, they get an important feature 22:12.360 --> 22:14.560 that a lot of customers are looking for. 22:15.640 --> 22:21.600 For us, we can ensure that the compatibility remains safe 22:21.600 --> 22:22.840 between every release. 22:22.840 --> 22:28.280 So basically, the bind is taking into account for every change. 22:28.280 --> 22:31.360 And there's actually this nice message 22:31.360 --> 22:37.360 from the documentation that the DINDVAPI was contributed 22:37.520 --> 22:38.360 by Redhat. 22:38.360 --> 22:41.720 They were a person in the past and this is a little thank you. 22:41.720 --> 22:44.440 So there's a share with that. 22:44.440 --> 22:48.680 There was actually more contributions in the past. 22:48.680 --> 22:52.720 So if for whatever reason, this is not possible, 22:52.720 --> 22:56.720 we would like for bind to have a some kind of external API 22:56.720 --> 22:58.880 so that that can remain stable. 22:58.880 --> 23:02.480 And we can use that instead of using the internal API. 23:02.480 --> 23:04.840 And there's actually a draft in upstream bind. 23:04.840 --> 23:08.800 So we will try to talk with the developers 23:08.800 --> 23:14.000 and try to make sure that this future API contains all the features 23:14.000 --> 23:16.800 that we need for the plugin. 23:16.800 --> 23:17.960 So yeah, thank you. 23:18.080 --> 23:24.080 . 23:24.080 --> 23:26.800 So we have the same for questions. 23:26.800 --> 23:31.120 So any confused. 23:31.120 --> 24:00.320 So, it's going to be a replace, oh yeah, the question. So, this person saw the discussion about this in the 24:00.320 --> 24:07.320 December millilist and he's asking whether it will work with somebody in future versions. 24:07.320 --> 24:12.640 So, the idea is for this to be a one-to-one replacement to the old plug-in. So, whatever 24:12.640 --> 24:16.280 thing that worked in the old plug-in will work in this version. So, we are not removing 24:16.280 --> 24:18.280 support for anything. 24:18.280 --> 24:22.920 I was, I was, I was expecting the question. 24:22.920 --> 24:29.920 So, the idea is still, the old G is still not located by anybody, it will be. 24:29.920 --> 24:31.920 So, it's a different one. So, it's a different one. 24:31.920 --> 24:35.920 So, it's a different one. So, it's a different one. 24:35.920 --> 24:36.920 Yeah. 24:36.920 --> 24:41.920 So, what anyway, yeah, I mean the trends from mine we all have been all used to was in the five, 24:41.920 --> 24:43.920 under the years, the number of people who support it. 24:43.920 --> 24:49.920 Yeah, very fascinating based on their customers, and every time they release something new. 24:50.920 --> 24:53.920 Yeah. 24:53.920 --> 24:58.920 So, we were forced to write a word in terms of plug-in, or held up. 24:58.920 --> 25:01.920 Oh, yes. 25:01.920 --> 25:07.920 Yeah, we were forced to write the entire plug-in in order to support a new version of mine. 25:07.920 --> 25:10.920 That is coming with new features like, for wording, I stuff like that. 25:10.920 --> 25:16.920 For the reasons like features like, I've greeted you in as that Antonio mentioned at the very beginning. 25:17.920 --> 25:21.920 But yeah, this is solving the problem for us for five years maybe. 25:21.920 --> 25:28.920 And then at some point, there will be a new version of mine, and then we will need to check again the plug-in. 25:28.920 --> 25:35.920 So, at least now, we have time to talk to mine and see if we can collaborate. 25:35.920 --> 25:40.920 Either way, the option one that Antonio mentioned is to send the plug-in to them. 25:40.920 --> 25:45.920 So, they can integrate in the proper way. So, every time they release something new, they make sure it works. 25:45.920 --> 25:56.920 And the other way is perhaps they could improve or expose more stuff through an external API that somehow and free-pay we could use or rely on. 25:56.920 --> 26:01.920 So, that we don't break every time they release a mine new version. 26:01.920 --> 26:06.920 So, we can continue discussing because we, the time is up. 26:06.920 --> 26:09.920 We have another talk now. 26:09.920 --> 26:11.920 So, thank you. Thank you. 26:11.920 --> 26:12.920 Thank you. 26:15.920 --> 26:20.920 Thank you.