IoT September 2019

iot@lists.fedoraproject.org

8 participants
13 discussions

Re: Official mozilla-iot-gateway container
by Troy Dawson 27 Sep '19

27 Sep '19

Sounds good. Thank You On Fri, Sep 27, 2019 at 9:14 AM Frank E. Zimmer <frank.e.zimmer(a)gmail.com> wrote: > > I will have look at it and provide the first version in the next few days. > I would suggest it should pass our first internal review before I > submit it to the reviewer. > > > On Fri, 27 Sep 2019 at 17:34, Troy Dawson <tdawson(a)redhat.com> wrote: >> >> The documentation starts here >> https://docs.fedoraproject.org/en-US/containers/guidelines/guidelines/ >> >> It's very similar to getting an rpm packaged. You have a submitter >> and a reviewer. >> https://docs.fedoraproject.org/en-US/containers/guidelines/review/ >> >> I've been through many rpm review processes, but not a container one. >> So this will be new for both of us. >> >> On Fri, Sep 27, 2019 at 8:28 AM Frank E. Zimmer >> <frank.e.zimmer(a)gmail.com> wrote: >> > >> > Hi Troy, >> > >> > I would be quite happy to provide the official fedora container. >> > In the beginning, I might need some assistance from you. >> > >> > I mentioned to Peter that I would be also interested in >> > working on tasks around home assistant sometime later. >> > >> > I will be pretty busy in the near future due to private things. >> > Nevertheless, it should be possible for me to work on the >> > mozilla-iot-gateway container. >> > >> > How do we proceed? >> > >> > Frank Zimmer >> > >> > >> > >> > On Fri, 27 Sep 2019 at 16:27, Troy Dawson <tdawson(a)redhat.com> wrote: >> >> >> >> Hi Frank, >> >> Were you interested in making an official fedora container[1] with >> >> your Dockerfile[2]? >> >> If so, did you need any help? >> >> If not, would you mind if I did it? >> >> >> >> Troy Dawson >> >> >> >> [1] - https://docs.fedoraproject.org/en-US/containers/ >> >> [2] - https://pagure.io/mozilla-iot-gateway-container >> > >> > >> > >> > -- >> > Dr. Frank Zimmer >> > Polenzstrasse 23 >> > 01277 Dresden >> > >> > Handy: +49 163 3091361 >> > Tel.: +49 351 3144310 >> > > > -- > Dr. Frank Zimmer > Polenzstrasse 23 > 01277 Dresden > > Handy: +49 163 3091361 > Tel.: +49 351 3144310

1 0

Official mozilla-iot-gateway container
by Troy Dawson 27 Sep '19

27 Sep '19

Hi Frank, Were you interested in making an official fedora container[1] with your Dockerfile[2]? If so, did you need any help? If not, would you mind if I did it? Troy Dawson [1] - https://docs.fedoraproject.org/en-US/containers/ [2] - https://pagure.io/mozilla-iot-gateway-container

2 1

[Fedocal] Reminder meeting : IoT Working Group weekly meeting
by pbrobinson＠fedoraproject.org 24 Sep '19

24 Sep '19

