Using systemd to high level languages
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 50 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43133 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
All Systems Go! 20186 / 50
1
4
11
12
13
14
16
17
19
23
24
25
29
30
32
34
35
39
40
41
43
44
50
00:00
SpacetimeSystem programmingHigh-level programming languageProduct (business)Library (computing)FacebookProgramming languageLevel (video gaming)Physical system
00:47
System programmingPhysical systemInformationData managementHigh-level programming languageGoodness of fitLibrary (computing)Presentation of a groupFunction (mathematics)Physical systemSoftware maintenanceInstance (computer science)FacebookScripting languageField (computer science)MereologyService (economics)Bus (computing)Group actionProgramming languageComputer animation
02:45
Physical systemInformationDecision theoryService (economics)Group actionMessage passingBus (computing)System programmingService (economics)CodeDecision theoryVirtual machineTelecommunicationInformationNamespaceIntegerLevel (video gaming)Gastropod shellGoodness of fitBitSoftware developerDemonInterface (computing)Physical systemString (computer science)Type theorySystem callHigh-level programming languageQuicksortData managementExecution unit
05:21
Network topologyService (economics)Object (grammar)Physical systemAttribute grammarExecution unitReverse engineeringDomain nameSymbol tableInstance (computer science)Source codeXML
06:17
Object (grammar)Category of beingParameter (computer programming)Interface (computing)Attribute grammarMultiplication signWordEndliche ModelltheorieFunctional (mathematics)Service (economics)Physical systemExecution unit
07:18
Object (grammar)Communications protocolInformationObject (grammar)Interface (computing)Address spaceCategory of beingLibrary (computing)Peer-to-peerTouch typingXMLComputer animation
07:50
Representation (politics)TheoryLoginSystem programmingParameter (computer programming)Library (computing)Physical systemCategory of beingType theoryRepresentation (politics)Object (grammar)TheoryElectronic mailing listIdentifiabilityInterface (computing)
08:46
Electronic visual displayCategory of beingCohen's kappaBus (computing)Object (grammar)Parameter (computer programming)Direction (geometry)Library (computing)Type theoryImplementationObservational studyXML
09:19
Keyboard shortcutInheritance (object-oriented programming)ImplementationLibrary (computing)SoftwareWikiSoftware developerMultiplication signLibrary (computing)BlogMereologyImplementationLatent heatCommunications protocolPhysical systemBus (computing)Exterior algebraAuthorizationKeyboard shortcutComputer animation
10:27
Keyboard shortcutSystem programmingLie groupScripting languageProgramming languageCheat <Computerspiel>Library (computing)Physical systemCommunications protocolBus (computing)FacebookKeyboard shortcutWeb pageMathematicsWordComputer configurationArithmetic meanSoftware developerState diagramPersonal identification number
12:04
Social classVirtual machinePhysical systemError messageCodeRevision controlProgramming languageException handlingPattern languageSound effectPropagatorMultiplication signSystem callLibrary (computing)Social classInformationParameter (computer programming)Execution unitFerry CorstenComputer animation
13:03
RankingCartesian coordinate systemPoint (geometry)CodeMultiplication signDifferent (Kate Ryan album)Exception handlingBitError messageFerry Corsten
13:38
Social classProgramming languageWritingObject (grammar)Point (geometry)System callSocial classView (database)Computer animation
14:19
System programmingRankingVideoconferencing
14:43
Local GroupLimit (category theory)LeakPrincipal ideal domainRootNetwork socketDemonInformationCASE <Informatik>Execution unitProcess (computing)Bus (computing)Software developerFunction (mathematics)Real numberInterface (computing)Network socketSystem callEmailWritingIntegerDecision theoryLevel (video gaming)Physical systemGoodness of fitKey (cryptography)MereologyRadio-frequency identificationCodeProgramming languageInstallation artCircleSolid geometryFile formatMultiplication signService (economics)JSON
17:11
System programmingSheaf (mathematics)CodeExecution unitNetwork socketType theoryInheritance (object-oriented programming)Principal ideal domainAsynchronous Transfer ModeMilitary operationGastropod shellCache (computing)WebsiteContext awarenessStapeldateiScripting languagePerspective (visual)Level (video gaming)Physical systemProcess (computing)File formatGroup actionInformationExecution unitSystem callBarrelled spaceService (economics)Integrated development environmentDistribution (mathematics)Inheritance (object-oriented programming)CodeSheaf (mathematics)Cartesian coordinate systemSet (mathematics)Portable communications deviceType theoryRight angleVirtual realityMultiplication signWeb pageSoftware developerPurchasingInstance (computer science)VirtualizationComputer animation
21:10
RankingContext awarenessGastropod shellIntegrated development environmentComputer fileTemporal logicFile systemBinary fileCodeDistribution (mathematics)Cartesian coordinate systemInstance (computer science)
21:41
Gastropod shellAsynchronous Transfer ModeMilitary operationCache (computing)WebsiteContext awarenessLibrary (computing)Set (mathematics)Virtual realitySoftware developerMathematics1 (number)Uniform resource locatorProduct (business)Context awarenessConfiguration spaceInstance (computer science)Physical systemComputer animation
22:35
Context awarenessGastropod shellFerry CorstenContext awarenessProcess (computing)Multiplication sign
22:58
Scheduling (computing)Process (computing)DatabaseBackupExecution unitVirtual machineSoftware developerStapeldateiScripting languageMultiplication signBlock (periodic table)DatabaseScheduling (computing)Instance (computer science)Data structureComputer animation
23:28
RankingService (economics)Multiplication signProcess (computing)Gastropod shellScripting languageData managementSystem call
23:55
DatabaseProcess (computing)BackupExecution unitScheduling (computing)InformationElectronic visual displayMilitary operationDemonExecution unitAreaBitService (economics)Computer fileAttribute grammarScripting languageGastropod shellLimit (category theory)MathematicsComputer animation
24:52
DatabaseMilitary operationDemonSystem programmingInformationProcess (computing)Electronic visual displayExecution unitService (economics)Physical systemScripting languageBackupMultiplication signMathematicsService (economics)Normal (geometry)Scheduling (computing)Remote procedure callQuicksortUser interfaceExecution unitBuildingPhysical systemProgramming languageLibrary (computing)Bus (computing)Interface (computing)JSONComputer animation
26:22
System programmingObject (grammar)Physical systemLibrary (computing)Service (economics)Operator (mathematics)Slide ruleRight angleBridging (networking)CuboidNetzwerkverwaltungParameter (computer programming)Interface (computing)Functional (mathematics)Multiplication signType theoryData management1 (number)EmailLoop (music)Computer configurationJSONMeeting/Interview
29:19
Inheritance (object-oriented programming)Keyboard shortcutElectronic visual displayCategory of beingBus (computing)Object (grammar)Cohen's kappaLoginError messageObject (grammar)Execution unitService (economics)LoginProper mapInterface (computing)QuicksortAttribute grammarJSONXML
29:59
System programmingObject (grammar)Data managementInterface (computing)Virtual machineGeneric programmingNetzwerkverwaltungSocial classAttribute grammarInstance (computer science)Inheritance (object-oriented programming)System call
30:44
Local ringQuadrilateralSystem programmingException handlingMultiplication signRight angleVirtual machinePhysical systemPerfect groupSocial classLoginLogicSource code
31:23
FacebookSystem programming
Transcript: English(auto-generated)
00:06
OK, cool. So hi, guys. I'm Alvaro Leyva. I'm a production engineer at Facebook and Instagram. And I'm here to talk to you about how about we use systemd in high-level languages.
00:20
systemd is already written in C. So that's already a high-level language. But I'm talking higher-level languages, like Python, Node, API, sorry, Node, yeah. Node, JavaScript, PHP, all those languages that are not really nuanced and stuff. OK, cool. So basically, this talk will have two portions.
00:45
One is how we, as Facebook, did a library that talks to systemd directly instead of shelling out, and then a few fun things that we do with it. The idea of this presentation is not to say, hey, guys, go and use our library.
01:00
It's more on the sense like, hey, this is all the things that we learn by creating this library. You should all go and create your own libraries in your own languages. And if you also want to do one in Python, that's the one that I'm going to present, go for it. This is really fun. And this is something that we can all learn from. So let me start with the initial journey on how we start with this.
01:23
So this started basically when we were at Instagram. We needed to migrate all of our fleet to CentOS 7, because that was part of what Facebook was doing. David has talked about this for two years now. He promised in this year that we have already done this,
01:43
and we were one of the last groups to do this. And the reason why it was hard for us is because we had a lot of maintenance scripts that rely on the underneath service manager. One of the things that we typically do is that we would execute stuff like etc, initd, Cassandra status.
02:01
And then we parse the output, and then that's how we decided if Cassandra was running or not running, and all the things. And so all the things that were not really possible, but that was not a good idea to do it with systemd, and for good reasons. So for instance, systemd comes with systemctl status, which is really great for humans,
02:22
but it's really hard to parse the output. And systemd does provide a lot of tooling to do this from the command line. Even systemctl has a child status that will ask you individual fields. You can also use busctl and all those stuff. But if you are in a high-level language,
02:41
again, I use this as a synonym for Python. To do this, you have to shell out, and at least from my personal experience, shell it out. I've considered it a little bit clowny on those things. So it would be really nice to have a really nice and native interface to talk to systemd.
03:01
So it basically all starts with divas, right? So from an external developer, not a systemd developer, but from an external developer that wants to interact with systemd, this is, for me, the best decision that could have ever gone into systemd. Like, using divas as a way to interface with systemd.
03:22
This basically allows external services to communicate through this daemon and get all the information that you need from it in a way that is not as clowny or hacky as like executing a command, getting a text out, parsing the text, and then if that text is supposed to be like a piv, convert that into string,
03:40
sorry, convert that into an integer that has its own problems. So it was really kind of a surprise to me when I started working with this that this is also how systemd most internal tools work. And it's kind of because we all know that the divas daemon is not present at every stage of the machine.
04:01
Like, it's not really present at the beginning and at the end, shut down and start. But for most general things, this is how you communicate. This is how even systemd tooling communicate. So firstly, if you go and read systemd code, which I'm assuming that everybody here has done it, you will see all this type of code.
04:20
Like, systemctl, communicate to the manager, systemd run, which is something that I really like to use and have used. Also communicate through divas to start the transient unit. And even machinectl, like instead of telling out or changing namespace or doing other things that you could do, just communicate to the divas daemon running inside the machine.
04:42
I'm pretty sure that I'm gonna get corrected about this, but at least this is how I view it from the outside. So divas is really great, and it's something that we could really use. In general, if you forget all about this and you need a really good IPC layer to communicate, like, use divas.
05:00
It's really reliable. I expect people can tell you otherwise. So since everything start with divas, if you're gonna interact with systemd from a high-level language, you should literally just start with divas. So let's see a little bit how diva things work. So systemd comes with a nice tool that is busctl.
05:22
Busctl, when you execute it without any comment, it will just show you all the services that are running on your system. And these are all things that you already know since like systemd1 or hostname that is called the reverse domain something. Sorry, I black out on that. Well, basically, these are all the services, right?
05:42
If you go and explore one of the services, you will see objects. And objects, you can always look at this like name of instantiated attributes or instantiated objects on the system. For instance, for systemd, these are all the objects that you can connect. And then you see, even though they have like weird names, they're all in target or service.
06:01
So if you don't know anything how this thing works, but you have only worked with systemd, those doing like start creating units and stuff like that, you will start to see like there's a certain resembles and this looks like a really programmatic way to access this data. So if you go and actually do an introspect into this,
06:21
you will see that it has interfaces that has names that are really similar to what you would expect them to have. Like if I'm inspecting the service unit, you will expect that I will have org.freeDesktop.systemd.service. And then inside those, you have methods and properties.
06:41
And I'm pretty sure that this is really known for everybody but at least when I started this, this was all new. So I think it's at least worth mentioning. Method is just a fancy way to say functions. It's something that you will call and will return you on something that you can give arguments to it. And properties, it's again, it's another fancy word for just saying a property is something,
07:01
an attribute that your object has. And it can change through times. I always think of properties like functions that you call without arguments, even though that is not true but that's a really mental model that I have. So the thing that make a divas object that you actually, that makes this really powerful
07:21
are the three interfaces that are at the beginning. The first interface is the one that we're gonna start using and it was the one that make possible to actually create a library, was the introspectable that allows you to, without knowing anything, accept the address on the object. This will give you all the information that you have to reconstruct the object and actually interface with it.
07:40
Peer and properties are things that are there and are really cool that we're not gonna touch really much but you can also use it. Okay, cool. So introspect. Introspect is a method of that interface that if you call it, you will get an XML representation of the object. And once you have an XML representation of the object, anyone who has lived through the 90s
08:02
knows that you can construct anything, right? Because SOAP did it, so why can we do it with divas? So in theory, that's all you need to do to work with it. So how do you call it? I'm getting ahead of myself because I'm using a systemd library. There's nothing in my talk so far that talks about systemd. I'm just talking about divas, but I'm getting ahead.
08:22
So basically, you call that method and then you will get something like this. That is the XML. And you see that it gives me interfaces, a list of interfaces. Inside you have properties that has the type that it will return. It has the type of, it has a real name that you will use as a unique identifier
08:40
for the property. And then you have methods. And methods can not take arguments or they can take arguments. And then you have arguments with the types and basically the direction. Is there in is arguments that you give. You also have like the return types that is eventually defined somewhere. So some implementation of divas also returns
09:03
the name of the argument. That is kind of useful. I mean, I would prefer that it were there, but if it's not there, it's not a big deal. So we now have a way to construct things. So when we were going to start building this library, we had to find underneath libraries that we wanted to use.
09:24
Again, I'm a Python developer, if you haven't noticed by the 100 times that I say Python. So I wanted to use divas Python because it has Python in it and it also has divas. It makes sense. The problem is that there is a binding to lib divas that is really old, that is basically written exactly like a month later
09:42
after the implementation of a specification of divas was written. So it doesn't have all the experience that we have now that this protocol is fully mature. And also the main author of this library said a disclaimer that says divas Python might not be the best divas binding for you to use.
10:01
So if the author says don't use it, then thank you. I will move on. Okay, the next one was pydivas, which also is based on gdivas, and it was a really good alternative that I wanted to use. But with that said, I spent a few times reading learner's blog and I find sdivas as part of the system,
10:22
the implementation. And this was actually the best thing that we wanted to use. So we wanted to create a library to win to systemd, not to link to divas. Divas was the protocol. And using this thing will basically give us the same way that systemd itself bins to divas and do everything.
10:40
And also it gives you a little way of cheat in the sense that I could just go to systemd and read the code and understand how to do it and then I could implement it on my script in Python and say hey, I create something, but no I didn't. For your language, if you want to do it, there's this page over here, there's some free desktop that has all the bindings for many languages.
11:00
You should go and, again, write this in Ruby. Have fun. Okay, so the great thing is that, okay, so we want to use sdivas. There's no Python library for sdivas. In fact, there's no Python library to win to leave systemd. I mean, there is not. There's few libraries. None of them did whatever we want.
11:21
So as all developers do, when they can't find something, they just build them themselves. So we at Facebook creative, pistond. pistond is a pun of words because it sounds like systemd, but also start with pi as every Python library should. So yeah, naming things is hard. This was easy, great. Other options were pid-uno, which basically is pid-1
11:44
but in Spanish, so yeah. We did it, yeah. Okay, so basically, we did it because we wanted to pin to sdivas, but we also want, now that we're pinning to systemd, we could pin to other libraries that were present, like std daemon, and do all the things that David had talked on his talk. That was really cool.
12:01
So how does this work? We basically Python this library, connect to the bus, get the information, and you generate classes. Nothing far of the ordinary. I'm pretty sure that everybody can come out in five minutes with code version of what this does. But here's the fun thing that you learn while you are translating, basically,
12:21
something that was written in C into Python, is that there are theisms or pythonisms that you need to translate from one language to another. For instance, in C, there is no propagation of exception. So you see this pattern all the time when you read code. You call to a method that returns x status and their side effects on the argument,
12:41
and then you need to check for the return status to get, sorry, you need to check for the x status to realize if you need to fail or continue. And then if this method is returned by another method, then that method also needs to check, and then there's this propagation that you have to explicitly do. In Python and other languages
13:01
where you do have exception propagation, all you need to do is check the x status of the first time that you call the command that actually has this behavior, and then you raise. And when you raise the exception, that will bubble up everywhere else. So if you want to stop when something fails, you don't do anything. You just let the application or the virtual VM does that for you.
13:21
If you do want to stop, sorry, if you don't want to stop then you just try accept your errors. So that's one cool thing that you get, and then you're gonna see this difference if you ever look to my code that I raise a lot instead of checking. And then I try accept a lot. The other thing is that systemd, at least from my point of view,
13:41
it's really written in a way that it looks like it, supposed to be object-oriented, but it's not because it's not. So you usually give this struct at the beginning of almost all calls. So this really lends to when you are translating this into a language that is object-oriented, like heavily object-oriented, you get into those things.
14:02
So you have a class Sdvas that should be, then you delete the first name, and then you just rename all the methods, and then they call self. The idea of doing this is that if somebody is used to write Python, this comes really natural. And if something is used to write C and wants to write these things, but in Python, because somebody asked him to,
14:24
it doesn't have to learn so much new things, it just needs to learn that it needs to replace Sdvas underscore with Sdvas and then a dot. That's not that big of a deal. So now how'd this look? It's basically you install as everything with pip install pistond, then you call it like that,
14:43
and it looks very simple. Like if you do org.free-desktop.systemd1, you will install, sorry, call it from pistond.python, and then you call the unit, and then you start the unit in this really Pythonic way where you don't have any information about how it is, and this will construct everything, and then you can start and stop it.
15:02
And this thing over here encodes the idea of the interface that is completely evaluated when you call for the first time unit. Now this is, again, you can do it, if you don't see, you can even do it and see there's nothing magic about this.
15:20
The great thing is that now for a Python developer or these developers that are high level, that they have never touched C and they also don't want to touch C, you give them a really nice interface to the stuff that they first didn't knew how to do, or that they will chill out and then do a really hacky and, let's face it, clowny way to get the output.
15:44
So these things are cool. Also, once you call this method that it basically automatically calculates the thing that it needs to replace, put it on the bus and everything, you also get the real return value of the thing that in this case will be a job. So then you can verify the job through the bus and everything, write nicely,
16:00
and then you don't have to do any experimentation. I think that I really think, I said that I really think that systemd was really good at making the decision of running divas. The other thing that I really think systemd does really good is giving you output or information about your service, and I'm preaching to the choir probably, but when you do systemctl status,
16:22
you get all this information. And sometimes you actually want this to do in your code, so you do the same thing and then you ask the main pith. And again, the main pith, you get it as an integer because this thing is typed. But then with systemd, ooh, fancy animations. Okay, so with systemd, you can actually do socket activation.
16:44
I mean, you don't do it with socket activation, but you read the information from socket activation when you just get the same headers that you would get with systemd. And you do socket from fd, and then now a Python developer, and maybe I'm telling them short, but that is used to do socket and then socket.list
17:03
and then socket.accept or bind. Now, in his own language, without changing anything, he can do the things. So that's the first part, and now let's talk about fun things that we can do. And a little disclaimer, everything that I'm gonna show you, you can already do it with systemd run
17:21
and then batch script and everything. I'm just showing you how you can do things that may not be the best way to do them, but again, you can do it from a high-levels perspective. So the first thing that I really like when I start working with systemd and the things, I really wanted to have this idea that I could decorate a method,
17:40
like for instance this ping over here, that it could be even like a normal call, and then I wanted to decorate and then just run this section of the code in a different secret or even in a different process. So I actually went on and did a few things. This will all be available on the systemd page, so it has repository.
18:02
Right now, they are not, because I write them only for this talk. So my idea was that I could decorate this method and then make this method run without any network access. The idea of this is that sometimes you have to run like non-secure code or code that users provide, so it will be a good idea
18:21
to just make this thing run on a different secret. And again, this is not the best way to do it, but it's an interesting way of doing it. So yeah, so this is how I solve it. I decorate that, and then what that will make, it will start a unit that is just a really big no-op. It has remain-after-exit true. I really know that you don't need to do this,
18:41
but I just put it as an example. So remain-after-exit true. So this will execute this, will not do anything, and they will stay there. And then you set the type one shot, you set the type delegate to true, and then you set the cgroup settings that you actually want to preserve. And then you start your settings, your method.
19:04
To start your method, I do a little trick that is the following. In a main process, I start this as a tile, I fork. The great thing about doing the fork is that I can still hold all the status, all the variables, and all the information that I have from the main process.
19:20
So if I declare a global variable, it's available to this method, but I start. I wait for this thing to actually start to have a bid, and then I call this little great thing that is called attach process to unit that basically will allow me to make this process, move them to this cgroup or to this other process. Yeah, assume that I said something that makes sense.
19:44
So then, this is what happened in the parent. And then in the children, I start the process, I wait for actually to change the unit and to be running on a different unit, and then I call the methods. What this will do is two things. The first thing is that I can call this,
20:02
and then when I try to ping, it will not allow me to ping. Even though my application does have this permission, by me changing to a different cgroup, it works. This is not the best way to do it, but it really works good for this. The other thing is that now, since this is working in a different process, you can literally just do systemctl status,
20:20
the other process, and then you will see this running. And then this give you all the informations that you want. So yeah, so this was one cool thing that we did. I think, okay, never mind. I'm assuming I still have time. So other thing that I have is that, just a raise of hand, because how many people here are Python developers or code in Python?
20:44
I love you all guys. Okay, so I'm not gonna purchase the choir. In Python, you have this idea of virtual environments, which allows you to basically set a similar but different environment that you have on your system with Python. So you can imagine that there's an analogous concept
21:02
to the idea of portable services, but having portable Python environment. So instead of you just shipping a whole system, like a whole distribution, thank you, like a whole distribution, you just ship like your Python code, you just ship the Python executable and delete Python.
21:21
And then through the magic of just setting up stuff, you can make it run in a way that is completely isolated from the Python that you have. And this is one example of how we do this, but for instance, you can just start a temporal file system, that's awesome, and then you just pin mount all the Python that you bring from your application,
21:41
you just mount it into this environment. So you can mount the, literally, the binary, and then you can mount whatever libraries you want to preserve, then you do a few configurations, and you run, and then it's a good way to actually create virtual environments on the fly in a systemd context, instead of doing virtual end.
22:03
So this was actually really cool. With this set, you can do the same thing, it doesn't have to be Python. One other thing that we have tried is that actually instead of doing this, it's bash. So we can actually make, when a developer, for instance, wants to try, they have their own settings that looks really similar to production,
22:21
but they actually want to try change interchanging libraries with the ones that they are developing, we change this to bash, and then the mounts just change the location where the library should go with the developer one, and it works really well. The good thing is that this works in the context of the process, and then when you exit the process, it goes out.
22:40
And again, the magic here is that you create ptys, and then you've been stdin, stdout. This is the last example that I will give, and I think with this, I will be running out of time, and I think I really want to have questions at the end. So one typical thing that we usually do as infrastructure people is that we need to,
23:02
for instance, we have to decommission a whole rack of machines. So for that, if these are databases, you usually need to drain them, then take the data, put it somewhere else, and run it. And the first time that you do this, you create a batch script. You SSH from a scheduler, you execute that batch script, but then that batch blocks. So you block the thing, and then you don't,
23:20
you cannot actually run more than a few because you don't have resources to run them. So the first thing that developers do, and I've been guilty of this, is that they say, oh, so I'm gonna create a service that is gonna be listening, and then it's, when it gets a call, I'm gonna sub-process something, create it, and then this is gonna start working, and then I'm gonna monitoring what it's doing,
23:40
and when it's finished, I'm gonna call back the main process. And every time that I hit that, it's like, that's a service manager. Why would you call that if you already are running in Linux with a service manager? So a good way to do that is that instead of doing that, just write your same shell script that you have, do a little bit, do a little more interesting stuff,
24:00
but literally just run it as a transient unit. So like, this could be like a normal unit, and then you just start it, but if you want to create this file on the fly and do all those stuff, you could literally just create as a transient unit. You give all the attributes that you want, you can put limitation into your script,
24:21
change the user, and the good thing is that you should always try to use notify when it's possible. The reason why, well, so this is non-blocking, and then you just return the name of the unit that you created, and then you just monitor that unit. Now, how do you monitor that unit? One thing that you could do, and it's not really useful,
24:40
but then you could just, like, notify. So notify, you say ready equals one, it gives you, like, the status, but what if you can put text into it? And you can, like, YouTube, like, don't overuse this, but, like, in your backup script, you go through your backups, and then every time that you make a change, you change the status. If you do that, then if you run,
25:01
if you monitor your service through normal tools, you will always see the change that you did. Then you can actually get it from the text, but that means that your scheduler, what it can do, it can always kind of go and connect to that particular unit and then retrieve the status text. And this is useful when you create interfaces,
25:22
like human interfaces. Like, you allow the script that is doing the backup to communicate how it's doing the things. That way you can read it. That's mainly it. I will not touch that one. Ask me later if you want to do that. Final thing is that binding to be, sorry, binding to leave system this fun,
25:41
you should all do it, find a language that doesn't have a binding, do it yourself. And that's it. So, thank you, and questions. I have one minute, so at least one question or none.
26:00
Go for it. So, I have two questions. The first one is, you showed before that there is some auto-generated code out of the DBOS introspection stuff. When is that happening, like at build time? So, in my library, you can do whatever you want. You're free to write your library, whatever you want.
26:21
It's here. You create the object, and this with in Python world, it's execute a method that is called enter. And that method enter, you get, go to system, go to the library, sorry, go to system, go to Veevas, go to the instructions back method, gets XML, construct the object, and then you return the object that you constructed.
26:42
The only, the good thing is that these interfaces are really stable, and you only need to do this once. We don't do it, we do it every time that you create an object, but you only need to do that once. Okay, and the second question was like, if I'm not wrong, there are a few function, library function that are asynchronous already in systemd.
27:02
Oh, yes. How do you, and that one is like its own loop, I think. It's like, how do you bridge with the Python asynchronous stuff? So I don't, but I will. So yes, that's the one. So the first thing that I create this library, I create it with the specific intention that Python 2 has to be supported,
27:20
which everybody in the Python world hate me for. And Python 2 doesn't support asyncio out of the box. So now that we're moving into Python 3 world, it's like, I will do asyncio and I will make this library completely async, if you want to. Like, it's not, cool. You're welcome.
27:41
Cool, gentleman in the front that I have never seen. On that slide right there, what is replace? Oh, so that is basically like the start and the stop method. They, this is like systemd from yourself, so I can't give you the better answer than that.
28:02
But they take arguments on how you want to start, like how do you want the manager to actually start or stop your service. And the most stable one is replace, go ahead. It's basically if you start a service and this contradicts with another operation that has been queued before, what shall happen? Shall the new operation replace the older ones
28:21
or shall the new one fail or something like that? So I want before, if you have a question before you ask it, I want to say like, this actually was one of the coolest thing about working in this type of library, is that you get to learn, quote unquote, how these things actually work, how the stuff that is made because you get to, like I call this method, doesn't have arguments, like what?
28:42
And then you say like, oh, there's all these options. There's like three options, I believe, go ahead. My question was regarding like, if you go, yeah, on this slide here, like you're saying that the introspection happens at the time that the object is allocated, right? Yeah. So this works for any device service? Yes, literally, so it. How would that look like if I, let's say,
29:01
talked to, I don't know, network manager or? Oh yeah, so I don't have example for this, so let me see if I can get this one. So basically, this is how the magic work. You, like I have, sorry, okay, so this one, it's like a custom object made understand
29:20
that it's the concept of unit, but I have an object where this inherit from that basically allows you to specify any service and any object. When you read that object and you see the XML, I understand that everything that, like if it is r.free.login.1,
29:41
I understand that every interface that start with that, it's like an interface proper of the object, so I exposed it like the thing as a proper attribute. So then you have like your object that you created that you need for the user would be this one, and then you will see it, like it works like that, and then the method works. And the other one that has different names, they are not exposed as separate attributes,
30:02
but you can always like get interface and then give the proper name, and then they will have it. So what's the work then, then let's say, if I wanna talk to network manager or any other DBOS interface, what would I do? I would first subclass this generic object thing, fill like a handful in of things, and then that's it, right?
30:21
The rest happens automatically. Yes, exactly. But in general, like you don't even have to subclass it because the base class, like it work on its own. You have to subclass it like to make like future calls, not necessarily to actually give the name, but you will literally just, if you want to talk, for instance, I do this a lot, like with machine one, you give this one, and then you give the object
30:40
that would probably be either the machine manager or the machine itself. And then like you say, everything works like right off the box, except for stuff like time date, which are like really small, and they don't really confirm this logic. We can talk about that later, but for things like machine CTL or login,
31:01
which are like really big classes, and they work exactly like system D1, perfect. Okay, sounds great. I'm glad you like it. I don't know if I have time for more questions. I don't have time for more questions, but.