Add SIG Architecture Code Organization spotlight article
Frederico Muñoz
parent
402816f1ff
commit
5c1e710025
|
|
@ -0,0 +1,140 @@
|
|||
---
|
||||
layout: blog
|
||||
title: "Spotlight on SIG Architecture: Code Organization"
|
||||
slug: sig-architecture-code-spotlight-2024
|
||||
canonicalUrl:https://www.kubernetes.dev/blog/2024/04/04/sig-architecture-code-spotlight-2024
|
||||
date: 2024-04-04
|
||||
---
|
||||
|
||||
** Author: Frederico Muñoz (SAS Institute)**
|
||||
|
||||
_This is the third interview of a SIG Architecture Spotlight series that will cover the different
|
||||
subprojects. We will cover the [SIG Architecture: Code
|
||||
Organization](https://github.com/kubernetes/community/blob/master/sig-architecture/README.md#code-organization-1)_
|
||||
|
||||
In this SIG Architecture spotlight we talked with [Madhav
|
||||
Jivrajan](https://github.com/MadhavJivrajani) (VMware), a member of the Code Organization
|
||||
subproject.
|
||||
|
||||
## Introducing the Code Organization subproject
|
||||
|
||||
**Frederico (FSM)**: Hello Madhav, thank you for your availability. Could you start by telling us a
|
||||
bit about yourself, your role and how you got involved in Kubernetes?
|
||||
|
||||
**Madhav Jivrajani (MJ)**: Hello! My name is Madhav Jivrajani, I serve as a technical lead for SIG
|
||||
Contributor Experience and a GitHub Admin for the Kubernetes project. Apart from that I also
|
||||
contribute to SIG API Machinery and SIG Etcd, but more recently, I’ve been helping out with the work
|
||||
that is needed to help Kubernetes [stay on supported versions of
|
||||
Go](https://github.com/kubernetes/enhancements/tree/cf6ee34e37f00d838872d368ec66d7a0b40ee4e6/keps/sig-release/3744-stay-on-supported-go-versions),
|
||||
and it is through this that I am involved with the Code Organization subproject of SIG Architecture.
|
||||
|
||||
**FSM**: A project the size of Kubernetes must have unique challenges in terms of code organization
|
||||
-- is this a fair assumption? If so, what would you pick as some of the main challenges that are
|
||||
specific to Kubernetes?
|
||||
|
||||
**MJ**: That’s a fair assumption! The first interesting challenge comes from the sheer size of the
|
||||
Kubernetes codebase. We have ~2.2 million lines of Go code (which is steadily decreasing thanks to
|
||||
[dims](https://github.com/dims) and other folks in this sub-project!), and a little over 240
|
||||
dependencies that we rely on either directly or indirectly, which is why having a sub-project
|
||||
dedicated to helping out with dependency management is crucial: we need to know what dependencies
|
||||
we’re pulling in, what versions these dependencies are at, and tooling to help make sure we are
|
||||
managing these dependencies across different parts of the codebase in a consistent manner.
|
||||
|
||||
Another interesting challenge with Kubernetes is that we publish a lot of Go modules as part of the
|
||||
Kubernetes release cycles, one example of this is
|
||||
[`client-go`](https://github.com/kubernetes/client-go).However, we as a project would also like the
|
||||
benefits of having everything in one repository to get the advantages of using a monorepo, like
|
||||
atomic commits... so, because of this, code organization works with other SIGs (like SIG Release) to
|
||||
automate the process of publishing code from the monorepo to downstream individual repositories
|
||||
which are much easier to consume, and this way you won’t have to import the entire Kubernetes
|
||||
codebase!
|
||||
|
||||
## Code organization and Kubernetes
|
||||
|
||||
**FSM**: For someone just starting contributing to Kubernetes code-wise, what are the main things
|
||||
they should consider in terms of code organization? How would you sum up the key concepts?
|
||||
|
||||
**MJ**: I think one of the key things to keep in mind at least as you’re starting off is the concept
|
||||
of staging directories. In the [`kubernetes/kubernetes`](https://github.com/kubernetes/kubernetes)
|
||||
repository, you will come across a directory called
|
||||
[`staging/`](https://github.com/kubernetes/kubernetes/tree/master/staging). The sub-folders in this
|
||||
directory serve as a bunch of pseudo-repositories. For example, the
|
||||
[`kubernetes/client-go`](https://github.com/kubernetes/client-go) repository that publishes releases
|
||||
for `client-go` is actually a [staging
|
||||
repo](https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/client-go).
|
||||
|
||||
**FSM**: So the concept of staging directories fundamentally impact contributions?
|
||||
|
||||
**MJ**: Precisely, because if you’d like to contribute to any of the staging repos, you will need to
|
||||
send in a PR to its corresponding staging directory in `kubernetes/kubernetes`, once the code merges
|
||||
there, we have a bot called the [`publishing-bot`](https://github.com/kubernetes/publishing-bot)
|
||||
that will sync the merged commits to the required staging repositories (like
|
||||
`kubernetes/client-go`). This way we get the benefits of a monorepo but we also can modularly
|
||||
publish code for downstream consumption. PS: The `publishing-bot` needs more folks to help out!
|
||||
|
||||
For more information on staging repositories, please see the [contributor
|
||||
documentation](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/staging.md).
|
||||
|
||||
**FSM**: Speaking of contributions, the very high number of contributors, both individuals and
|
||||
companies, must also be a challenge: how does the subproject operate in terms of making sure that
|
||||
standards are being followed?
|
||||
|
||||
**MJ**: When it comes to dependency management in the project, there is a [dedicated
|
||||
team](https://github.com/kubernetes/org/blob/a106af09b8c345c301d072bfb7106b309c0ad8e9/config/kubernetes/org.yaml#L1329)
|
||||
that helps review and approve dependency changes. These are folks who have helped lay the foundation
|
||||
of much of the
|
||||
[tooling](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/vendor.md)
|
||||
that Kubernetes uses today for dependency management. This tooling helps ensure there is a
|
||||
consistent way that contributors can make changes to dependencies. The project has also worked on
|
||||
additional tooling to signal statistics of dependencies that is being added or removed:
|
||||
<code>[depstat](https://github.com/kubernetes-sigs/depstat)</code>
|
||||
|
||||
Apart from dependency management, another crucial task that the project does is management of the
|
||||
staging repositories. The tooling for achieving this (`publishing-bot`) is completely transparent to
|
||||
contributors and helps ensure that the staging repos get a consistent view of contributions that are
|
||||
submitted to `kubernetes/kubernetes`.
|
||||
|
||||
Code Organization also works towards making sure that Kubernetes [stays on supported versions of
|
||||
Go](https://github.com/kubernetes/enhancements/tree/cf6ee34e37f00d838872d368ec66d7a0b40ee4e6/keps/sig-release/3744-stay-on-supported-go-versions). The
|
||||
linked KEP provides more context on why we need to do this. We collaborate with SIG Release to
|
||||
ensure that we are testing Kubernetes as rigorously and as early as we can on Go releases and
|
||||
working on changes that break our CI as a part of this. An example of how we track this process can
|
||||
be found [here](https://github.com/kubernetes/release/issues/3076).
|
||||
|
||||
## Release cycle and current priorities
|
||||
|
||||
**FSM**: Is there anything that changes during the release cycle?
|
||||
|
||||
**MJ** During the release cycle, specifically before code freeze, there are often changes that go in
|
||||
that add/update/delete dependencies, fix code that needs fixing as part of our effort to stay on
|
||||
supported versions of Go.
|
||||
|
||||
Furthermore, some of these changes are also candidates for
|
||||
[backporting](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md)
|
||||
to our supported release branches.
|
||||
|
||||
**FSM**: Is there any major project or theme the subproject is working on right now that you would
|
||||
like to highlight?
|
||||
|
||||
**MJ**: I think one very interesting and immensely useful change that has been recently added (and I
|
||||
take the opportunity to specifically highlight the work of [Tim Hochin](https://github.com/thockin)
|
||||
on this) is the introduction of [Go workspaces to the Kubernetes
|
||||
repo](https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/4402-go-workspaces). A
|
||||
lot of our current tooling for dependency management and code publishing, as well as the experience
|
||||
of editing code in the Kubernetes repo, can be significantly improved by this change.
|
||||
|
||||
## Wrapping up
|
||||
|
||||
**FSM**: How would someone interested in the topic start helping the subproject?
|
||||
|
||||
**MJ**: The first step, as is the first step with any project in Kubernetes, is to join our slack:
|
||||
slack.k8s.io, and after that join the `#k8s-code-organization` channel. There is also a
|
||||
[code-organization office
|
||||
hours](https://github.com/kubernetes/community/tree/master/sig-architecture#meetings) that takes
|
||||
place that you can choose to attend. Timezones are hard, so feel free to also look at the recordings
|
||||
or meeting notes and follow up on slack!
|
||||
|
||||
**FSM**: Excellent, thank you! Any final comments you would like to share?
|
||||
|
||||
**MJ**: The Code Organization subproject always needs help! Especially areas like the publishing
|
||||
bot, so don’t hesitate to get involved in the `#k8s-code-organization` slack channel.
|
||||
Loading…
Reference in New Issue