REQUEST: New membership for maelvls

[maelvls]

✅ Checklist

GitHub Username

@maelvls

Organization you are requesting membership in

kubernetes-sigs

Requirements

• I have reviewed the community membership guidelines
• I have enabled 2FA on my GitHub account
• I have subscribed to the kubernetes dev e-mail list
• I am actively contributing to 1 or more Kubernetes subprojects
• I have two sponsors that meet the sponsor requirements listed in the community membership guidelines
• I have spoken to my sponsors ahead of this application, and they have agreed to sponsor my application
• I have verified that my sponsors are from different member companies
• I have verified that my sponsors are a reviewer or an approver in at least one OWNERS file within one of the Kubernetes GitHub organizations (excluding the contributor-playground)
• OPTIONAL: I have taken the Inclusive Open Source Community Orientation course (done)

Sponsors: @vincepri, @robscott, @alvaroaleman

List of contributions to the Kubernetes project

I'd like to apply to the kubernetes or kubernetes-sigs membership in order to attend to the contributor summit at KubeCon 2022 Valencia.

I listed three contributions below. You can also look at my involvements with the Kubernetes projects and SIGs.

Contributions

Contribution 1: Cluster API (sig-cluster-lifecycle)

Sponsor: @vincepri

Back in 2020, the company I worked at used to rely and extend the Cluster API to handle fleets of Kubernetes clusters for edge deployments.

To test the platform we built on top of the Cluster API, we used the Docker backend of the Cluster API ("CAPD"), and we realized that staging images for CAPD were missing, and we had to re-build these images anytime we tested our platform. This issue was described cluster-api#3101.

My contribution was to enable building the CAPD images as part of the release process (which relied on Google Cloud Build back then). The pull request with this change, cluster-api#3177, was merged in June 2020.

Contribution 2: ingressClassName (sig-docs)

Sponsor: @robscott

When the cert-manager released 1.5 with the initial support for the Gateway API, we broke people some of the users that were relying on the HTTP-01 solver.

We realized that our assumptions about the kubernetes.io/ingress.class (by "our", I mean the cert-manager maintainers) were skewed. We thought that the value that someone would set using the annotation was sematically equivalent to the new field ingressClassName introduced in Kubernetes 1.18.

With the help of @szuecs and @iamNoah1, we wrote down the collaborative document Improving the documentation of the field ingressClassName. The document revealed various blind spots around the Ingress documentation and helped us understand how each Ingress controller deals with the annotation and the ingressClassName field.

This work led to an API improvement proposed in the pull request kubernetes#107675, which I decided to close when Noah (@iamNoah1) proposed a shorter version in kubernetes#109293. Noah's PR is still in review as of May 2022.

The next step is to open a pull request in the Kubernetes website repository to add the missing bits to the Ingress documentation page.

Contribution 3: controller-runtime (sig-api-machinery)

Sponsor: @alvaroaleman

My team and I use controller-runtime a lot across the projects we work on (both internal and open-source projects, including cert-manager).

One feature that controller-runtime offers is to be able to restrict a cache to only store the metadata on objects instead of whole objects, reducing the memory footprints of controllers. My team discovered that using the OnlyMetadata along the standard "full object" cache led to data races. This pain point is detailed in the issue controller-runtime#1660.

This discussion led to improving the API documentation of the OnlyMetadata option in the pull request controller-runtime#1747, which was merged in February 2022.

Outside contribution: GatewayAPI adoption in cert-manager (sig-network)

This is a contribution that is outside of kubernetes or kubernetes-sigs, meaning that I cannot use this contribution for the membership.

The Gateway API is an out-of-tree API that you can install on your Kubernetes cluster. The Gateway API gives you a set of new resources that have the same goal as the in-tree Ingress resource: let you do HTTP matching to proxy traffic to your pods.

cert-manager, on the other hand, is a tool many people use to issue and rene certificates in their Kubernetes cluster. A common use-case is to issue Let's Encrypt certificates. In order to issue Let's Encrypt certificates using the HTTP-01 mechanism, which most people pick when using Let's Encrypt, cert-manager needs to create temporary resources (a pod, an Ingress, and a Service) to be able to let Let's Encrypt perform the HTTP-01 challenge. Although Ingress resources are widely used, they are limited in what they can offer, and many Ingress controllers have chosen to go with their own set of custom resources.

With the challenge of adopting so many different custom resources, the cert-manager team decided to experiment with the Gateway API, which aims at covering most use-cases that the custom resources aimed to cover.

For example, the possibility of using Istio's VirtualService to solve HTTP-01 challenges is a highly requested feature (33 reactions throughout three issues), and is documented in cert-manager#3924. On the other hand, The Gateway API support was not requested much, with just two reactions on cert-manager#3920.

After deliberating in the biweekly cert-manager dev meeting (link), we decided to go ahead and add support for the Gateway API v1alpha1 in the pull request cert-manager#3920. The first version of cert-manager that supports v1alpha1 is cert-manager 1.5, released in August 2021. We moved to v1alpha2 in cert-manager 1.8, released in April 2022.

[vincepri]

+1

[alvaroaleman]

+1

[palnabarun]

@maelvls -- thank you for all your contributions so far :)

I've created PR #3405 to add you to the orgs. Once that gets merged, you should get a membership invite notification.

Welcome! 🎉

/assign

[robscott]

+1