 Hi, everyone. Welcome to the monthly Fedora Council video meeting. I am not Matthew Miller. I'm Ben Cotton, the Fedora program manager. This month we have Peter Robinson, who is the lead for Fedora IoT, talking about Fedora IoT. Peter, why don't you just go ahead and take it away. Thank you, Ben. I'll give a brief overview of myself, what I do, and then another view of what Fedora IoT is, where we're going, and kind of why. And then from there we can open it up for any questions that anyone may have. So I'm Peter Robinson. I've been involved in Fedora to some degree or another, basically from the outset. I have been involved in a lot of different things throughout the project. Over the time I have been on council and previously on the board as well. I have done community roles and then around five and a half years ago I started officially working on Fedora related things as part of release engineering, doing what at the time was referred to as secondary architectures is now referred to as alternate architectures. And then about three and a half years ago my senior vice president at the time or senior vice president of rail at the time, did a student mass basically gave me the job of investigating IoT in the context of the Linux operating system. So Fedora and related distributions but explicitly doing that sort of research and development around that in the Fedora community space. So Fedora IoT was basically born out of that remit to basically go and investigate IoT for Red Hat. So that's a brief overview of me. I've been at Red Hat about seven and a half years if memory serves me correctly and been working towards Fedora IoT for about three and a half of that. Anyway, so Fedora IoT, it's fully based on Fedora, fully upstream in Fedora. We don't have any forks. It is an RPM OS tree based remix or addition actually now of Fedora based out using atomic and Core OS technologies to produce a addition that is focused on IoT and device edge. The term edge and the term IoT are very similar to cloud in that they're very, very, very overloaded terms. Are we looking to run on your thermostat? Are we looking to run on tiny little sensors? No, we are not. You basically need to have a system that is essentially a Raspberry Pi or larger. So reasonable amounts of RAM able to run a full Linux distribution. We are in the short term at least just primarily due to the amount of resources that are available in terms of people and related that are actually actively working on this. We're focused on primarily a gateway style or an endpoint style Linux device without a graphical display. So, you know, we're not sort of currently going looking at sort of display related technologies. It has certainly been discussed. It has certainly been, it will possibly eventually be on the roadmap, but we're nowhere near that side of things. So, how does Fedora IoT differ from server or cloud or workstation, you know, delivery artifacts? We only deliver an RPMOS tree based image. It's relatively minimal, nowhere near as minimal as I would like. Applications are designed and meant to running containers with sort of just enough operating system underneath it to boot the hardware and interface with the hardware. We have a focus around security technologies. We have a number of large companies that are actually running Fedora IoT in production. And we're engaged with customers, partners such as ARM, Lonaro and various other areas of the ecosystem to sort of provide feedback and engagement and support in the sort of things we are doing. For example, the Lonaro ledge or the Lonaro edge initiative uses Fedora IoT as one of their reference platforms. And yeah, so generally a small OS, mostly rolling release RPMOS tree based where with Fedora 32, we're moving from a initial setup based config. So when you first boot, it would typically prompt you to create a username and various other bits and pieces so that you can log in and continue. While that's very good from a developer point of view, because it will run up and allow you to provision, it's no good for a widely like. So we have customers that are running hundreds and looking at running tens of thousands of instances. And obviously you want to be able to auto provision that. So yes. And so we're moving to an ignition based provisioning system. And there's a web interface for that so you can sort of DD out an image for say the Raspberry Pi and go to provision dot Fedora project.org. You will need to have a wired network connection currently because we don't have the ability to deal with wireless interface config locally. And anyway, you can then sort of claim the device. The service is relatively new. It is still under sort of development. I'm still need some enhancements. So if people are interested in IOT and are interested and capable of doing. Python Django, I believe it is written in based web development. Certainly reach out to us because we're doing some quite cool and interesting bits and pieces there. And yes, that is a general overview of it. Thanks Peter. Open up the meeting to questions from anyone. Just jump in and unmute yourself and shout your question out or put it in the chat if you can't. My question is, what's the biggest difference between IOT and Fedora coro s. So Fedora coro s is designed or has a focus of being a Kubernetes based distribution. Fedora IOT isn't focused on that. So we deal with a lot of things that you wouldn't get. So you wouldn't run a Kubernetes distribution typically over say a wireless wham link or low bandwidth. Yeah, it's designed also because of Kubernetes to be sort of in groups of machines. So cluster based where a lot of the Fedora IOT and device edge use cases are single use cases. So designed not to run in clusters and designed not necessarily to use something like I think it's airship to do sort of cluster based reboots. And movement of workloads and things like that. So basically coro s is very much focused on primarily being an OS in which to run Kubernetes on top of we are not. Ben, were you talking because I can't hear you. Oh, you think I'm supposed to unmute. Is that important? Anyone else have questions? I'll throw one out. Can you talk a little bit about the release streams and upgrades process because one of the big issues with IOT devices in general is they ship with some software and then they never get security updates and then everything is terrible. So how do we deal with that in Fedora IOT? So from a release stream point of view, we have three main streams. We have the stable stream, which is currently Fedora 31. We have Devel stream, which is currently 32. And we have roll hide, which is constantly rolling against the main Fedora roll hide. The stable stream will be switched to Fedora 32 on release day. And basically you will be actively upgraded through to that. There's a number of reasons for that. One, basically it's primarily a rolling release. And two, we just really don't have enough people to maintain multiple streams. So that leads into another question I had written down is how can people contribute to Fedora IOT if they're Fedora contributors who want to join in and help out? So we have all the usual Fedora means of contribution. We have IOT mailing list, IOT IRC channel, which is Pound, Fedora hyphen IOT. We have a Pagger instance with a number of Git repos that are primarily used around docs and the release engineering side of things. And we also have a Fedora-IOT GitHub page where we host a few of the other more general projects around that. So the provisioning system, which is the project name is Zaziri, is based there along with some of the security related stuff. Green Boot, which is a project around upgrade and rollback. So if a device, you can set up a bunch of health checks. And once you upgrade and reboot a device, if it can't connect to, say, the network and the update system and various other or C bits of hardware that are specified within the health check framework, it will rollback to the previous version. So there's a number of different ways to get involved. The mailing list and the IRC channel are probably the two traditional ways that most people actively involved in Fedora will know how to get involved. So I know you mentioned earlier, Ignition required some Django experience, is that right? What other sort of technical areas or non-technical areas are you really looking for contributions from right now? So some of the, I wouldn't call them non-technical, but more easy to get involved area is documentation and testing is always useful. We support currently a small amount of hardware with Fedora 32. The supported hardware is widening out quite a bit there with addition of devices from Pine 64 and a couple of other companies, which I will be able to talk about shortly. So documentation, testing on the technical or the more engineering development side of things. We have Zaziri, which I mentioned, which is the web-based provisioning system, and there will be some other functionality coming to that. We have a handful of sort of issues open where we track functionality. I need to create a bunch more there, but there's a bunch of bits and pieces there, which are relatively straightforward to get started with if you're aware of sort of Python and Django-based development. And then we have lower-down related stuff where we've got quite a big focus on TPM2-related stuff and things that utilize the TPM, such integrity measurement and application-related stuff. And so there's a bunch of work that's being done there. And a whole bunch of other sort of feature enhancement-related stuff that if people are interested in, I am sure that there are a lot of other ideas that aren't exactly coming to my direct to my mind at the moment. Any questions from anyone else? I'll throw another softball your way, Peter. How many IoT devices do you have sitting somewhere in your house right now, whether you're using them or not? I would say 100s, and in actual fact, in the coming, well, it was due to be in the coming weeks. I think probably due to the current pandemic at the moment, it will be some time in the coming months. I am due to move house, and I was actually planning on documenting all the devices in a series of blog posts when I moved. But I would say from full-on ARM devices, like the Pine 64 and Raspberry Pi 4 and similar-related devices through to devices such as this device, which is Zephyr-capable, so much more RTOS and smaller and can be run on a battery. Well, and truly into the hundreds. So how much of the Fedora IoT work is done sort of on Fedora IoT itself versus on component packages or upstream to make sure things work right on ARM hardware, for example? So there's a lot of testing in Fedora and Fedora IoT directly around the ARM-related stuff, but also X86-related stuff. There is, I do a lot of contribution into other upstream communities. So Uboot, for example, for device enablement, and a lot of that is sort of more done in my own time and as part of the Fedora ARM effort. I'm directly involved in a bunch of upstream standardization organizations as part of my job at Red Hat and as part of my remit there. So I mentioned Lanaro, and so Lanaro actively uses Fedora IoT and there are some other sort of ecosystem and standardization bodies that I participate in as well. So it's a combination like right across the ecosystem in my opinion. Great. Any other last chance for questions from anyone else in the audience? I think we might have a question coming up, but we can't hear them. I got a question. I'm not on the council, but I'm here for the meeting. Please. Whatever happened to the ExxonMobil and Fedora deal? Can we talk about that? So ExxonMobil is actively using Fedora IoT. I wouldn't call it a deal per se. They're a company like a number of other companies that are using Fedora IoT. We're lucky in that they quite happily have openly spoken about their use of Fedora IoT in a number of forums. Okay. Just curious. I remember hearing it flock. Is there any way that the community can help with ExxonMobil's efforts or is that even something that they've requested or need? I mean, help in their efforts is an interesting... I mean, they are actively following along the discussion that happened in the community. They don't tend to speak up in that space a huge amount, although there are certainly individuals there that sort of actively sort of participate in that sort of space. Community directly working with Exxon is not really something that's sort of easy to do. But yeah, no, they at the moment basically use pretty vanilla off the shelf Fedora IoT. They layer a few packages on for specific low level bits and pieces that they need and they run a lot of stuff in containers across a bunch of different use cases. Thanks, Peter. Anyone else? This is open questions. You don't have to be a council member to chime in with questions for Peter. In fact, we encourage people who aren't council members to give him the business. Well, it sounds like we've reached the end of questions. Peter, do you have any last comments you want to make? No. Obviously, I've tested feedback. Feel free to reach out to me if you have any other questions or queries around Fedora IoT or any suggestions. All right. Thanks, Peter. And thanks to everyone who joined in and participated. We through our council does this every month with different guests as suggested by members of the community. So if you go to the Fedora Wiki, the council slash video meetings page has a list of the upcoming meetings and a place where you can submit ideas for people we should be talking to. And with that, everyone have a great day and we'll talk to you next month. Thank you, Ben.