You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: contributors/devel/running-locally.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -156,7 +156,7 @@ change the service-cluster-ip-range flag to something else.
156
156
157
157
### I cannot create a replication controller with replica size greater than 1! What gives?
158
158
159
-
You are running a single node setup. This has the limitation of only supporting a single replica of a given pod. If you are interested in running with larger replica sizes, we encourage you to try the local vagrant setup or one of the cloud providers.
159
+
You are running a single node setup. This has the limitation of only supporting a single replica of a given pod. If you are interested in running with larger replica sizes, we encourage you to try Kind or one of the cloud providers.
We would like for the Kubernetes community to settle on one preferred log message structure, that will be enforced by new klog methods. The goal of the migration is to switch C like format string logs to structured logs with explicit metadata about parameters.
15
+
We would like for the Kubernetes community to settle on one preferred log message structure and log calls as defined by [logr].
16
+
The goal of the migration is to switch C-like format string logs to structured logs with explicit metadata about parameters and
17
+
to remove the global logger in klog with a `logr.Logger` instance that gets chosen by the caller of a function.
15
18
16
19
Migration within the structured logging working group happens in two different ways - organized & non-organized.
17
20
@@ -42,6 +45,7 @@ Before sending a PR our way, please ensure that there isn't one already in place
42
45
* 1.21 Kubelet was migrated
43
46
* 1.22 Collected feedback and improved the process.
44
47
* 1.23 kube-scheduler and kube-proxy were migrated.
## Sending a Structured Logging Migration Pull Request
47
51
@@ -78,7 +82,7 @@ Migrate <directory/file> to structured logging
78
82
79
83
### Why my PR was rejected?
80
84
81
-
Even though the Kubernetes project is organizing migration of Structured Logging, this doesn't mean that we are able to accept all the PRs that come our way. We reserve the right to reject the Pull Request in situations listed below:
85
+
Even though the Kubernetes project is organizing migration of logging, this doesn't mean that we are able to accept all the PRs that come our way. We reserve the right to reject the Pull Request in situations listed below:
82
86
83
87
* Pull request is below minimum quality standards and clearly shows that author hasn't read the guide at all, for example PR just renames `Infof` to `InfoS`.
84
88
* Pull request migrates components that the owners have decided against migrating. List of those components:
@@ -168,47 +172,129 @@ type KMetadata interface {
168
172
}
169
173
```
170
174
175
+
## Contextual logging in Kubernetes
176
+
177
+
Contextual logging builds on top of structured logging because the parameters
178
+
for individual log calls are the same. The difference is that different
179
+
functions need to be used:
180
+
181
+
-`klog.ErrorS` -> `logger.Error`
182
+
-`klog.InfoS` -> `logger.Info`
183
+
-`klog.V().InfoS` -> `logger.V().Info`
184
+
185
+
In all of these cases, `logger` is a `logr.Logger` instance. `klog.Logger` is
186
+
an alias for that type. Determining where that instance comes from is the main
187
+
challenge when migrating code to contextual logging.
Copy file name to clipboardExpand all lines: contributors/guide/issue-triage.md
+4-6Lines changed: 4 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -154,16 +154,15 @@ Note that adding labels requires Kubernetes GitHub org membership. If you are no
154
154
155
155
GitHub allows you to filter out types of issues and pull requests, which helps you discover items in need of triaging. This table includes some predetermined searches for convenience:
156
156
157
-
<!--- NOTE: Table syntax is for the Hugo rendered page -->
158
-
{{< table caption="Example issue and pull request searches" >}}
|[comments-desc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc)| Busiest untriaged issues, sorted by # of comments |
165
164
|[comments-asc](https://github.com/kubernetes/kubernetes/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-asc)| Issues that need more attention, based on # of comments |
166
-
{{</ table >}}
165
+
167
166
168
167
We suggest preparing your triage by filtering out the oldest, unlabelled issues and pull requests first.
169
168
@@ -223,16 +222,15 @@ We use GitHub labels for prioritization. If an issue lacks a `priority` label, t
223
222
224
223
We aim for consistency across the entire project. However, if you notice an issue that you believe to be incorrectly prioritized, please leave a comment offering your counter-proposal and we will evaluate it.
225
224
226
-
<!--- NOTE: Table syntax is for the Hugo rendered page -->
227
-
{{< table caption="Priority labels for issues" >}}
225
+
228
226
|Priority label|What it means|Examples|
229
227
|---|---|---|
230
228
|`priority/critical-urgent`| Team leaders are responsible for making sure that these issues (in their area) are being actively worked on—i.e., drop what you're doing. Stuff is burning. These should be fixed before the next release. | user-visible bugs in core features <br> broken builds <br> tests and critical security issues |
231
229
|`priority/important-soon`| Must be staffed and worked on either currently or very soon—ideally in time for the next release. Important, but wouldn't block a release. |[**XXXX**]|
232
230
|`priority/important-longterm`| Important over the long term, but may not be currently staffed and/or may require multiple releases to complete. Wouldn't block a release. |[**XXXX**]|
233
231
|`priority/backlog`| General agreement that this is a nice-to-have, but no one's available to work on it anytime soon. Community contributions would be most welcome in the meantime, though it might take a while to get them reviewed if reviewers are fully occupied with higher-priority issues—for example, immediately before a release.|[**XXXX**]|
234
232
|`priority/awaiting-more-evidence`| Possibly useful, but not yet enough support to actually get it done. | Mostly placeholders for potentially good ideas, so that they don't get completely forgotten, and can be referenced or deduped every time they come up |
235
-
{{< /table >}}
233
+
236
234
237
235
## Step Four: Find and Set the Right SIG(s) to Own an Issue
The Mentoring Lead role is created to help upstream Kubernetes contributors to participates in various mentorship programs like [GSoC](https://github.com/kubernetes/community/blob/master/mentoring/programs/google-summer-of-code.md), [GSoD](https://github.com/kubernetes/community/blob/master/mentoring/programs/google-season-of-docs.md), [LFX Mentorship](https://github.com/kubernetes/community/blob/master/mentoring/programs/lfx-mentorship.md) and many more as an independent organisation or under Cloud Native Computing Foundation(CNCF).
6
+
7
+
## Responsibilities
8
+
The role lead should:
9
+
10
+
- Keep a calendar of dates for each program (when to submit our project name, when to submit the project scope, when selecting period is, etc) throughout the year and
11
+
- Coordinate all submissions and participation in each one
12
+
- Go to sig meetings and slack channels to proactively help with scoping and planning work / job descriptions
13
+
- Help onboard interns to the k8s specific community items like coordinate a hello for them at the k8s monthly community meeting
14
+
- Help off board interns to the k8s specific community items like demo at monthly community meeting
15
+
16
+
17
+
### Role Description
18
+
19
+
Major responsibilities includes a commitment to:
20
+
21
+
- Be proactive in information sharing, through the mailing list/slack channels, regarding various mentorship cohorts
22
+
- Be a bridge between the CNCF staff, mentors, and mentees from kubernetes project
23
+
- Be an active contributor, who could identify parts of the project that could get help from mentorship programs
24
+
- Be a go-to person for all SIGs to help them with their mentorship proposals
25
+
- Be welcoming of everyone by being your unique self
26
+
- Be inclusive on contributors, especially with new contributors joining kubernetes project as part of the mentoring process
27
+
- Be a leader of the mentoring sub-project with a commitment to its charter
28
+
29
+
### Minimum Skills and Requirements
30
+
31
+
Skills:
32
+
33
+
- Be comfortable with general GitHub workflows. You'll be working inside of multiple repositories with different workflows and helping others on the team with troubleshooting.
34
+
- Be a team player, making the project welcoming for new mentees and helping other members of the project interested to part in mentorship with the process.
35
+
- Be willing and capable of saying "no" as necessary, but try to get to a "yes, and" to help the community achieve its goals. In short, be empathetic.
36
+
- Strong written and verbal communication skills. A willingness to meet (a lot) of new people is important for this work.
37
+
38
+
Requirements:
39
+
40
+
- Member of the [Kubernetes GitHub Org]
41
+
-[Reviewer] in the mentoring folder
42
+
- Not Necessary, but a previous mentee/mentor in any of the mentorship programme is preferrable
43
+
44
+
#### Expected Time Investment
45
+
46
+
- Four hours a week as a minimal target, might be two hours more during the proposal submission perios
47
+
48
+
#### Duration
49
+
50
+
Ideally, no lead should be in the same position indefinitely. With that in mind,the project would like to see new leadership every 24 months to keep a fresh perspective.
51
+
52
+
### Becoming a Shadow
53
+
54
+
Any regular contributor to mentoring subproject can put forward their interest to the mentoring lead to become a shadow. If accepted, the objective of the council members is to nurture that shadow into a leadership position in the next 12 months.
55
+
56
+
#### Expectations of a Shadow
57
+
58
+
Consistently communicate and collaborate closely with the lead. The objective is to get you, as the shadown, to be a confident leader of the above responsibilities. Be ready to backfill for them when they are unable to attend a meeting or represent the subproject.
0 commit comments