Build a notification system/process to report conversion results

[LiorLieberman]

What would you like to be added:
A new notification system/mechanism/process to notify users conversion results, warnings and crucial messages regarding their conversion.

Ideally, this should be a generic notification mechanism that is able to support different types of notifications/messages and present them nicely.

Why this is needed:
As we onboard more implementations and add more logic, the logs are not sufficient to report such a thing. And in order to improve the usability users should know exactly the original resource/s -> new resource/s mapping plus what the tool couldn't convert so they could make the final touches before applying the new resources to the cluster.

Among the things it can include are:

• Overview of original resources and the equivalent resources they have been converted to
• Warnings on partial conversions (partial fields within a resource)
• Warnings in case a new resource does not(or can not) retain the exact same semantics. For example a different default redirect code, semantics around * and empty host fields, etc.
• Warnings about fields/logics not supported in Gateway API
• Warnings about fields/logics not supported by the tool BUT are supported by Gateway API

[Ishad-M-I-M]

Hello @LiorLieberman @mlavacca, I'm intereseted on working for this Idea for GSoC'24. I started learning golang and somewhat familiar with kubernetes. I appriciate if you can provide further resources and instructions on how to get started with this project.
Thank you in advance!.

[Devaansh-Kumar]

Hello everyone, I am Devaansh Kumar and I also interested in applying for this project under GSoC'24. I have a basic knowledge of golang and would love to discuss the requirements of the project.

[YIHONG-JIN]

Hi there, I am Yihong Jin, and interested in working on this issue for GSoC'24 as well. I have experience in Golang and have tried ingress2gateway for research projects. Is this project supposed to be an incremental patch to ingress2gateway which enhance its usability?

Regarding the notification mechanism, are we trying to build an active mechanism (forced human intervention) or a passive mechanism (aggregate the warnings and generate a report)?

[LiorLieberman]

Thank you all for expressing your interest.
Brief requirements are more or less what appear in the description.

Some useful resources you could start with are:

1. Familiarize yourself with Gateway API
2. If you are not familiar with ingress, read about this it here
3. Read about different ingress and gateway implementations. Here is a detailed list of projects that implement gateway api.

@YIHONG-JIN regarding your question - to start with, it will be aggregated report (ideally per provider,object,fieldPath) to indicate:

1. what where the errors/warnings
2. where we couldnt convert
3. where we could convert only partially
4. Where the logic of the newly converted resource is similar but not 100% the same (for example cases where default status code redirect is different)
5. ...

[prakrit55]

Hey @LiorLieberman, I am interested in solving the issue for GSOC'24, I have experiences with golang and kubernetes, and contributed to multiple projects before. Thank you.

[z1ens]

Hello, I am Zhe Shen, a third year undergraduate in Germany and also interested in this project, I have experience with Golang and also Kubernetes, recently I build a project with my classmates: develop a FaaS which its functionalities similar to OpenFaaS , using Kubernetes API gateway as the main entry point, and associated with Sawgger UI.
I am currently reading different Ingress and Gateway implementations, really looking forward to make contributions!
Have a nice day!

[Thisausername99]

Hi, I am Cody Hoang, I am interested in the prospect of building this notification report system for GSOC'24. I have industrial experience with Go, and fundamental understanding of K8s. In the past, I developed a conversion reporting pipeline in Go, facilitating comparison between new services and soon-to-be-replaced ones. I am currently going over the relevant documentations regarding Ingress and Gateway implementations, and their applications. I am looking forward to bringing this system to live, and assisting the expansion of ingress2gateway!

[LiorLieberman]

/assign @Devaansh-Kumar

[Devaansh-Kumar]

This is the document outlining the design of the project: https://docs.google.com/document/d/1xQfatXNs2boohEXLw_jGi1OMmdWy3hW-yEWHRZzq2JY/edit?usp=sharing

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[mlavacca]

/remove-lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[LiorLieberman]

/remove-lifecycle rotten

@Devaansh-Kumar is this done?

[Devaansh-Kumar]

Only these two PRs are left to be merged: #180 #181