Feedback

• Feedback
  • Pros
    • Technical
    • Non technical
  • Cons
    • Technical
    • Non technical
  • Difficulties
  • Our Vision, to Infinite and Beyond!
    • Learn
    • Feedback and next steps
    • Last words
  • Contributors

Here some feedback to Red Hat team, after spending some (fun) time on this project!

All the remarks are not in a specific order.

Pros

Technical

1. Challenge to use a full Red Hat solution

2. Challenge to work with arm64/aarch64 architecture, playing with cross-compilation

3. Pratice with containers, especially with podman + quay

   • Build images
   • Push / Pull to registries
   • Use CI/CD to automate the process

4. Play with Python and Flask, even if it was not the primary goal of that project

5. Discover Quarkus, and all its potential on edge side!

6. Finally find a real use case for our RPis @ home :)

Non technical

1. Our team is distributed, and we never have time to work on a same project. This was an opportunity for us to take some time together

2. Opportunity to enforce our Red Hat partnership

3. Find some time on innovative projects

Cons

Technical

1. Guidelines maybe too restrictive (compared to the previous public hackfest)

2. Frustrated to not work on OpenShift platform

3. No way to have debug / logs information on the DataHub platform

Non technical

1. The project was done during our free time, mostly (business first!). Then it was difficult work asynchronisly, by night, with all the team

2. We would like to have more collaboration between teams. We are 12 teams, but only few were tchating / help on the dedicated slack channel

Difficulties

1. We are OPS and not DEV, we had some skills on Pythons, but almost none on JAVA.

2. For some of us, English was a barrier and it was difficult to understand everything during the interactive exchanges like “drop-in clinic”. This language barrier did not encourage interactivity between teams.

Our Vision, to Infinite and Beyond!

Learn

Learn new useful tools to deploy multi-pro/cons projects:

• Flask
• Gunicorn
• Swagger
• Fast Api
• quay.io
• podman
• hub (github tools)
• Prometheus

and, finalky:

• Quarkus!

Yeah !

Feedback and next steps

1. (David) I think that the raspberry pi is not the best choice to do some IoT, the raspberry can be an edge gateway but not the main sensors retriever. For this example we could choose Arduino or other like ESP etc…

2. Our vision about this project it also add some metrics ON the edge (ex: via prometheus) in case of network failing, during this interruption we could always check-it in local.

3. We need also more secure flow exchange between the edge device and the poller (now it is in Http).

4. We are wondering about the benefit of using QUARKUS on Edge side, because we don’t need to scale up or provision quickly.

5. We need also more security on the edge, the OpenScap can be one of this solution? or maybe a custom image or …

6. We can also monitoring the edge (partitions, memory, process and so on …) with maybe an exporter (see defore) or a nagios like.

7. To finish, we build a quickly (in devel - not tested) ansible playbook which can be run either via Ansible Engine or Ansible AWX/Tower.

Last words

Andrea, please, change your microphone ;)

Contributors