Dear all, You are kindly invited to the meeting: IoT Working Group weekly meeting on 2019-09-25 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: Fedora IoT weekly status meeting. More information available at: [https://pagure.io/fedora-iot/](https://pagure.io/fedora-iot/) Source: https://apps.fedoraproject.org/calendar/meeting/9244/

1 0

[Fedocal] Reminder meeting : IoT Working Group weekly meeting
by pbrobinson＠fedoraproject.org 24 Sep '19

24 Sep '19

1 0

Proposing a Fedora 31 IoT Test Day
by Sumantro Mukherjee 20 Sep '19

20 Sep '19

Hey All! Fedora 31 beta is about to be out and last release we ran an IoT Test Day as Fedora IoT is growing, we would like to see another test day this cycle.I was checking in to see when will be a good time to have it and if we can test new features or specific changes in this cycle? -- //sumantro Fedora QE TRIED AND PERSONALLY TESTED, ERGO TRUSTED <https://redhat.com/trusted>

2 4

[Fedocal] Reminder meeting : IoT Working Group weekly meeting
by pbrobinson＠fedoraproject.org 17 Sep '19

17 Sep '19

Dear all, You are kindly invited to the meeting: IoT Working Group weekly meeting on 2019-09-18 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: Fedora IoT weekly status meeting. More information available at: [https://pagure.io/fedora-iot/](https://pagure.io/fedora-iot/) Source: https://apps.fedoraproject.org/calendar/meeting/9244/

1 0

[Fedocal] Reminder meeting : IoT Working Group weekly meeting
by pbrobinson＠fedoraproject.org 17 Sep '19

17 Sep '19

1 0

[Fedocal] Reminder meeting : IoT Working Group weekly meeting
by pbrobinson＠fedoraproject.org 10 Sep '19

10 Sep '19

Dear all, You are kindly invited to the meeting: IoT Working Group weekly meeting on 2019-09-11 from 14:00:00 to 15:00:00 UTC At fedora-meeting(a)irc.freenode.net The meeting will be about: Fedora IoT weekly status meeting. More information available at: [https://pagure.io/fedora-iot/](https://pagure.io/fedora-iot/) Source: https://apps.fedoraproject.org/calendar/meeting/9245/

1 0

[Fedocal] Reminder meeting : IoT Working Group weekly meeting
by pbrobinson＠fedoraproject.org 10 Sep '19

10 Sep '19

1 0

Re: Minimizing IoT images
by Tim Coote 09 Sep '19

09 Sep '19

> On 6 Sep 2019, at 10:12, Peter Robinson <pbrobinson(a)gmail.com <mailto:pbrobinson@gmail.com>> wrote: > > On Fri, Sep 6, 2019 at 9:58 AM Tim Coote <tim+fedoraproject.org(a)coote.org <mailto:tim%2Bfedoraproject.org@coote.org>> wrote: >> On Wed, Sep 04, 2019 at 02:41:49PM -0700, Troy Dawson wrote: >> 2 – Of those packages that need to be in the IoT image, which ones do you think are the top priority? And what parts do you think can be trimmed? These are from previous discussions. >> anaconda-core – move flatpack from -core to -gui [3] >> initial-setup – pulls in … everything. Can it be trimmed down. >> Presumably `podman` is high priority. >> why? >> I’ve heard mention that there’s support for lxc images as an approach to packaging code within Fedora, but I’ve not managed to identify what the argument is. It makes sense in the context of a multiple machine environment, where there’s value in hiding the machine specifics, but in the context of IoT, the typical deployment is one machine with many cooperating processes and adding in an extra layer of indirection makes testing and operations more complex, while removing some of the dependency management/control of a package manager. >> > There's a bunch of points here so: > > lxc images in Fedora? That's a new one to me and I've never had any discussion around that with anyone in the context of IoT. My mistake. I meant podman containers. > > In terms of mult machine environment that's exactly what IoT is, I've spoken with customers where they want tens or hundreds of thousands of machines, in one case there was even a desire for the millions and then you do need to hide the specifics of the machine because there will be multiple versions of applications running, multiple versions of HW etc so the ability to be able to manage each app or app stack independently on a lifecycle that's separate to the underlying OS is critical. If we need to patch the OS for something like Spectre, a WiFi or bluetooth flaw you don't necessarily want to have to impact the application stack to be able to do that. > > I would ultimately, and pretty much all the feedback I've had is that running things in containers make things easier for teams as managing the dependencies for the apps in independent for each of the apps is easier and makes operations easier because they can look at each of the applications independently because each of the apps teams are independent to make the decision that is best of those teams independent of the underlying BaseOS and independent of the HW. My last IoT system’s around 1M computers. Initially, I thought that the issue being addressed was to create pools of containers that demand can be spread across, but I think that the desire is to support h/w and o/s variation in the field. I’ve looked at this problem in large enterprises in some depth. IoT emphasises the same challenges. At scale, the support costs dominate the economics because of the explosion of combinations of compoenent versions. The only way that I’ve found to keep a lid on the Incident and Problem Management costs is to keep as much the same as possible, otherwise the regression test corpus and the cost of Problem reproduction becomes horrid. It does mean driving the CD pipeline hard, to keep up, but you’ve got to do that anyway to keep abreast of fixes for exploits. >> I’d love to understand the rationale for using containers in this context better, as I’m concerned that I’ve missed something. Are there any pointers? >> > It allows isolation. Isolation of the applications from each other and from the HW. A lot of IoT use cases want to run multiple independent applications on a single device and if one of those gets compromised the impact is has can be mitigated and not affect the underlying HW or other applications running along side it. Add to that it allows applications to be upgraded on different lifecycles to the underlying BaseOS or each other. As a general rule, in the early stages of an IoT system, when the problem and the solution are not well understood, there is a high rate of deployment of new s/w versions. If these are going all the way to the edge, I’d expect a lot of instability. I think that I understand the problem better now. Thanks. I’m less sure that I believe the analysis/solution: let’s see what works :-)

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

IoT September 2019