The project has created the #pr-reviews channel on Slack as a place for you to get help with finding a reviewer for your pull request.
The Steering Committee had a public meeting last week. They discussed the audit of WGs and charters (WG-ML may be converted to a UG), and updated the SC charter. They will be contacting SIGs who need to update charters. The cloud providers will all be moved under SIG-Cloud-Provider.
They also did more to clarify SubProjects, where we need roles and contact information for each, and document User Groups, which have been added to sigs.yaml. We need more documentation around funding and resources from the CNCF and the CoC.
NEXT DEADLINE: Docs complete March 18th. Code Thaw March 19th
Last week was Week 10. This means that RC1 is due out next week, and release the week after that. All enhancements should be done, and your docs are due now.
The Release Team is considering migrating to Go 1.12.1, which would delay Code Thaw and the release; watch kubernetes-dev for warnings.
A bit of a light week thanks to code freeze, but a few PRs to look over.
Kubernetes defined. Or at least a formal declaration of what things belong in Kubernetes and which should be affiliated ecosystem projects. This specification has seen a lot of discussion from the community and will doubtless see more, but this is at least where we are today.
The upgrade to Go 1.12.1 appears to have stabilized several tests that were broken until 1.12.0. Be on the lookout for any lingering issues given the close proximity of the release.
A great addition to keep our Slack safer now that public registration is enabled again, all messages now have a context menu option to report them to the moderator team. If you’re having any issues in Slack and are unsure how to contact the moderators (you can find us in
#slack-admins), please use this new tool.
We also added a welcome bot to help new users as they join our community!
The documentation for HTTP readiness and liveness probes has always said that any HTTP response with a code between 200 and 400 would be considered a success, but until now 301 and 302 redirects have been expanded by the kubelet and queried again. As a compromise between matching the spec and not overly breaking backwards compatibility, redirects to the same hostname as used originally will still be followed, but a redirect to a new hostname will be considered a success and not followed. This may result in a loss of accuracy in some very rare cases such as clustered applications redirecting to each other. But on the plus side it improves the security of Kubernetes and closes a potential traffic amplification vector.
Last Week In Kubernetes Development (LWKD) is a product of some members of the Kubernetes project, but is not an official publication of the Kubernetes project or the CNCF. All original content is licensed Creative Commons Share-Alike, although linked content and images may be differently licensed. LWKD does collect some information on readers, see our privacy notice for details.
You may contribute to LWKD by submitting pull requests or issues on the LWKD github repo.