# kubernetes-sigs membership application for [maelvls](https://github.com/maelvls/) | 🚧 The org application is now live: [kubernetes/org#3403](https://github.com/kubernetes/org/issues/3403) | |--| 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](https://github.com/search?q=org%3Akubernetes+or+org%3Akubernetes-sigs+involves%3Amaelvls&type=Issues) with the Kubernetes projects and SIGs. ## Contributions ### Contribution 1: Cluster API (sig-cluster-lifecycle) > **Sponsor:** [@vincepri](https://github.com/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](https://github.com/kubernetes-sigs/cluster-api/issues/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](https://github.com/kubernetes-sigs/cluster-api/pull/3177), was merged in June 2020. ### Contribution 2: ingressClassName (api-docs) > **Sponsor:** [@robscott](https://github.com/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](https://github.com/szuecs) and [@iamNoah1](https://github.com/iamNoah1), we wrote down the collaborative document [Improving the documentation of the field ingressClassName](https://docs.google.com/document/d/11YrnTqale4ICnR9SFMttCoRL4-NEvQJookNfFb3QjYA/edit). 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](https://github.com/kubernetes/kubernetes/pull/107675), which I decided to close when Noah ([@iamNoah1](https://github.com/iamNoah1)) proposed a shorter version in [kubernetes#109293](https://github.com/kubernetes/kubernetes/pull/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](https://kubernetes.io/docs/concepts/services-networking/ingress/). ### Contribution 3: controller-runtime (sig-api-machinery) > **Sponsor:** [@alvaroaleman](https://github.com/alvaroaleman) My team and I use [controller-runtime](https://github.com/kubernetes-sigs/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](https://github.com/kubernetes-sigs/controller-runtime/issues/1660). This discussion led to improving the API documentation of the `OnlyMetadata` option in the pull request [controller-runtime#1747](https://github.com/kubernetes-sigs/controller-runtime/pull/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. [@robscott](https://github.com/robscott) would sponsoring this one. 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](https://github.com/cert-manager/cert-manager/issues/3924). On the other hand, The Gateway API support was not requested much, with just two reactions on [cert-manager#3920](https://github.com/cert-manager/cert-manager/issues/3920). After deliberating in the biweekly cert-manager dev meeting ([link](https://docs.google.com/document/d/1Tc5t6ylY9dhXAan1OjOoldeaoys1Yh4Ir710ATfBa5U/edit#bookmark=id.vrkt9nt01bkk)), we decided to go ahead and add support for the Gateway API v1alpha1 in the pull request [cert-manager#3920](https://github.com/cert-manager/cert-manager/issues/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. ## Checklist progress - [x] Enabled [two-factor authentication] on their GitHub account - [x] Have made multiple contributions to the project or community. Contribution may include, but is not limited to: - [x] Authoring or reviewing PRs on GitHub. At least one PR must be **merged**. - [x] Filing or commenting on issues on GitHub (see below section) - [x] Contributing to SIG, subproject, or community discussions (e.g. meetings, Slack, email discussion forums, Stack Overflow) - [x] Subscribed to [dev@kubernetes.io] - [x] Have read the [contributor guide] - [x] Actively contributing to 1 or more subprojects. - [ ] Sponsored by 2 reviewers. **Note the following requirements for sponsors**: - Sponsors must have close interactions with the prospective member - e.g. code/design/proposal review, coordinating on issues, etc. - Sponsors must be reviewers or approvers in at least one OWNERS file within one of the [Kubernetes GitHub organizations]*. - Sponsors must be from multiple member companies to demonstrate integration across community. - [ ] **[Open an issue][membership request] against the kubernetes/org repo** - Ensure your sponsors are @mentioned on the issue - Complete every item on the checklist ([preview the current version of the template][membership template]) - Make sure that the list of contributions included is representative of your work on the project. - [ ] Have your sponsoring reviewers reply confirmation of sponsorship: `+1` Once your sponsors have responded, your request will be reviewed by the [Kubernetes GitHub Admin team], in accordance with their [SLO]. Any missing information will be requested. [code reviews]: /contributors/guide/expectations.md#code-review [community expectations]: /contributors/guide/expectations.md [contributor guide]: /contributors/guide/README.md [Kubernetes GitHub Admin team]: /github-management/README.md#github-administration-team [Kubernetes GitHub organizations]: /github-management#actively-used-github-organizations [Kubernetes org]: https://github.com/kubernetes [dev@kubernetes.io]: https://groups.google.com/a/kubernetes.io/group/dev [kubernetes-sigs]: https://github.com/kubernetes-sigs [membership request]: https://github.com/kubernetes/org/issues/new?assignees=&labels=area%2Fgithub-membership&template=membership.yml&title=REQUEST%3A+New+membership+for+%3Cyour-GH-handle%3E [membership template]: https://github.com/kubernetes/org/blob/main/.github/ISSUE_TEMPLATE/membership.yml [Contributor Playground repository]: https://github.com/kubernetes-sigs/contributor-playground [New contributors]: /CONTRIBUTING.md [OWNERS]: /contributors/guide/owners.md [sigs.yaml]: /sigs.yaml [SLO]: /github-management/org-owners-guide.md#slos [two-factor authentication]: https://help.github.com/articles/about-two-factor-authentication [elevated set of permissions]: #Responsibilities-and-privileges [Devstats project]: https://k8s.devstats.cncf.io/