[Starlingx-discuss] Edge Computing Use Case, Deployment Advice Needed
Hi StarlingX Community, We need your advice to determine the most appropriate way to migrate an existing demo deployed via containers to StarlingX infrastructure with cloud features in mind (e.g. zero touch provisioning). We are integrating this demo in our spare time to ramp up in cloud technologies and one of its imperatives is a working solution. It started as a use case proposal around unmanned aerial systems [0], then decided to avoid some of the complexity involved in flying the drones, and finally landed it as a use case around home automation / smart cities at the network edge. Three key aspects for you to consider: - Edge computing foundation is all about "things" interchanging "data" with "servers", same foundation when both use case proposals were envisioned. - "Data" will include "video streaming" pipelines, considered in both use case proposals. - "Video streaming" pipelines will serve as an input to "machine learning / deep learning" services offloaded to different hardware (CPU, GPU, VPU, FPGA) also considered in both use case proposal, which gives an interesting workload to showcase some of the StarlingX characteristics: reliability, scalability and ultra-low latency. [ General Architecture ] The high level architecture [2] is compromised of the following components (naming still under review): - Core Applications - Services [ Core Applications ] Core Applications [3] give the foundation of the demo, the following have been integrated: - Home Assistant: Open Source Home Automation - InfluxDB: Time Seria Database Platform - Grafana: Data Visualization and Monitoring - Mosquitto: MQTT Message Broker - Glances: System Monitoring Tool - Portainer: Docker Environment Manager - Node-RED: Programming Tool for Hardware Devices - Netdata: Systems and Applications Monitoring - Plex: Media Server - motionEye: Video Signal Monitoring [ Services ] Services [4] are designed to perform a specific function in a specific device for a specific period of time (on demand) and will work with other micro services to form higher-level decisions, from a machine learning 'bot' service that use time-series data from the different sensors for simple control and personalization to a deep learning computer vision service that use existing network video recorder streams for video surveillance and video analytics. This demo has currently integrated samples of computer vision applications with the following services: - OpenCV (Computer Vision) - Haar Cascades - OpenVINO (Computer Vision) - Gstreamer (Video Stream) - Mjpeg- Streamer (Video Stream) - You Only Look Once (Object Detection) This demo has currently integrated the following acceleration resources: - GPU - VPU (Movidius NCS) Once demo has a solid foundation and stability with these first services, the following components are next to be integrated: - FPGA - Intel Accelerated Stack [ StarlingX Deployment ] [ Offload ] What would be the preferred way to deploy this use case proposal in StarlingX? We understand the following options are available including its preference: 1. Via Kubernetes (Not Preferred) 2. Via Virtual Machine (Preferred) 3. Via Bare Metal (Preferred) Are the above options and their preference, correct? If not, can you please give us some hints behind your answer. [ StarlingX Deployment ] [ Provisioning ] As mentioned at the beginning, another of our imperatives, is to exercise zero touch provisioning. Does it makes sense to split the provisioning in 2 parts based in the required time for the demo components to live? - The core applications 100% uptime - Services on demand / 100 uptime in some cases Is there any other cloud feature we would want consider, to take a look and use for this first version of the demo? [ StarlingX Deployment ] [ Provisioning ] [ Core Applications ] Would it make sense to create a cloud image with the core applications integrated? If not, what would be your best approach for the core applications? [ StarlingX Deployment ] [ Provisioning ] [ Services ] Since Services will be on demand, there might be some options: - Service running in containers under a virtual machine / bare metal - Services running in single virtual machines - Any other? This part is the most important for the demo since user experience might be affected (e.g. time taken for the system to start a face recognition service under camera one) [ Thanks ] We appreciate your time to read this email and your support so we can understand the best provisioning architecture for the use case proposal / demo. One of the additional things we are working on is a workshop taking this learning with the final objective to deploy in StarlingX in community events, still in an early development phase [5]. [0] https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Airc... [1] https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home [2] https://github.com/bacabhome/bacabhome [3] https://github.com/bacabhome/bacabhome/blob/master/docker-compose.yml [4] https://github.com/bacabhome/bacabhome/tree/master/services [5] http://bit.ly/SmartHomeSolution
I added some points/questions inline. On Thu, Mar 28, 2019 at 6:02 PM Arce Moreno, Abraham < abraham.arce.moreno@intel.com> wrote:
Hi StarlingX Community,
We need your advice to determine the most appropriate way to migrate an existing demo deployed via containers to StarlingX infrastructure with cloud features in mind (e.g. zero touch provisioning).
We are integrating this demo in our spare time to ramp up in cloud technologies and one of its imperatives is a working solution. It started as a use case proposal around unmanned aerial systems [0], then decided to avoid some of the complexity involved in flying the drones, and finally landed it as a use case around home automation / smart cities at the network edge.
First off, I'd like to let people know that we are planning on doing some kind of "edge" proof-of-concept with Packet.com resources, so perhaps the project you discuss could fit in with that. I'm sure we'll chat about it at some point here. At the next TSC meeting we'll discuss how to get the packet projects off the ground, so feel free to attend. :)
Three key aspects for you to consider:
- Edge computing foundation is all about “things” interchanging “data” with “servers”, same foundation when both use case proposals were envisioned.
- ”Data” will include “video streaming” pipelines, considered in both use case proposals.
- “Video streaming” pipelines will serve as an input to “machine learning / deep learning” services offloaded to different hardware (CPU, GPU, VPU, FPGA) also considered in both use case proposal, which gives an interesting workload to showcase some of the StarlingX characteristics: reliability, scalability and ultra-low latency.
[ General Architecture ]
The high level architecture [2] is compromised of the following components (naming still under review):
- Core Applications
- Services
[ Core Applications ]
Core Applications [3] give the foundation of the demo, the following have been integrated:
- Home Assistant: Open Source Home Automation
- InfluxDB: Time Seria Database Platform
- Grafana: Data Visualization and Monitoring
- Mosquitto: MQTT Message Broker
- Glances: System Monitoring Tool
- Portainer: Docker Environment Manager
- Node-RED: Programming Tool for Hardware Devices
- Netdata: Systems and Applications Monitoring
- Plex: Media Server
- motionEye: Video Signal Monitoring
[ Services ]
Services [4] are designed to perform a specific function in a specific device for a specific period of time (on demand) and will work with other micro services to form higher-level decisions, from a machine learning ‘bot’ service that use time-series data from the different sensors for simple control and personalization to a deep learning computer vision service that use existing network video recorder streams for video surveillance and video analytics.
This demo has currently integrated samples of computer vision applications with the following services:
- OpenCV (Computer Vision)
- Haar Cascades
- OpenVINO (Computer Vision)
- Gstreamer (Video Stream)
- Mjpeg- Streamer (Video Stream)
- You Only Look Once (Object Detection)
This demo has currently integrated the following acceleration resources:
- GPU
- VPU (Movidius NCS)
I would not expect a USB device like the Movidius NCS to be available in most STX deployments, but maybe?
Once demo has a solid foundation and stability with these first services, the following components are next to be integrated:
- FPGA
- Intel Accelerated Stack
[ StarlingX Deployment ] [ Offload ]
What would be the preferred way to deploy this use case proposal in StarlingX? We understand the following options are available including its preference:
1. Via Kubernetes (Not Preferred)
2. Via Virtual Machine (Preferred)
3. Via Bare Metal (Preferred)
Are the above options and their preference, correct? If not, can you please give us some hints behind your answer.
From my standpoint, I think #3 would be the least common option. #2 would be a good place to start, but I don't think #1 is "not preferred", I guess it depends on where these preferences are coming from.
[ StarlingX Deployment ] [ Provisioning ]
As mentioned at the beginning, another of our imperatives, is to exercise zero touch provisioning.
Does it makes sense to split the provisioning in 2 parts based in the required time for the demo components to live?
- The core applications 100% uptime
- Services on demand / 100 uptime in some cases
By zero touch provisioning do you just mean automation using IaaS APIs? eg. the docker compose file you link to? Or something else? Thanks, Curtis
Is there any other cloud feature we would want consider, to take a look and use for this first version of the demo?
[ StarlingX Deployment ] [ Provisioning ] [ Core Applications ]
Would it make sense to create a cloud image with the core applications integrated? If not, what would be your best approach for the core applications?
[ StarlingX Deployment ] [ Provisioning ] [ Services ]
Since Services will be on demand, there might be some options:
- Service running in containers under a virtual machine / bare metal
- Services running in single virtual machines
- Any other?
This part is the most important for the demo since user experience might be affected (e.g. time taken for the system to start a face recognition service under camera one)
[ Thanks ]
We appreciate your time to read this email and your support so we can understand the best provisioning architecture for the use case proposal / demo. One of the additional things we are working on is a workshop taking this learning with the final objective to deploy in StarlingX in community events, still in an early development phase [5].
[0] https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Unmanned_Airc...
[1] https://wiki.openstack.org/wiki/Edge_Computing_Group/Use_Cases#Smart_Home
[2] https://github.com/bacabhome/bacabhome
[3] https://github.com/bacabhome/bacabhome/blob/master/docker-compose.yml
[4] https://github.com/bacabhome/bacabhome/tree/master/services
[5] http://bit.ly/SmartHomeSolution _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
-- Blog: serverascode.com
I added some points/questions inline.
Thanks Curtis for your time!
We are integrating this demo in our spare time to ramp up in cloud technologies and one of its imperatives is a working solution. It started as a use case proposal around unmanned aerial systems [0], then decided to avoid some of the complexity involved in flying the drones, and finally landed it as a use case around home automation / smart cities at the network edge.
First off, I'd like to let people know that we are planning on doing some kind of "edge" proof-of-concept with Packet.com resources, so perhaps the project you discuss could fit in with that. I'm sure we'll chat about it at some point here.
At the next TSC meeting we'll discuss how to get the packet projects off the ground, so feel free to attend. :)
Awesome! We will be paying attention to community communications about this topic.
This demo has currently integrated the following acceleration resources: - GPU - VPU (Movidius NCS)
I would not expect a USB device like the Movidius NCS to be available in most STX deployments, but maybe?
Maybe, Movidius NCS seems to be one of one those exploration paths to offload some workloads, and where budget could make a difference in comparison with FPGAs.
[ StarlingX Deployment ] [ Offload ] What would be the preferred way to deploy this use case proposal in StarlingX? We understand the following options are available including its preference:
1. Via Kubernetes (Not Preferred) 2. Via Virtual Machine (Preferred) 3. Via Bare Metal (Preferred)
Are the above options and their preference, correct? If not, can you please give us some hints behind your answer.
From my standpoint, I think #3 would be the least common option. #2 would be a good place to start, but I don't think #1 is "not preferred", I guess it depends on where these preferences are coming from.
Understood, we think it is worth to try option 2 initially at least for the core applications of the use case.
[ StarlingX Deployment ] [ Provisioning ]
As mentioned at the beginning, another of our imperatives, is to exercise zero touch provisioning.
Does it makes sense to split the provisioning in 2 parts based in the required time for the demo components to live?
- The core applications 100% uptime - Services on demand / 100 uptime in some cases
By zero touch provisioning do you just mean automation using IaaS APIs? eg. the docker compose file you link to? Or something else?
We understand the term from its definition but that "something else" is not in our knowledge yet. From our current understanding, that zero touch provisioning will allow us to deploy with one single instruction: - The core applications part of the use case (e.g. access to the different dashboards) - The services part of the use case: the start and stop of X service (e.g. face recognition, object recognition, etc.) for each of the wanted video streams. We will appreciate if you can share any online resource where we can learn more about this zero touch concept in a practical way (e.g. whitepaper, use case) so we can land into our use case. Again, thank you Curtis for your time and help to answer our questions.
On Mon, Apr 1, 2019 at 7:43 PM Arce Moreno, Abraham < abraham.arce.moreno@intel.com> wrote:
I added some points/questions inline.
Thanks Curtis for your time!
We are integrating this demo in our spare time to ramp up in cloud technologies and one of its imperatives is a working solution. It started as a use case proposal around unmanned aerial systems [0], then decided to avoid some of the complexity involved in flying the drones, and finally landed it as a use case around home automation / smart cities at the network edge.
First off, I'd like to let people know that we are planning on doing some kind of "edge" proof-of-concept with Packet.com resources, so perhaps the project you discuss could fit in with that. I'm sure we'll chat about it at some point here.
At the next TSC meeting we'll discuss how to get the packet projects off the ground, so feel free to attend. :)
Awesome! We will be paying attention to community communications about this topic.
This demo has currently integrated the following acceleration
resources:
- GPU - VPU (Movidius NCS)
I would not expect a USB device like the Movidius NCS to be available in most STX deployments, but maybe?
Maybe, Movidius NCS seems to be one of one those exploration paths to offload some workloads, and where budget could make a difference in comparison with FPGAs.
Oh for sure, cost effective. I see what you mean.
[ StarlingX Deployment ] [ Offload ] What would be the preferred way to deploy this use case proposal in StarlingX? We understand the following options are available including its preference:
1. Via Kubernetes (Not Preferred) 2. Via Virtual Machine (Preferred) 3. Via Bare Metal (Preferred)
Are the above options and their preference, correct? If not, can you please give us some hints behind your answer.
From my standpoint, I think #3 would be the least common option. #2 would be a good place to start, but I don't think #1 is "not preferred", I guess it depends on where these preferences are coming from.
Understood, we think it is worth to try option 2 initially at least for the core applications of the use case.
[ StarlingX Deployment ] [ Provisioning ]
As mentioned at the beginning, another of our imperatives, is to exercise zero touch provisioning.
Does it makes sense to split the provisioning in 2 parts based in the required time for the demo components to live?
- The core applications 100% uptime - Services on demand / 100 uptime in some cases
By zero touch provisioning do you just mean automation using IaaS APIs? eg. the docker compose file you link to? Or something else?
We understand the term from its definition but that "something else" is not in our knowledge yet. From our current understanding, that zero touch provisioning will allow us to deploy with one single instruction:
- The core applications part of the use case (e.g. access to the different dashboards) - The services part of the use case: the start and stop of X service (e.g. face recognition, object recognition, etc.) for each of the wanted video streams.
We will appreciate if you can share any online resource where we can learn more about this zero touch concept in a practical way (e.g. whitepaper, use case) so we can land into our use case.
I'm interested in "zero touch" and I'll be doing some research over the next while. This is also potentially something that can benefit stx. This is just me talking, but I think there is a difference between zero touch and automation. To me the canonical example of ZT would be turning on a device, typically physical, and that device starts up, registers, and then is scheduled and takes on some kind of personality for whatever workload is scheduled to it, all without any human intervention. Manually initiating an automation workflow, like say a docker compose run, doesn't feel like ZT to me, but again I'm still working to define it for myself. :)
Again, thank you Curtis for your time and help to answer our questions.
No thank you, I think this is great. :) Are you going to be doing your work in the public, like in a public git repo? Thanks, Curtis -- Blog: serverascode.com
sorry for the late reply On Wed, Apr 3, 2019 at 7:21 AM Curtis <serverascode@gmail.com> wrote:
On Mon, Apr 1, 2019 at 7:43 PM Arce Moreno, Abraham <abraham.arce.moreno@intel.com> wrote:
I added some points/questions inline.
Thanks Curtis for your time!
We are integrating this demo in our spare time to ramp up in cloud technologies and one of its imperatives is a working solution. It started as a use case proposal around unmanned aerial systems [0], then decided to avoid some of the complexity involved in flying the drones, and finally landed it as a use case around home automation / smart cities at the network edge.
First off, I'd like to let people know that we are planning on doing some kind of "edge" proof-of-concept with Packet.com resources, so perhaps the project you discuss could fit in with that. I'm sure we'll chat about it at some point here.
At the next TSC meeting we'll discuss how to get the packet projects off the ground, so feel free to attend. :)
Awesome! We will be paying attention to community communications about this topic.
This demo has currently integrated the following acceleration resources: - GPU - VPU (Movidius NCS)
I would not expect a USB device like the Movidius NCS to be available in most STX deployments, but maybe?
Maybe, Movidius NCS seems to be one of one those exploration paths to offload some workloads, and where budget could make a difference in comparison with FPGAs.
Oh for sure, cost effective. I see what you mean.
[ StarlingX Deployment ] [ Offload ] What would be the preferred way to deploy this use case proposal in StarlingX? We understand the following options are available including its preference:
1. Via Kubernetes (Not Preferred) 2. Via Virtual Machine (Preferred) 3. Via Bare Metal (Preferred)
We should support either of them in my opinion, your project is a great example of cases where potential user in the future might not want to run their container apps in a vm I can take the AR of test the boundaries of what are the needs in kernel space for the latest kernel that other distributions provide. Maybe having an alternative latest LTS kernel for centos might not be that crazy after this kind of approach . Regards
Are the above options and their preference, correct? If not, can you please give us some hints behind your answer.
From my standpoint, I think #3 would be the least common option. #2 would be a good place to start, but I don't think #1 is "not preferred", I guess it depends on where these preferences are coming from.
Understood, we think it is worth to try option 2 initially at least for the core applications of the use case.
[ StarlingX Deployment ] [ Provisioning ]
As mentioned at the beginning, another of our imperatives, is to exercise zero touch provisioning.
Does it makes sense to split the provisioning in 2 parts based in the required time for the demo components to live?
- The core applications 100% uptime - Services on demand / 100 uptime in some cases
By zero touch provisioning do you just mean automation using IaaS APIs? eg. the docker compose file you link to? Or something else?
We understand the term from its definition but that "something else" is not in our knowledge yet. From our current understanding, that zero touch provisioning will allow us to deploy with one single instruction:
- The core applications part of the use case (e.g. access to the different dashboards) - The services part of the use case: the start and stop of X service (e.g. face recognition, object recognition, etc.) for each of the wanted video streams.
We will appreciate if you can share any online resource where we can learn more about this zero touch concept in a practical way (e.g. whitepaper, use case) so we can land into our use case.
I'm interested in "zero touch" and I'll be doing some research over the next while. This is also potentially something that can benefit stx. This is just me talking, but I think there is a difference between zero touch and automation. To me the canonical example of ZT would be turning on a device, typically physical, and that device starts up, registers, and then is scheduled and takes on some kind of personality for whatever workload is scheduled to it, all without any human intervention.
Manually initiating an automation workflow, like say a docker compose run, doesn't feel like ZT to me, but again I'm still working to define it for myself. :)
Again, thank you Curtis for your time and help to answer our questions.
No thank you, I think this is great. :)
Are you going to be doing your work in the public, like in a public git repo?
Thanks, Curtis
-- Blog: serverascode.com _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
participants (3)
-
Arce Moreno, Abraham
-
Curtis
-
Victor Rodriguez