 So, hello everybody. I would like to encourage you to ask questions at the end of the session. You can win scars. Our next presenter is a member of Red Hat Release Engineering team and is involved in non-X86 architectures for both REL and Fedora. Please welcome Peter Robinson. Hello everyone. So I'm going to talk about using OS Tree on Fedora for IoT. It's going to be a fairly quick presentation with a small, slightly working demo at the end. I should have learnt much better by now than actually trying to set up a complex multi-computer with network demo at a conference, but, well, you know, it is what it is and there's not much we can do about it now. So there's been a lot on the news about security of IoT, IoT being Internet of Things, or as I prefer to call it, Internet of Everyone Else's Things. So we've got fairly good architecture support for a lot of the sort of little devices like this one here, and I'm probably going to break my demo before I even start it. And they're being actively used in lots of different sort of IoT projects, but they're an interesting case of hodgepodge of things just pulled off the Internet and thrown together. So I think we could do an IoT spin with project atomic OS Tree stuff to give, you know, non-brickable devices using open protocols and open IoT standards. And so that's what I've started to do, and I've had a fair amount of interest, but it is a very vast space with lots of things we could do. So we're just going to initially target three architectures, you know, no pressure. A few of the core upcoming protocols like Cope and MQTT, which is a slimmed down messaging stack, and then give the ability to lay out sort of bigger projects on top like Node, Red, and IoT TV. So, yeah, target some initially a very small hardware set. In the Fedora ARM project, we currently have support for well over 150 devices, and we support some of those better than others. So we figured that if we target a small set of initial devices that we can get working really, really well, it should then be much easier to expand it out to the much greater IoT ecosystem as we go. So, yeah, we'll be initially focusing on Beagle Bone and Chip. Hopefully Raspberry Pi 2, it allegedly has enough in the upstream kernel for 4.5, so fingers crossed we may be able to add support for that in Fedora 24, and then other devices like the Pine 64, which is a new $15 ART64 device, which apparently I have waiting for me at home in my postbox, so we should have some interesting devices coming along there this Fedora cycle. So I'll just give a small demo, which you'll primarily be, and it may not be too easy to see on the screen, so we'll see how we go. So just here we're just booting into the OS tree with Patrick who's helped me out on this, and I have discovered a number of bugs as we've gone along, and so it's sort of been very much iterate early, iterate often process with the lack of conference Wi-Fi not being particularly useful to us for pulling down new images. I was going to get the Beagle Bone I have here to use it as a gateway to speak to this little device, which is a TI sensor tag, which is a minuscule device with about 16 sensors, temperature, barometric pressure, light, XY axis, various other... That looks useful. We're not there just yet. It's a good start. What do they say in TV? Never work with animals and small children or computer systems. So here we have running OS tree and then... So we can see the sensor tag here. I couldn't actually get it working. I basically run out of time. I got the OS tree image running about an hour before the talk was due to kick off. So it wasn't quite there, but we're getting there and we should have a working image with sensor support in the next few days with luck. But yeah, so the demo was originally going to be this where we've got a couple of... It ended up basically being this bit here. So we're not quite all the way there, but it's working and by the time F24 goes GA, we should have a sort of tech preview spin for people to actively play around with and start to contribute to. So how do you get involved? At the moment, we've got a mailing list and an IRC channel. The Git repository has all the atomic bits that we're using to build the image. And in the next few days, we'll start to generate like a nightly raw hide OS tree, which I'll send the details out to the mailing list for people to start play with. And hopefully shortly thereafter, I'll actually be able to produce nightly sort of arm images, but we have a few things we need to fix there for image creation. So almost that, not quite. So in summary, the plan is to start small with a very focused feature set, very focused device set, far small incremental improvements to that built purely on a topic. So no DNF install of various functionality. I think this is the right way to go, especially for IoT based devices. We then have the potential to expand out from there. There's been a number of robotics and there's a very good Fedora robotics spin that I've had a number of people ask me about using some of the devices with real time PR use and things like that and whether we could support robotics and things like that on it. Sure. I don't think I have the skill set to actually make robots fly. I think they would just crash and burn. So it's probably not the best person, but absolutely would love to see people doing that sort of stuff on Fedora. And as I mentioned earlier, we'll have a preview coming for F24. So anyone got any questions? I have some cool scarves to give out here. Is the integration of atomic something that's hardware specific or is it not? In other words, could we use the atomic update element of what you're doing independent of the IoT components because that might be useful too? Yep. So there's nothing particularly hardware specific and like this image that we're running here will run on pretty much any of the ARM devices that we support in Fedora. We won't be doing anything to stop it running on any devices, but we'll be just focusing feature-wise and things like that on specific devices. But everything we support in Fedora will be supportable this way. Cool. Anyone else? Over here. Sorry. Do you have any early ideas on what you're going to do with the little TI sensor? So this TI sensor tag is kind of cool in that it's got a 2.4 gig wireless on it and you can upload different firmwares into it. So the firmware it's got at the moment is a Bluetooth smart firmware that supports Bluetooth 4. I've heard rumors that they're going to add Bluetooth 4.2 support, which will give us the ability to run six low WPAN, which is a reduced IPv6 stack over it. And you can also put in a generic 802.15.4, which runs across 2.4 gigahertz range as well, but enables full meshing and to run six WPAN across it. So it's a Cortex-M3 processor, so we can't run a full blown Linux on it, but at the same time it runs off a cell battery and you can do that for a year. So basically the plan is to be able to support the IoT, like the Fedora build as a sort of gateway to speak to these sort of devices as well as interact with the sensors directly on plugged into the devices as well. Anyone else? So when I arrive at my destination I have everything I need. Yeah, so we could, I was about, yeah so the question is how we can use IoT and something like this to track his damn luggage that the airport seems to lose. Yeah, so you could quite easily put together a little device with probably a cell phone chip and SIM as long as you're happy to pay international roaming. And then we basically have GPS logging and you can upload it and you could probably even put a camera on it so you can take photos of the idiots that are losing it. Smile, exactly. Any further questions? Yeah, sorry? What are you doing in the space of monitoring the heartbeat of those devices? The heartbeat of which devices? All connected devices. Do you mean as to whether they're up and operational? Yeah, so the idea is that they have watched dog devices on board. So if you do a atomic OS tree upgrade and it fails to boot into the new version you can reboot back to the old one or if the device locks up you can trigger the watchdog will trigger to reset it and boot back to a known good config. Does that answer the question? I mean that's a nice thing of OS tree is that you can have multiple versions and so if you do an upgrade you set a boot once flag and it reboots and if it boots up and doesn't go into the new version and like planning on having a little demon that will do like some health checks once the new version boots so can I see my sensor devices, can I speak to the network and communicate back to say the MQTT broker and if none of that fails so it might boot up but it might not have network connectivity or it might boot up and it might not be able to see all the sensors and if it doesn't pass that health check it then basically resets or a watchdog will trigger if it's not up by a particular time. If it comes up and all the health check passes it turns off the watchdog trigger but if it fails at any point in that the watchdog will trigger and it will just boot back to the old working version. So in theory we should be able to we should be in a situation where we should never get a device that's bricked. How that works in practice time will tell but there's been a number of examples over the last couple of years where IOT manufacturers have sent out a poorly QA'd firmware and they've ended up with a million brick devices that they've had to sort of email customers and go we're terribly sorry can you please ship your device back so we can ship you out a working one. No more questions? The question is about upper layer stacks so at the moment the primary stack I'll be aiming for because it seems to have the most traction in the IOT space is no dread and we're working to get that we have no JS4 and a bunch of dependencies that Jared Smith, Stephen Gallagher and others have been working on and that's landed in Fedora 24 so that will be the initial stack will support but the idea is that we will probably run those stacks within Docker on the image so that you can basically switch out. There's another group that are running a stack called IOT, IOTivity which I mentioned. Yeah so this one here so the idea is that we can basically support a number of different stacks and you can basically just deploy whichever one you know suits your needs or you want to play with to keep it modular. What in your mind is the separation of the responsibilities between the underlying platform atomic plus pieces that will be running on atomic on the middleware and middleware stacks like that? It depends a lot on the deployment. You wouldn't run something like no dread necessarily on the endpoint sensor devices in the case of but then like I mean in my opinion an IOT gateway is something that will bridge between a network of sensors and so you've got like in an industrial environment they don't tend to use wireless at all because it just gets destroyed with all the machinery and things like that so they tend to run CAN buses or RS485 things that they can run over shielded cables to ensure that the data gets through so like an IOT gateway tends to be either from you know Bluetooth LA or ZigBee or one of the network stacks to IP they don't tend to run like MQTT brokers or other stacks like that although they can do some caching but they tend to be quite small and then you would get what I would tend to call a middleware or messaging gateway which is an IOT specific that you run in a data center to potentially process the output of that to inject it into something like elastic search or some platform to enable you to do statistics and data and stuff like that so from like an IOT gateway tends to be like a six low pan to IPv6 network sort of almost router as opposed to running a massive middleware stack on it well ultimate so the question was would we stream everything into the data center define a data center I mean in a home network where you might have a bunch of temperature sensors adjusting the heating you probably wouldn't need a data center at all because the devices talk to each other and you would run a simple MQTT broker on that gateway device but you wouldn't necessarily run an entire middleware stack on the gateway device in the case of a large industrial factory there would probably be a data center that's running that factory of some description on site or if it's a network or if it's large multinational corporation it depends on the use case hi I would like to ask what containers do you do you plan to release together with the first first release of Atomic Fedora I suppose some kind maybe you have mentioned some stacks like Node Red but will be there something like tools container or similar similar things in the first release for f24 there may not be any it may be just a basic image with the ability to manipulate a bunch of sensors you know some MQTT clients and and so ultimately open to discussion open to people who are interested in doing things there's a lot of different projects out there and the idea is to be flexible also have to be realistic I was hoping to get this working a year ago and with day job and life and various other bits and pieces it's taken me longer than planned so my plan for Fedora 24 is to get a relatively stable robust base image with support for hardware and network interfaces and things like that and then see how far we get in Fedora 24 and then build on it from there thanks so I think that's it those of you that asked questions and would like a scarf feel free to come up to the front and grab one from me thank you I would also encourage you to vote for lighting tools in this section and please come in time to presentations during the breaks thanks hello