LF Edge Working Group 2: Okay, looks like we're recording, so we're a couple minutes after. So let me get started with the meeting. So first of all, let me thank you all for coming.
LF Edge Working Group 2: Need to grab a participant list here so I can see you all is coming
LF Edge Working Group 2: So this is the first meeting of the open horizon agent workgroup as reconstituted under the Linux Foundation. So when I thank you all for joining today. My name is Dave booze.
LF Edge Working Group 2: I'm the chief architect in IBM for the product that consumes open horizon, the product is called IBM edge application manager we consume open horizon in its entirety and add some extra stuff to it.
LF Edge Working Group 2: I was one of the original creators of this project, five or maybe six years ago now. So I'm happy to get this now into LF edge and part of Linux Foundation and and to get this kicked off.
LF Edge Working Group 2: So I'm showing you the antitrust policy. Notice I assume you're all aware of this and have all read it.
LF Edge Working Group 2: So with that, and then you been looking at it while I was talking. So with that, let me just get started here. So I know we have a number of people on the phone. I'm going to be bold and ask
LF Edge Working Group 2: If each one of you wouldn't mind introducing yourself, give us an idea of why you're here today, what your interest might be
LF Edge Working Group 2: And then I'll get into the rest of the agenda. So Dave, Martin. Why don't you go first.
dcmartin: Hi David Martin.
dcmartin: Former IBM or utilizing open arise as a
dcmartin: Warm emotion.
LF Edge Working Group 2: Thanks, Dave. Joe
Joe Pearson (IBM): Found the mute button. Hi Joe Pearson been with IBM a little while I'm pitching in and helping out with the open horizon project, trying to make it easy for the team that builds this product to get other people to
Joe Pearson (IBM): Help out and build a community.
LF Edge Working Group 2: Okay.
LF Edge Working Group 2: Thanks, Joe.
LF Edge Working Group 2: Bling. I saw you you jump in. Do you want to give us a quick intro
Ling Gao: Oh hi my name's link out. I'm a developer for the open horizon. I'm just want to see what's going on here.
LF Edge Working Group 2: What link has been with us since the very beginning of this last five or six years, so there's there's any bit of this project that I don't know. She knows it.
LF Edge Working Group 2: Sure is. You want to go next.
Charisse Lu (IBM): Hi, I'm sure he slew also with IBM started to use the open hearts and project. So I'm looking to see how I can help and contribute and maybe do some more support. Yeah.
LF Edge Working Group 2: Great to have you aboard to reach. Thank you very much and Christina want to pick on you last
Christina Li: Hi, my name is Christina Lee. I am a CS students don't call our gym I joined the team this summer and as an outside contributor
LF Edge Working Group 2: Yeah and we appreciate all the work you've done so far then outstanding. So thank you for joining us to okay I put together. Let's see how this is going to go. I put together a quick
LF Edge Working Group 2: Mission statement for the group because that seems to be a thing that that we do. So here's, here's our mission statement.
LF Edge Working Group 2: We can we can amend this anytime we want. Let me just read it agent working group exists to enable development of the open horizon platform by providing an agent that can deploy containers at scale.
LF Edge Working Group 2: Within the context of edge computing and providing various Linux distributions and packages for the agent itself.
LF Edge Working Group 2: So that I think is our primary purpose of this work group is to progress this agent technology, but there are going to be related technologies, the agent doesn't work alone. It doesn't work independently.
LF Edge Working Group 2: It needs some other pieces if we want to adjust this mission statement in the future. I'll put it on the agenda.
LF Edge Working Group 2: But for now, that's our mission. Our focus here is on the agent piece and as well as there's a couple of pieces in the management hub that will also own I'll get I'll get to that later.
LF Edge Working Group 2: Okay.
LF Edge Working Group 2: Whoops. So in terms of participation, when I switch windows. Is it is the screen share following me.
LF Edge Working Group 2: Joe. If I click on or someone if I click on roles and responsibilities here is screen share jump into the wiki.
LF Edge Working Group 2: Or is that I'm doing. Then just see the PowerPoint.
LF Edge Working Group 2: It's not, is it possible to share entire screen. Do you know
Joe Pearson (IBM): Yeah, absolutely.
dcmartin: Posting the links in the chat.
LF Edge Working Group 2: Yeah, let me, let me see if I can get the screen share to work my entire screen here.
Joe Pearson (IBM): And DCM thanks for posting the links the those links persist afterwards in the transcript. So that's very helpful.
LF Edge Working Group 2: Yeah, it is.
LF Edge Working Group 2: OK, so
LF Edge Working Group 2: Right. So I want to talk. So if I'm switching windows. Is it is it tracking me now.
LF Edge Working Group 2: Yes, yeah. Okay, that's great. So let's talk about roles and responsibilities, a little bit.
LF Edge Working Group 2: Just so we can just so I can level set
LF Edge Working Group 2: Everyone on this. So in the elf edge.
LF Edge Working Group 2: wiki here.
LF Edge Working Group 2: Is the wiki that describes the open horizon project itself. There's a technical charter here. This is of interest. I think so that we can get a context of what's going on. The, the overall
LF Edge Working Group 2: Linux Foundation injection point for us is what's called the technical steering committee, we haven't yet elected a chair of that committee, although there is one that I'm aware of. Only one nomination outstanding for who that is.
LF Edge Working Group 2: And his name rhymes with mo. So hopefully we'll get that chair position filled. Pretty soon that chair is responsible for overlooking several working groups agent is one. There are several other working groups that that we have
LF Edge Working Group 2: Available. There's the management hub there's examples. There's documentation, probably a couple other that I'm forgetting. There's a QA testing one there's Community interest outreach one
LF Edge Working Group 2: Each one of those work groups is is comprised of different kinds of users and this page really outlines what that is. Most of us in this call are going to be contributors or maintainer.
LF Edge Working Group 2: Possibly users. And at some point, we may get some partners. We don't have any of those on the on the call today. So for the most part we're talking about contributors and maintainer.
LF Edge Working Group 2: People that are working with the code directly and will be interacting with each other. So, so I think that puts us all on a relatively level playing field. I'm going to continue to chair this agent work group for the for the foreseeable future.
LF Edge Working Group 2: So I'll be
LF Edge Working Group 2: I'll be involved quite a bit from that perspective. Let's see.
LF Edge Working Group 2: What else we have here.
LF Edge Working Group 2: I think go through all these pages ahead of time. So we do have some some governance, how does our workgroup fit in. How is the whole project governed and what this wiki page described is
LF Edge Working Group 2: Is how that governance happens again, it's all originates from the the technical steering committee that sits above us.
LF Edge Working Group 2: We want an open environment where, you know, just about anything can be discussed and you know this is open in public. So anything that can be discussed publicly is is appropriate. Here we want people to be able to work in a way that is most suitable to them.
LF Edge Working Group 2: being transparent with each other and and for the best of our ability. Being able to work together to produce the best possible code that we can
LF Edge Working Group 2: Going to have disagreements along the way. And so, you know, expect that we'll try to work those out through series of meetings and and discussions. But most of all, we try and get this group to be as open and transparent with each other as possible.
LF Edge Working Group 2: And if it comes down to it, you know, there were certain ways that you know if we have if we have decisions. We can't make
LF Edge Working Group 2: Can't seem to reach agreements through discussion, we do have
LF Edge Working Group 2: Escalation possibilities, but hopefully we'll never get never need to get to any of that. So,
LF Edge Working Group 2: Okay, so that's just a little bit about governance.
LF Edge Working Group 2: There's some information on the elephant wiki on how to get started. Again, Joe put together some real brief information here.
LF Edge Working Group 2: We can talk, especially with respect to the agent. We can talk in the future about how to get started with the code itself.
LF Edge Working Group 2: How to Check it out, how to test it. What is the PR process, the way things are set up right now PR are going to be reviewed and approved by me and possibly by LNG as well.
LF Edge Working Group 2: We'll see how that goes. And as people contribute and, you know, and show proficiency with the code and with with our process, then we can elevate people to
LF Edge Working Group 2: You know, to having that sort of
LF Edge Working Group 2: Responsibility as well for approving emerging P ours. But for now, that's that's with me in length.
LF Edge Working Group 2: Okay, so a lot of boring stuff. Most of you may already know. We're just going to do a couple more administrative things here case anyone, doesn't know.
LF Edge Working Group 2: This is where the code base is we're talking about the annex project. If I look at open horizon.
LF Edge Working Group 2: As a whole, there's a number of repositories here. There's probably half a dozen or so that are really important.
LF Edge Working Group 2: The annex repository is the one we're talking about for annex or for the agent. This is where the agent source code lives. It is a very
LF Edge Working Group 2: Large project. As you can see, paging down. There's lots of needs in terms of documentation. There's lots of the technical things that we can discuss, but it's a very complex project, I can take you through some details of what's in the project.
LF Edge Working Group 2: At a future point in time, but for now.
LF Edge Working Group 2: And x is the repo that we're mostly concerned with
LF Edge Working Group 2: And we can talk about some of this other stuff later.
LF Edge Working Group 2: All right. There is also we'll see if this works is then Hub has been acting weird for me lately. There is a Zen hub board for the project that shows lots of stuff in progress.
LF Edge Working Group 2: Lots of lots of work that's going on. Obviously on the IBM side. I'll just filter this down to, you know, stuff that I'm working on right now, just to give you an example. You know, this is typical, typical Zen hub process issues come in, they get triage, they get assigned to people's backlogs
LF Edge Working Group 2: You pull stuff out of your backlog as you get ability and time to work on it, put it in progress. When you're ready for review. It moves to review QA and we'll look at your PR and you'll notice that PRS are attached to issues so that we know you know what code goes with what issue.
LF Edge Working Group 2: You'll see us.
LF Edge Working Group 2: You know, as a best practice. Try to document everything you can about the issue. There's a number of labels we use in here to indicate things indicate status and facts about these issues as they go through
LF Edge Working Group 2: Don't worry about too much of this at first, we'll, we'll work through this together. And we'll learn. How's the best way to work but so here's the Zen hub again link to from from the PowerPoint. So
LF Edge Working Group 2: That's some opening administer trivia stuff. Does anybody have any questions about this or any comments they want to make at this point.
dcmartin: This is David Martin. The only thing that I don't see
dcmartin: Articulate here is any type of attributes of the architecture of the agent, as it relates to exchange.
LF Edge Working Group 2: And can you be more
dcmartin: Well, what specifically I have an outstanding issue, which is that Docker runtime is a dependency for my container distribution.
dcmartin: Yep. Right. You don't have the right doctor runtime container.
LF Edge Working Group 2: Right.
dcmartin: I've come up with a workaround for that, but I don't think it's clean of an architecture.
LF Edge Working Group 2: Okay.
LF Edge Working Group 2: So that's that sounds to me like an issue that you can open and that we could work on
LF Edge Working Group 2: Through this work group.
dcmartin: Okay.
LF Edge Working Group 2: That would be my first knee jerk reaction. So what I was planning to do the rest of the day today. Dave was to talk about was the rest of these slides are some technical details about how the agent fits in.
LF Edge Working Group 2: What it looks like what some of the main concepts are within the system only got about five slides I could talk to these slides for hours, but I'm going to try to keep it to a half an hour.
LF Edge Working Group 2: To try and give everyone a little bit of an overview of that and I think
LF Edge Working Group 2: I think that sounds relevant to to part of the discussion here so we can talk about what's part of the architecture and what is part of the implementation is they aren't necessarily the same thing.
LF Edge Working Group 2: All right, any, any other questions about the minister via or how we're going to operate, we are meeting every other Monday.
LF Edge Working Group 2: If we find that we need to meet once a week. I'm certainly open to that possibility if we have enough activity and we need some more face to face communication. I'm open to that.
LF Edge Working Group 2: But I'll you know we'll do, we'll decide that, as a group, if we need to.
LF Edge Working Group 2: Alright then, let me let me move forward. So I'm going to spend. I wanted to spend about maybe a half an hour going over what open horizon is from a technical perspective, just
LF Edge Working Group 2: To give everybody
LF Edge Working Group 2: A common context, we need to put the agent in context of everything else that's happening. Some of you know this already. Some of you might need a refresher.
LF Edge Working Group 2: And for some of you, maybe this is, you know, maybe it's the first time you're seeing this. So let me, let me start with this technical technical architecture overview. So this is a this is a physical look at the way that open horizon.
LF Edge Working Group 2: But all the pieces of open are all the pieces that make up a complete open horizon installation or configuration.
LF Edge Working Group 2: There are, there's something we call the management hub at the top of the screen at the bottom of the screen is what we call the agent.
LF Edge Working Group 2: So you remember the mission here. The mission is about how do I deploy containers to an Edge device that may not actually be a piece of it equipment. Maybe it's a camera. Maybe it's a robot. Maybe it is it a server.
LF Edge Working Group 2: But it could be anything with Compute capability on it. So the purpose of the management hub is to provide the central
LF Edge Working Group 2: Foundation, which can manage all of these Edge devices, the agent is going to be running on the Edge devices. Now, we use the term node to indicate any sort of a compute capable thing that can support the agent.
LF Edge Working Group 2: Agents are installed as an extension to the operating system. So on an Ubuntu or a Debian based system, you would install the dead packages.
LF Edge Working Group 2: To install the agent on to that system those dead packages are built by the annex repo, the code to build those has been slowly moving into the annex repo.
LF Edge Working Group 2: To make it more accessible for everyone.
LF Edge Working Group 2: If you were going to install the agent on a on a rail or an RPM based operating system, you would you would build the RPM and and have the RPM installed.
LF Edge Working Group 2: There are install scripts in the annex project that will help you install those Deb's and RPM. If you're, you know, if you want a little bit easier. Install experience.
LF Edge Working Group 2: You need to you. All you do in that case is gather up some information about the management hub provide it to the install script and the agent will be installed in that case.
LF Edge Working Group 2: So,
LF Edge Working Group 2: So that, so the agent, a very small piece of software 25 megabytes binary roughly in size, it has a local database inside of it. It is a memory mapped database.
LF Edge Working Group 2: We assume that the agent is running as root. Like I said, as an extension of the operating system. It does some authorized activities.
LF Edge Working Group 2: Like communicating with Docker, for example, but it also is keeping track of some security information and other things that need to be protected.
LF Edge Working Group 2: All that stuff lives in the you know the little green database looking thing that I have there in the picture. So it's a, you know, it's a root protected file system. It's got local database. So it is staple the agent itself is staple
LF Edge Working Group 2: It can be stopped and restarted on an Ubuntu system or any system that supports system D.
LF Edge Working Group 2: We will install this thing as a system, the service. And so you can use those Linux commands to start and stop the agent, it can tolerate being stopped and restarted and it'll pick up from where it was before because of the
LF Edge Working Group 2: The local database storage that it that it maintains
LF Edge Working Group 2: Now, all of that about the agent is, you know, from from an agent and from this workers perspective, interesting, but it doesn't do anything without the management hub at the top of the picture. So what you see in the management. How about there.
LF Edge Working Group 2: Is is three or four components, depending on how you want to look at. I want you to ignore the SEO component for a moment.
LF Edge Working Group 2: That's because I want to come back around again to how that how that SEO component is going to help us as as agent.
LF Edge Working Group 2: Work Group, folks. So in the open horizon architecture, the exchange is an API server, it's a REST API server, it holds all the state of the system with respect to the
LF Edge Working Group 2: Definitions and the metadata that describe what the system is supposed to do. So what you'll see in the exchange our users are defined their
LF Edge Working Group 2: Services are define their services refer to containers that are going to be deployed on an edge node.
LF Edge Working Group 2: So their services defined there there's policies defined, they're all of the nodes are defined in the exchange and all the policies related to those nodes. So, any, any sort of concept or object.
LF Edge Working Group 2: In the most abstract sense that you can think of that defined something about the system those resources, you'll all find in the exchange behind the REST API server in the exchange component
LF Edge Working Group 2: That exchange is built from a different repo in open horizon and in the exchange API repo.
LF Edge Working Group 2: It's not written in goats are written in Java.
LF Edge Working Group 2: Sitting on top of a couple of other frameworks to make it fast.
LF Edge Working Group 2: There is a different work groups knowledge worker work group that is responsible for that exchange. So as you can imagine the agent spends a lot of time talking to the exchange.
LF Edge Working Group 2: users spend a lot of time interacting with the exchange through the COI the command line interface that we that we provide. You'll notice
LF Edge Working Group 2: That the agent project right our working group actually also contains the open horizon command line interface. So, so this is one of those one of those places in the code where we have a direct relationship, not just from the agent, but we also provide the COI for the exchange.
LF Edge Working Group 2: That's not actually part of the exchange project that's actually in the agent project. And there's a couple of reasons for that, but I'm going to those now.
LF Edge Working Group 2: It seems a state for has a Postgres database behind it. As you would imagine to hold all its resources.
LF Edge Working Group 2: Now, the next the next piece here in the list is the the CSS the CSS and E SS or a pair, you'll see the E SS component down in the agent. I'm going to skip that for just a moment.
LF Edge Working Group 2: And I'm going to come back to it in a moment. The third component is this thing that we call an ag bought and this is really central to how containers are deployed to the edge.
LF Edge Working Group 2: You'll notice that there's a little tiny API on the ag bot, but nobody uses it. And that's currently true the ag bot is really just another client.
LF Edge Working Group 2: It's a lot like the agent. And in fact, it's the same code base.
LF Edge Working Group 2: So this agent work group that we are all in now is actually also responsible for the ag bought we're responsible for that egg bought component, even though it lives up in the management hub, we're responsible for it. It's the same code the ag bought in the agent.
LF Edge Working Group 2: Coordinate with each other to figure out what containers should be deployed on what nodes that that's the essential nature of their relationship.
LF Edge Working Group 2: The AG. But does this by querying the exchange to find out what Edge nodes are in the system what Edge nodes have been registered and connected to the management hub.
LF Edge Working Group 2: What policies and patterns have been defined by the users, what services. There are available to deploy the iRobot is aware of everything that the exchange nodes. He
LF Edge Working Group 2: The ag bot will process all of this information, figure out which nodes should be running which services and then it will send messages to the agent through the exchange as a way of telling the agent, what to do.
LF Edge Working Group 2: What services should you be running. What's the configuration of those services.
LF Edge Working Group 2: And the reason that the ag BOT does this communication through the exchange is because the agent and this is really, really important from an architectural perspective.
LF Edge Working Group 2: The agent has no listening ports that that it can listen to off the box right there are no remote ports into the agent and that's by design.
LF Edge Working Group 2: You can't attack a network address that you can't reach. And so that's the reason. So the agent effectively has no external API to it. And that is by design.
LF Edge Working Group 2: The agent figures out what to do by reaching up to the exchange into what we call the switchboard
LF Edge Working Group 2: Where all of the agents messages live. So if an agent doesn't have connectivity to its management hub, it can't get any messages and that's okay. An agent is expected to run without network connectivity for some period of time, it will just continue to do what it was last told to do.
LF Edge Working Group 2: It will, you know, on a periodic basis, reach up to the exchange look for messages that have been sent to it by the ag bot, and then react to those messages, one way or another.
LF Edge Working Group 2: It's a whole nother topic to talk about the protocol. The Message Protocol that exists between the ag bought in the agent. There's a whole agreement protocol.
LF Edge Working Group 2: Where the ag by than the agent come to an agreement on what to actually deploy into the system. There's a couple of packages in the annex repo that describe the protocol and some extensions to the protocol that's actually an extensive ability point within the source code itself.
LF Edge Working Group 2: So there's that. So that's what the I bought does
LF Edge Working Group 2: Now the CSS in the SS in the middle. I said, we'll come back to this. There's a parallel keep a piece of capability in the system.
LF Edge Working Group 2: With which the agent participates called the model management system that the model management system can be broken down into two pieces, the CSS and the E SS the responsibility of the model management system is to deliver
LF Edge Working Group 2: machine learning models.
LF Edge Working Group 2: From the management hub to whatever Edge nodes need those models. One of the really important use cases for open horizon is not just the ability to deploy containers to an edge node.
LF Edge Working Group 2: So that it can so that we can do analysis of data right on the node, but that analysis might involve machine learning.
LF Edge Working Group 2: Machine learning algorithms are basically metadata driven applications and the metadata that drives a machine learning app is this thing called a model.
LF Edge Working Group 2: These things can be 50 megabytes to 50 gigabytes probably depending on what it's doing. It can be very, very large. The, the thing to know about this. The most important thing to know about this with respect to open horizon is that
LF Edge Working Group 2: In the machine learning world those machine learning models are continually being retrained
LF Edge Working Group 2: In order to get in order to correct the models in order to remove bias or in order to compensate for something else that's happening in the data streams that you're analyzing
LF Edge Working Group 2: So recognizing that these models change more often than the code that's using the model suggests that the code that's using the model has a different life cycle than the model itself and that is why we have the model management system. It's a parallel deployment mechanism.
LF Edge Working Group 2: To the container deployment mechanism. So the ag bot and the agent work together with the exchange to figure out what containers should be running on what Edge nodes.
LF Edge Working Group 2: DAG doesn't exactly exact same thing with these machine learning models. This this metadata that's given to the CSS the ag bot works with the CSS to figure out what are all the models.
LF Edge Working Group 2: You know what services.
LF Edge Working Group 2: Do they do these models belong to
LF Edge Working Group 2: And let me make sure that the right agents have those models to the agent will be told, you know, here's a model that you should have one of your service needs it.
LF Edge Working Group 2: The agent will download that model that's the SS piece will store that model in route protected storage in the agent.
LF Edge Working Group 2: And make that model available to whatever services are running on the agent that that are allowed to have access to it.
LF Edge Working Group 2: We can restrict what what services can see what models. You know what containers can see on the agent. So you can have services.
LF Edge Working Group 2: containers running on an edge node that are not able to see some of the machine learning models. That's important.
LF Edge Working Group 2: From a proprietary just second date for important from proprietary perspective because models are often
LF Edge Working Group 2: Cut off and Miss sometimes be considered trade secrets and so you don't necessarily want every container to be able to see every model, especially if the containers are coming from different parties to go ahead, Dave.
dcmartin: Is this a change in functionality for the agent to recognize us as objects as first class model objects.
LF Edge Working Group 2: Is this a change, not from what you're
LF Edge Working Group 2: What you've seen in the past. I don't think
dcmartin: Okay. Okay, perfect.
LF Edge Working Group 2: Right, this is, this is the same MMS that I think you worked with a couple months back.
dcmartin: And my question was around the agent. I know what the SMS MMS whatever you want to call it that combination does I've been using that
dcmartin: Yep. Right. I just want to ask you if there was enhancements to the agent that I was aware of that might provide an abstraction layer above the SS that would find a first class object called a model that would be part and parcel of maybe policy definition or a service specification
LF Edge Working Group 2: Yeah okay let me, let me turn it around and let me answer your question. And let me turn it around a little bit and I think
LF Edge Working Group 2: So to two part answer to your question one. Um, you know if there's interest. I will do a policy overview of all of the aspects of policy that relate to the agent in a future worker, but that's interesting to folks.
LF Edge Working Group 2: And it may be after I give this second answer. So the second half. I want to say is, yes, there is the notion of a first class object that is deployed.
LF Edge Working Group 2: To agents just like containers are deployed there those objects can be assigned what services they belong to.
LF Edge Working Group 2: Those objects can also be assigned policy that determine what nodes may be eligible or ineligible for that object. So
LF Edge Working Group 2: While I talked about the use case for machine learning and the point machine learning models really what this system does it's it's really just a generic metadata delivery system. The
dcmartin: Object hasn't. That hasn't changed or
LF Edge Working Group 2: Not
LF Edge Working Group 2: That is not changed, right. This is a generic object delivery system so that can be used in any way you want. But we named it for machine learning, because that's the primary use case. But any metadata driven app can use this this
LF Edge Working Group 2: You know, and it will work with the same policy deployment mechanisms as containers so
LF Edge Working Group 2: I think that's consistent with probably what you already knew.
dcmartin: That's what I already know.
LF Edge Working Group 2: Yep. Okay. All right, good.
dcmartin: So I don't know if that's something that we look at in terms of an issue again to go back to the question, because I opened up one on AX as we discuss. But what if we were to propose a first class object agent provided a model abstraction.
LF Edge Working Group 2: Yeah, I think.
dcmartin: I think we would propose in this forum.
LF Edge Working Group 2: Yeah, I think so. I think you could. I think you could propose that here and we can discuss it, you know, work through the design and what it means. And I think this is the forum in which to do that.
dcmartin: Perfect.
LF Edge Working Group 2: Okay.
LF Edge Working Group 2: All right, I've got
LF Edge Working Group 2: 10 minutes on my self imposed time limit here, I might go
LF Edge Working Group 2: So let me try to finish up on this slide. So I can move on.
LF Edge Working Group 2: Over on the right side of the slide is this thing called SEO. This is a relatively new.
LF Edge Working Group 2: piece of functionality that we've delivered into the system. And again, it's relevant to the agent in so far as the purpose of SEO is to get an agent on to a note.
LF Edge Working Group 2: So, you heard me talking to beginning of this about your part of the agent workgroup includes the code that builds packages like Deb's and RPM. To install the agent itself.
LF Edge Working Group 2: What that means, though, is it somebody has to manually go to the node and actually run a script to install the agent itself.
LF Edge Working Group 2: From that point on, you should never have to touch the node.
LF Edge Working Group 2: Again, but you did have to touch it initially to get it set up and get those packages installed.
LF Edge Working Group 2: What if weird, there was a way where we didn't ever have to touch the node where the node could come online and figure out on its own, that it needs to have an agent installed on it and have that done automatically. That's the goal of SEO.
LF Edge Working Group 2: SEO stands for secure device onboarding. This is a standard that was proposed by Intel and is now being implemented in open source and is also part of LF edge.
LF Edge Working Group 2: So SEO is a sister project for us within the Linux Foundation open horizon has adopted SDO as part of its edge management hub as the way for device manufacturers to indicate
LF Edge Working Group 2: That a device is associated with a particular voucher a voucher gets imported into the management hub.
LF Edge Working Group 2: The men as soon as the device comes up it figures out where that voucher is and eventually the agent gets downloaded.
LF Edge Working Group 2: Now I just simplified a very complex and highly secure process down into about three sentences or be that's basically what it does.
LF Edge Working Group 2: We can go into a lot more detail. And in the future, about what it does, but that's the purpose. The purpose would be for a device manufacturer
LF Edge Working Group 2: To provide a piece of authenticating information like a like a voucher that comes with a device, a customer buys the device turns it on
LF Edge Working Group 2: And it automatically gets connected into the edge management hub through this bootstrapping mechanism that St. Joe provides so that gives us the ability to do zero touch onboarding of Edge nodes. And that's an that's a
LF Edge Working Group 2: Again, a really important use case for us.
LF Edge Working Group 2: Because Edge nodes.
LF Edge Working Group 2: We expect those to be remotely accessible. As in, you know, it won't be often that a human goes to touch the thing
LF Edge Working Group 2: You know, nobody's going to climb up on a ladder to mess around with the with the with a camera when they need to
LF Edge Working Group 2: Update the software that stuff should happen.
LF Edge Working Group 2: Remotely so so that's what SEO is about and that's how it fits in with our agent.
LF Edge Working Group 2: So let me switch me switch second slide now so
LF Edge Working Group 2: Again, our mission statement was about deploying
Karan Bal: Containers.
LF Edge Working Group 2: To the edge to edge nodes. This is a picture of the concepts and sort of how this happens from a conceptual perspective.
LF Edge Working Group 2: three columns in this picture on the left is a device in the center is something called an edge cluster that we haven't talked about yet.
LF Edge Working Group 2: And over on the right is the management hub that that we've that we saw on the previous slide. So let's start over on the right, so we've got our management hub over there. Look at this. I love what what sometimes PowerPoint does to you.
Two concepts.
LF Edge Working Group 2: Over on the right into management, there's, you know, a dozen concepts in the management have that we need to understand, let me introduce just two of them initially here. So the first one is this thing called a service definition.
LF Edge Working Group 2: Service definition is
LF Edge Working Group 2: A description of what containers to deploy.
LF Edge Working Group 2: What, what do I want to call these containers. When I deploy them sort of like what's the name of the service what hardware architecture, does it run on what version.
LF Edge Working Group 2: Is the service. What are the containers. You want me to run. What's the configuration of those containers. All of that stuff is all wrapped up in
LF Edge Working Group 2: What we call a service definition. So you have to create one of these service definitions as part of wrapping your containers.
LF Edge Working Group 2: For open horizon to
LF Edge Working Group 2: deploy them.
LF Edge Working Group 2: But that's not enough to get it to be deployed. That's what the agent needs the agent needs that
LF Edge Working Group 2: Service definition to figure out
LF Edge Working Group 2: How to run and configure those containers, the management hub needs.
LF Edge Working Group 2: Some something to tell it what to deploy.
LF Edge Working Group 2: And what I've described here is the second thing called a deployment policy.
LF Edge Working Group 2: The job of a deployment policy is to tell
LF Edge Working Group 2: The
LF Edge Working Group 2: AG bot. Remember that's code we own
LF Edge Working Group 2: In this work group.
LF Edge Working Group 2: Is to tell the ag bot what service should I deploy and where should I deploy it, and it does that through as a policy mechanism that
LF Edge Working Group 2: I'll show you very briefly in a couple of slides. Right. So those are the two things, a service definition what to deploy.
LF Edge Working Group 2: Deployment policy, how and where to deploy it. So once you have those two things you can get something deployed. So let's go over to the device on the left side. So you've got to this device. It could be a VM could be anything, right, running
LF Edge Working Group 2: Linux, it's got the agent running on it.
LF Edge Working Group 2: It has some policy that I'll get into in a moment that describes a little bit about that device.
LF Edge Working Group 2: That device will register itself with the management hub and once it's registered the ag bot can using deployment policies, find that node so
LF Edge Working Group 2: So he does that, you know, very briefly here in this one simple arrow that says up okay he's found the device. I've deployed the the service to the edge the edge service. One is now running on the device magic happened.
LF Edge Working Group 2: There's a lot of details under the covers that make that happen. But that's the, you know, conceptual
LF Edge Working Group 2: Abstraction of how this works. Now edge clusters. Let's talk about edge clusters, we've been talking about Edge devices Edge devices are
LF Edge Working Group 2: Usually a single operating system thing embedded in something else. It's an operating system embedded in something else. Or maybe it's a standalone virtual machine, something like that. And it's cluster is also very interesting. There are use cases where
LF Edge Working Group 2: In the open horizon context here there are use cases where it's interesting to have more processing capability that has more
LF Edge Working Group 2: More feature function in it. So something like a set of servers that can be configured into a cooper daddy's cluster. And that's what we're talking about in the center column here a cooper daddy's cluster.
LF Edge Working Group 2: That has one or more worker nodes one or more machines, providing container runtime capability you you will find things like this small Cuban 80s clusters. You can find these things in
LF Edge Working Group 2: The it closet of a warehouse or, you know, the it causative a manufacturing facility somewhere or in the managers office in the back of the CVS.
LF Edge Working Group 2: You know, or in, you know, the managers office in Walmart, you'll find these little clusters of IT equipment that are running a running Cooper daddy's in the running containers.
LF Edge Working Group 2: It's it's squarely in focus for open horizon to be able to deploy workloads to those clusters. Those Grenadians clusters, just in the same way we can deploy them to a device. And so again, this is relatively new capability and it works exactly the same way with one exception.
LF Edge Working Group 2: You would create a service definition for the services you want to deploy to the cluster you create a deployment policy.
LF Edge Working Group 2: That matches up with, you know, the policy for that edge cluster. There's an agent running in the cluster. Just like there is on a device.
LF Edge Working Group 2: That agent has a node policy associated with it that you know they'll show you how that works in the second that that's how the I bought finds this cluster.
LF Edge Working Group 2: And then we will deploy open horizon agent running inside that cluster will deploy the service that you've configured. Now the difference here is
LF Edge Working Group 2: We know the agent in this case knows that it's running inside of Cooper Nettie so what it actually will deploy is the operator A Cooper daddy's operator. So the service definition.
LF Edge Working Group 2: That is in the management hub is actually pointing to an operator. In this case, the edge agent.
LF Edge Working Group 2: will deploy the operator into the same Cooper daddy's cluster to the runs in that operator, then, is responsible for deploying the actual services that you want running in the cluster.
LF Edge Working Group 2: Cooper daddy's operators, a fairly well known thing. There are tools open source tools in the coop world for building these things.
LF Edge Working Group 2: So, and so this is how open horizon integrates will deploy those operators for you. And then your Cooper 90s administrator can work with that operator in the way that he's used to dealing with it.
LF Edge Working Group 2: And manage the service for you if if the if the agent decides to service shouldn't be there anymore. He'll take the operator away.
LF Edge Working Group 2: And operators will then take away the services that they're supposed to supposed to be managing so the life cycle works exactly the same. It's the same policy mechanism. It's the same agent code.
LF Edge Working Group 2: It's just running in a different context. And it's Cooper natives aware so you will see in our source code that we have Cooper Nettie is awareness.
LF Edge Working Group 2: For for exactly this use case so that we can deploy to either one of these edge contexts, either the simple device or the edge cluster case.
LF Edge Working Group 2: Now,
LF Edge Working Group 2: Let me just show you quickly and this is might be a little bit of an eye chart and I'm sorry if this is hard to see.
LF Edge Working Group 2: There's lots of examples of service definitions. I thought you should at least see one. This is the JSON definition, all of the resources in open horizon are defined by JSON.
LF Edge Working Group 2: Some research told us that JSON was easier for people to deal with then gamble. And so we so we went there. I always get this question, why not yet all in my responses y mo.
LF Edge Working Group 2: So, you know, it's six of one, half dozen the other. You can convert one to the other. If you want to open her eyes and uses JSON.
LF Edge Working Group 2: So, sir, what's a service definition. There's some administrative stuff up front, who owns it, you know, a label a description. Those things are interesting from a, you know, for see allies, or for you guys that would get built on top of this. Where's the documentation for it.
LF Edge Working Group 2: There's a couple of attributes in here that are interesting.
LF Edge Working Group 2: Let me jump to the bottom first. So
LF Edge Working Group 2: Deployment down here.
LF Edge Working Group 2: This is the configuration of the of the containers, the actual container images that you want to deploy in any configuration of them that you want.
LF Edge Working Group 2: Any variables that that the
LF Edge Working Group 2: Container knows about that you
LF Edge Working Group 2: Want to set can be set here.
LF Edge Working Group 2: Are required services is a set of capability that allows you to indicate
LF Edge Working Group 2: Other services are dependencies of yours. So it's possible to create a service dependency tree with open horizon.
LF Edge Working Group 2: Deploy the top level service and then all of its dependencies will be deployed automatically for you.
LF Edge Working Group 2: You know their configuration will be done. We, the agent will start the containers. In this case, if you have a tree of dependencies, like this.
LF Edge Working Group 2: What the agent will do is he will start the containers at the leaf nodes of the tree and build up to, to the top level service, the one that you really trying to deploy so he'll build from the tree up
LF Edge Working Group 2: And get all the services connected together networking. Why so that they can talk to each other.
LF Edge Working Group 2: The most important parts of a service definition, are these three fields in the middle the URL, which is essentially the name of the thing, the version. And this is a semantic version. It has meaning so open horizon is aware
LF Edge Working Group 2: That one version is different from another and greater than another.
LF Edge Working Group 2: Open our eyes and nose at to Dotto is newer than one.to right so this is not just a text field.
LF Edge Working Group 2: This there's semantic versions associated here and it's three dotted decimal field, the dots in the numbers are optional. So if you say version one that's assumed to be one dot zero dot zero
LF Edge Working Group 2: So under the covers everything it's normalized, you'll see us do this in the code, but the version in Scheme is is works in that way. And then the hardware architecture field that tells us what
LF Edge Working Group 2: You know what hardware architecture does a service run on because because it matters is how the code the Docker container that you use of the OCI container image you use are usually specific to a particular hardware architecture.
LF Edge Working Group 2: We can't deploy that on something with a different hardware architecture. So that's important for us to know what architecture is available.
LF Edge Working Group 2: Now the last one last field here is sometimes confusing to people is public field in the service definition. What this means is that the service.
LF Edge Working Group 2: Is publicly available to organizations outside the one you're working in. And so now you're thinking, What do you mean to organizations, what, what are you talking about open horizon.
LF Edge Working Group 2: Is built to support multi tenancy what we call multi tenancy meaning that the management hub can support multiple different groups of users who are completely unaware of each other.
LF Edge Working Group 2: If this is the way you want to define the system now in our test environments. You know, usually have one organization, but all assets all definitions that are defined within the system are all qualified by the organization that they live within
LF Edge Working Group 2: Public true means that this service definition can be seen by other organizations. So it's possible to have one organization create some services.
LF Edge Working Group 2: make them available as public equals true and other organizations in the same management hub and it could be the same users if you wanted to, but it could be completely different users.
LF Edge Working Group 2: Can use the services. So services can be reusable. In this sense, not just you know within dependency trees, but also across organizations, if that's if that's interesting.
LF Edge Working Group 2: Now the last thing I will talk about today.
LF Edge Working Group 2: So I don't overwhelm me too much unless you want to talk about today is policy.
LF Edge Working Group 2: There are two ways to deploy services, I talked about one of them. I talked to previously about using a deployment policy to deploy a service. There's a second way called patterns. It's a whole lot easier, which I'll go into at a future point if if necessary.
LF Edge Working Group 2: Policy is the more flexible mechanism because the, the language that's used to describe how things are deployed is completely open ended. It's completely open to the user to decide.
LF Edge Working Group 2: How they want to structure their policy language what open horizon provides is just a way to match policies to look for compatibility or in compatibility. And so here's
LF Edge Working Group 2: Here's how this works. I want you to focus on the right side of this slide for a second right side of the slide is the JSON representation of a deployment policy.
LF Edge Working Group 2: You know label description, the usual stuff. There's some information here about what service. I'm trying to deploy. What's the name, what organization is the service live in. What's the hardware architecture of it what versions.
LF Edge Working Group 2: Of the service. You want me to try to deploy. Right. So those are all that's all that information figures out which service. I'm trying to deploy.
LF Edge Working Group 2: The policy for where to deploy is defined
LF Edge Working Group 2: In this constraint parameter towards the end of the JSON. The way to read this constraint parameters as follows.
LF Edge Working Group 2: The, the management Hub will deploy this service the booze CPU service will be deployed to whatever node has a property called robot.
LF Edge Working Group 2: And the value is set to true. That's how you read the constraint expression.
LF Edge Working Group 2: Think you can think of this, like if you're familiar with database queries. This is like a query predicate from a database.
LF Edge Working Group 2: Query very similarly this is like the where clause of the of the select statement.
LF Edge Working Group 2: We go look at a sample node policy on the left side here, you can see that this node has a set of properties in it.
LF Edge Working Group 2: Some of them have the open horizon prefix, those, those are built in provided by open Horizon, horizon intersects those properties on the node that it's running on and sets those values for you.
LF Edge Working Group 2: But the user can also set their own. And in this case, we see that the user of this particular node set a property called robot and he set the value to true.
LF Edge Working Group 2: So nice. So the constraint expression for this service matches the property that's over there on the node. So that means that this deployment policy.
LF Edge Working Group 2: And the node match this node will have, you know, can have can support the service because the policy is is compatible or or is it
LF Edge Working Group 2: Are our policy mechanism and open horizon is actually bidirectional nodes are not assumed to be slaves in that they have no vote in what happens to them a note owner and this is again another really important architectural principle in the agent is that a node owner
LF Edge Working Group 2: May not be even in the same business unit or under the same control as whoever wrote the deployment policy.
LF Edge Working Group 2: So sometimes a node needs to have a vote and how this works, which is why the policy mechanism also works in the reverse direction nodes can have constraints that can say
LF Edge Working Group 2: You know, the, the deployment policy that's trying to deploy a service to my node better meet these these constraints, they better be a property called purpose.
LF Edge Working Group 2: That has the value asset utilization monitor or that same property that has the value assessed paint quality so that the point of policy better have one of those things in it.
LF Edge Working Group 2: And sure enough, in this case, it does. There's a property in the in the deployment policy that matches the first case.
LF Edge Working Group 2: And so we do have a bidirectional match and that is what allows the service to be deployed to the node.
LF Edge Working Group 2: Normally the nodes don't normally have constraints deployment policies don't normally have properties when when users are starting to get used to this policy model understand how it works. Usually
LF Edge Working Group 2: It's a constraint in the policy and the deployment policy.
LF Edge Working Group 2: And properties in the node when they match up deployment happens it's only in the cases where you get more advanced usage where the node needs to be a little bit more selective about what's being deployed to it.
LF Edge Working Group 2: That you would start introducing constraints to the node that the deployment policy needs to match. So this bidirectional capabilities there.
LF Edge Working Group 2: It's it's advanced. Usually it's unidirectional from the policy from the deployment policy back to the node. So there's a lot more. I can say about this, but I think that's as much as I want to do.
LF Edge Working Group 2: Again, how does the agent fit into all of this, right, the agent is is interested in the node policy, the agent is interested in verifying that these policies.
LF Edge Working Group 2: Do in fact match the agent is interested in all of the configuration within the service definition because it it it tells the agent, how to start the container what container to start how to start it what variables to set, etc. What's the name of the thing.
LF Edge Working Group 2: If the version of the thing changes the agent can react to that he's aware of the version of the service, etc. So the agent is aware of almost all the concepts in the system. And they're all relevant
LF Edge Working Group 2: And that's why I needed to take you through sort of the high level context here about how all of this stuff fits together. So let me stop. There's five minutes left in our scheduled time. Other questions.
LF Edge Working Group 2: About anything. I went over.
dcmartin: Is there a catalog of the built in.
dcmartin: Properties.
LF Edge Working Group 2: Properties, there is in source code there is yes.
LF Edge Working Group 2: We're, we're developers. You want to see what they are looking at the code, there's one place in the code where they're all defined
dcmartin: I believe I think there would
dcmartin: Be I think it would be important for consumption of the rise in general if there was some kind of catalog or ontology.
dcmartin: Of these attributes that we
dcmartin: Look at debate across
Joe Pearson (IBM): Good point DCM I
Joe Pearson (IBM): jotted down a quick note on the something we should take a look at for the documentation as well.
LF Edge Working Group 2: Yeah, there's, I think there's, I think.
dcmartin: I like to like to elevate to
dcmartin: Make it a first class discussion on what should be
LF Edge Working Group 2: Completely reasonable thing to discuss in this work group. Yep.
LF Edge Working Group 2: Yep, I think there's an empty file and the source code that also outlines what they are, which is the way that we do documentation.
LF Edge Working Group 2: In the repos by, you know, putting those in the files in the right spot so that you can define what's there. I think there's an empty file that defines all these, but I could be wrong about that. And if there isn't, we should certainly create one of those at a minimum, but yeah.
LF Edge Working Group 2: You know what, what is a built in property. What are the built in properties that we support. What are the semantics of those things. That's all in scope of what this work group is responsible for
LF Edge Working Group 2: Any more questions.
LF Edge Working Group 2: All right, only got a couple minutes left, so in a wrap. I want to wrap it up. Thank you all for coming. If there are more topics that we want to discuss. If we want to do more deep dives into certain parts of the of the project.
LF Edge Working Group 2: You know, we certainly do that. I could talk for hours about the Autobahn find all that I'm not going to do unless you unless you need me to. So let's use the slack.
LF Edge Working Group 2: Let's use the Slack channel and we can discuss, you know, any material. Any other deep dives. We want to do or any issues or design topics we want to discuss let's you know let's let's use the Slack channel there and then will you know, I'll take the agenda from there.
dcmartin: I'd also like to make a request that we have a build environment.
LF Edge Working Group 2: Team here can utilize when we start to try and address issues. Yeah.
dcmartin: The reason I say that because I don't know how to do it.
LF Edge Working Group 2: Yeah, there's a there's a DevOps, there's two things going on there. There's a DevOps work group that's supposed to be.
LF Edge Working Group 2: Getting on top of the LF edge infrastructure to get us there so that we can do builds you know when PRS come in will do builds in the LF edge infrastructure.
LF Edge Working Group 2: You know, produce the packages run the tests there. So there's a whole CI CD and the that the DevOps work group is responsible for
LF Edge Working Group 2: The other side of the other side of your question, Dave. Is that a lot of the build is actually moving into the annex repo itself so package build is moving in there.
LF Edge Working Group 2: Deb and RPM are moving in there and there's already a test infrastructure in there that you know that we need to do, probably a little more work on
LF Edge Working Group 2: To component eyes a bit, but there's already a test infrastructure in there that brings everything up, and runs a pilot test against it. We have that in the repo also
LF Edge Working Group 2: That runs today and the
LF Edge Working Group 2: You know, our
LF Edge Working Group 2: Our product actually uses that to
dcmartin: Yeah, we can do that, do it. They
LF Edge Working Group 2: Can do that too. I think, I think there would be I think it would be useful to see, you know, to, sort of, you know, the life of a PR
LF Edge Working Group 2: I got a piece of code. I want to change. I've got the repo in front of me. You know what, you know, what do I do to change the code where I do to build it, what I do to test it. How do I submit a PR that might be an interesting topic.
LF Edge Working Group 2: For folks to see
LF Edge Working Group 2: Okay, anything else.
LF Edge Working Group 2: stop sharing
LF Edge Working Group 2: I'm Joe I assume this thing stops recording when I terminate the meeting.
Joe Pearson (IBM): Yes. Yeah, there should be an option for the host to end the meeting, and that will stop the recording.
LF Edge Working Group 2: Okay. All right. Okay. So I think we're, we're at the bottom of the hour. So I will thank everybody for coming, participating today we'll meet again in two weeks. And let's use the Slack channel to start the discussions that we want to have
LF Edge Working Group 2: Okay, thank you all for
LF Edge Working Group 2: Joining us today I guys