Google SoC and Red Hat OSC 2020 project ideas

Hello,

after participating myself in the last year Google Summer of Code, I’d like to explore possibility of sending application for our open source group for both SoC and Red Hat Open Source Content 2020. To be able to do this, we need good list of projects, the deadline is Feb 5 but we need to have ideas collected earlier than that.

https://summerofcode.withgoogle.com/how-it-works/#timeline

https://research.redhat.com/red-hat-open-source-contest/ (site hasn’t been updated yet, deadline is mid Feb)

Please take a moment and try to find good topics, only submit them to this wiki if you intend to be a mentor for a student. Keep in mind that GSoC/OSC takes your time, from my experience I worked about 2-7 hours per week. Also make sure that the project can be well defined and will be safe for newcomer to solve, isolated work or codebase is preferred where a student is not required to have full-blown deployment of Foreman or some complex setup involving multiple VMs or complex network environment.

At this point, I would like to gather ideas with rough description. Please take your entry in the table as a full commitment. Also, submit only maximum of two projects - if there will be a student for both you will likely need to pick one or ask someone else to do mentorship. Before doing anything, I highly suggest to read the excellent Mentor Guide: https://google.github.io/gsocguides/mentor/ particularly https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html

We are still looking for a community manager, my plan is to get this running if we gather good enough topics and then hand him/her over this agenda. Unless there is a volunteer.

Title Mentor(s) Description Skills

This page is a wiki.

Modernize Foreman with Infrastucture as a Code with GitOps:

From a git repository Foreman applies resource files configuration ex:

  • ansible variable values
  • ansible roles assignment
  • hosts / content hosts groups membership
  • activation keys
  • etc

This would allow simple rollbacks, recovery in case of Foreman redeployment, increase auditability, even adding a git flow it would allow to have an approval/merge process depending on lifecycle environment/branches with merge requests.

I have found this approach for disaster availability in Kubernetes being incredibly useful. And this functionality does not have to block less advanced usage like in evironment where they only need the WebUI.

This is very insightful: https://www.weave.works/technologies/gitops/#git-iac

Applications closed February 5, 2020 when I was on my PTO. Damn, we really need a community manager.