jiebi/CodeConvo huggingface dataset:
Change:
## Changelog since v1.15.1 <del> **No notable changes for this release** </del> <ins> * Fix CVE-2019-11249: Incomplete fixes for CVE-2019-1002101 and CVE-2019-11246, kubectl cp potential directory traversal ([#80436](https://github.com/kubernetes/kubernetes/pull/80436)) * Fix CVE-2019-11247: API server allows access to custom resources via wrong scope ([#80750](https://github.com/kubernetes/kubernetes/pull/80750)) See also the [security announcement for this release](https://groups.google.com/forum/#!topic/kubernetes-security-announce/vUtEcSEY6SM). </ins> # v1.15.1

Discussion:
What would you like to be : The release notes state "No notable changes for this release": However it turns out these releases fix important security problems: Why is this needed: If people track releases in, for example, GitHub and then use the release notes to see what's changed, they will totally miss that important security problems have been fixed in these releases. People should not have to look in multiple places to find news of such fixes. The current practice risks people not upgrading because there were "no notable changes" and being oblivious to the risks they run.
I expect this is one for and probably others but I don't really have any clue who.
/sig release This has to do with the timing of cutting the releases vs sending the announcements. The notices were included in the announcement, but not in the generated md files. /assign can you open a PR to update those?
Looks like they put it in the email and the group, but not the release notes. !topic/kubernetes-security-announce/vUtEcSEY6SM/discussion
Just opened a PR to fix this: (I only noticed that this issue was already assigned after committing my changes, hope that's OK)
Thanks that PR looks exactly like what I'm after for this particular update!
Change:
trap cleanup EXIT SIGINT <del> kube::golang::setup_env </del> TMP_DIR=${TMP_DIR:-$(kube::realpath "$(mktemp -d -t "$(basename "$0").XXXXXX")")} ETCD_HOST=${ETCD_HOST:-127.0.0.1} ETCD_PORT=${ETCD_PORT:-2379}

Discussion:
we just log that the user should install etcd, which is impractical in an ephemeral container we actually already call installing etcd in the verify script, but we don't export it into the current PATH for the process so it doesn't work ... ref: /sig api-machinery /assign /kind bug
/triage accepted
for one possible fix
/sig etcd
Change:
fmt.Printf("%#vn", version.Get()) os.Exit(0) } else if *versionFlag == VersionTrue { <del> fmt.Printf("Kubernetes %sn", version.Get()) </del> <ins> fmt.Printf("%s %sn", programName, version.Get()) </ins> os.Exit(0) } }

Discussion:
When using the package, one can easily add a flag to a CLI tool. However, the output of invocation with is hard-coded to . As such, the package is not very usable in non-Kubernetes projects. /wg component-standard /assign
Change:
detect-master() { KUBE_MASTER=${MASTER_NAME} <ins> echo "Waiting for ${MASTER_NAME} IP Address." echo echo "  This will continually check to see if the master node has an IP address." echo </ins> KUBE_MASTER_IP=$(nova show $KUBE_MASTER --minimal | grep accessIPv4 | awk '{print $4}') <ins> while [ "${KUBE_MASTER_IP-|}" == "|" ]; do KUBE_MASTER_IP=$(nova show $KUBE_MASTER --minimal | grep accessIPv4 | awk '{print $4}') printf "." sleep 2 done echo "${KUBE_MASTER} IP Address is ${KUBE_MASTER_IP}" </ins> } # $1 should be the network you would like to get an IP address for

Discussion:
More often than not kube-up will loop forever for cluster initialization. I eventually realized it was because the script was looping forever on "https://|/api/v1beta1/pods". This happens any time Rackspace doesn't very quickly assign an IP address to the master. PR incoming with pretty rudimentary looping on the code that does the IP address lookup.
Change:
k8s.io/apimachinery/pkg/runtime/serializer/recognizer k8s.io/apimachinery/pkg/runtime/serializer/streaming k8s.io/apimachinery/pkg/runtime/serializer/versioning <ins> k8s.io/apimachinery/pkg/runtime/serializer/yaml </ins> k8s.io/apimachinery/pkg/selection k8s.io/apimachinery/pkg/types k8s.io/apimachinery/pkg/util/cache

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Add an external MetaFactory that allows for serializing multiple YAML (or JSON) files in kubeadm. The logic of marshalling YAML should be factored out from to . Why is this needed: This will allow processing component configs containing multiple documents per file. Additionally, an out-of-tree library would allow sharing this functionality with other components.
I will try work on this as carry-on from /sig cluster-lifecycle /cc
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Change:
# Verify prereqs on host machine function verify-prereqs() { # Check the OpenStack command-line clients <del> for client in swift glance nova openstack; </del> <ins> for client in swift glance nova heat openstack; </ins> do if which $client >/dev/null 2>&1; then echo "${client} client installed"

Discussion:
ci-kubernetes-e2e-gce-master-new-gci-kubectl-skew kubetest.SkewTest 2022-04-14 15:13:42 +0000 UTC The error message is It's complaining about "file contents" and not "url contents". And because this is a skew test I am assuming this is due to The fix might be to cherry pick this to 1.23. No response /sig cli
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
I've opened the cherry pick at if we decide that's the right route. The other options I can think of are to revert this change on master or to add the old environment variable back in as a file path. /assign /priority critical-urgent
Tracked the root of this to This should start passing once that merges. The cherry pick will also fix. We really need to get skew tests running on PRs.
Change:
<del> 2.14 </del> <ins> 2.15 </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : The image used in E2E tests is used for testing a wide variety of OS-agnostic features. One of these is , which runs an HTTP server with various endpoints that can be used to validate things like request/response. It would be useful to allow for 's functionality to also support HTTPS so all of that logic can be tested for TLS-based traffic. Currently, can be run like: I'm proposing something along the lines of: The default certificate/private key being basically identical to what provides. Why is this needed: One use case is where the intent is to add HTTPS functionality to lifecycle hooks (postStart/preStop). There is currently no easy way to test this logic because the container which receives the HTTPS request (in this case, ) does not support HTTPS traffic.
There are no sig labels on this issue. Please add an appropriate label by using one of the following commands: - Please see the for a listing of the SIGs, working groups, and committees available. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig testing
Change:
utilruntime.HandleError(fmt.Errorf("Unable to get pod %v/%v's service memberships: %v", oldPod.Namespace, oldPod.Name, err)) return } <del> services = determineNeededServiceUpdates(oldServices, services, podChanged) </del> <ins> services = determineNeededServiceUpdates(oldServices, services, podChangedFlag) </ins> } for key := range services {

Discussion:
This test has started failing on our e2e test suite, erroring out with "Failed to get endpoints..." https://k8s- https://k8s- Example failures https://k8s- https://k8s- cc cc
This may be related to our recently-merged endpoints change in . I'll look into it.
I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign
GitHub didn't allow me to assign the following users: joelsmith. Note that only can be assigned. <detailsIn response to : I verified that the flakiness introduced was a result of . A fix in should be merging soon. /assign Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
) func main() { <ins> klog.InitFlags(nil) </ins> flag.Usage = func() { fmt.Fprintf(os.Stderr, "Usage: %s [FLAG]... [PROFILE_DIR]...n", os.Args[0]) fmt.Fprintf(os.Stderr, "Load the AppArmor profiles specified in the PROFILE_DIR directories.n")

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --What happened: docker image built from source doesn't work with below error message, run binary doesn't work either, What you expected to happen: profile could be loaded successfully. How to reproduce it (as minimally and precisely as possible): cd test/images make all WHAT=apparmor-loader create namespace create DaemonSet with the built image check the log of the pod, kubectl logs apparmor-loader-dcbvp -n apparmor Anything else we need to know?: should init the flags in the source. Environment: Kubernetes version (use ): latest Cloud provider or hardware configuration: OS (e.g: ): all Kernel (e.g. ): all Install tools: Network plugin and version (if this is a network-related bug): Others:
There are no sig labels on this issue. Please add a sig label by either: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. See the . The in method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
Change:
} }) <del> ginkgo.It("should validate PreferredVersion for each APIGroup", func() { </del> <ins> /* Release : v1.19 Testname: Discovery, confirm the PreferredVersion for each api group Description: Ensure that a list of apis is retrieved. Each api group found MUST return a valid PreferredVersion unless the group suffix is example.com. */ framework.ConformanceIt("should validate PreferredVersion for each APIGroup", func() { </ins> // get list of APIGroup endpoints list := &metav1.APIGroupList{}

Discussion:
] 20 July 2020 [x] Two weeks soak end date: 3 August 2020 According to this APIsnoop query, there are still an endpoint which is untested. Get a list of all group /apis Iterate through list Query each endpoint List the PreferredVersion for the endpoint Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 15 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/retitle Write checkAPIGroupPreferredVersion Test +Promote - +16 Endpoint coverage
/reopen Merged /assign Ready for creation of Promotion PR
Reopened this issue. <detailsIn response to : /reopen Merged /assign Ready for creation of Promotion PR Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
return 1 fi <ins> if [[ ${GCE_PRIVATE_CLUSTER:-} == "true" ]]; then if gcloud compute routers describe --project "${NETWORK_PROJECT}" --region "${REGION}" "${NETWORK}-nat-router" &>/dev/null; then KUBE_RESOURCE_FOUND="Cloud NAT router" return 1 fi fi </ins> # No resources found. return 0 }

Discussion:
Public IPs are expensive resources. Given that we're running scalability tests on 5k-node clusters, we are unnecessarily consuming 5k IPs which is a lot. We should switch our tests so that nodes have only private IP addresses. We are going to do that by configuring NAT so that nodes can talk to outside world (e.g. to download image from dockerhub). But that also requires changing some correctness tests which assume public IPs.
To summarize recent work: setting up private gce clusters with nat, feature is gated via the env test and dashboard with correctness tests on gce private cluster - https://k8s- 27 tests fail on fixing the tests - should fix majority of them
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale /lifecycle frozen
- is there anything missing to be done here?
No, we can close this one. It was done long time ago. Thanks for catching /close
Closing this issue. <detailsIn response to : No, we can close this one. It was done long time ago. Thanks for catching Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Change:
// Create a iptables utils. execer := exec.New() <del> iptInterface = utiliptables.New(execer, protocol) </del> kernelHandler = ipvs.NewLinuxKernelHandler() ipsetInterface = utilipset.New(execer) canUseIPVS, err := ipvs.CanUseIPVSProxier(kernelHandler, ipsetInterface)

Discussion:
What happened: Currently kube-proxy cleanup not work, which will left iptables (and ipvs) rules in host and. What you expected to happen: Kube-proxy cleanup can work and not relay on hostName or ClientConnection config. How to reproduce it (as minimally and precisely as possible):
/sig network /assign
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
If this issue has been triaged, please comment . If you aren't able to handle this issue, consider unassigning yourself and/or adding the label. I am a bot run by vllry. ‍
Change:
containerRefManager, kubeDeps.Recorder) <del> tokenManager := token.NewManager(kubeDeps.KubeClient.CoreV1()) </del> <ins> tokenManager := token.NewManager(kubeDeps.KubeClient) </ins> klet.volumePluginMgr, err = NewInitializedVolumePluginMgr(klet, secretManager, configMapManager, tokenManager, kubeDeps.VolumePlugins, kubeDeps.DynamicPluginProber)

Discussion:
/kind bug /priority failing-test /priority important-critical /milestone v1.11 /assign cc All GKE jobs are failing in various release dashboards. Code freeze for 1.11 is a couple of hours away.
Common error appears to be:
Failures seem to align with when was merged. But nothing in that PR seems suspicious. Having verify. Bringing up my own cluster on head to try and get a live cluster.
I have a quick try to reproduce one of the failure test cases by gcloud container clusters create --addons=HttpLoadBalancing,HorizontalPodAutoscaling,KubernetesDashboard --machine-type=n1-standard-2 --image-type=gci --num-nodes=3 --cluster-version=1.11.0-beta.1.222+ test- The cluster isn't up. What I observed is the following: 1) kubelet on master is in crash-loop due to a panic No other master components could be up. 2) kubelet is in crashloop in node as well.
/sig node Looks like has a patch up at
/priority critical-urgent
/status approved-for-milestone
Waiting for new runs to verify the fix. Will reopen this issue if needed
/reopen Reopening this one until its actually verified to ensure it shows up in our tracking queries.
I see the GKE tests cleaning up in the . still doesn't seem to have the change (will have to wait for cutover?). The fix looks promising. Will wait for a couple more runs before I close
[MILESTONENOTIFIER] Milestone Issue Needs Attention Action required: During code freeze, issues in the milestone should be in progress. If this issue is not being actively worked on, please remove it from the milestone. If it is being worked on, please add the label so it can be tracked with other in-flight issues. Action Required: This issue has not been updated since Jun 6. Please provide an update. Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release.

</details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
all the GKE ones still look good /close
Change:
The replication controller is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](https://github.com/GoogleCloudPlatform/kubernetes/issues/492)), which would change its `replicas` field. We will not add scheduling policies (e.g., [spreading](https://github.com/GoogleCloudPlatform/kubernetes/issues/367#issuecomment-48428019)) to replication controller. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsehwere. We even plan to factor out the mechanism for bulk pod creation ([#170](https://github.com/GoogleCloudPlatform/kubernetes/issues/170)). <del> The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubecfg (run, stop, resize, rollingupdate) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc. </del> <ins> The replication controller is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run-container, stop, resize, rollingupdate) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](http://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing replication controllers, auto-scalers, services, scheduling policies, canaries, etc. </ins> ## Common usage patterns

Discussion:
It's causing problems and is kind-of GCE dependent anyway, we should just use the kubecfg binary, and document the environment variables it uses.
I think its beneficial to keep something, but remove the GCE dependent pieces, i.e. "external-ip" piece.
I put together some instructions here:
We can remove this when kubecfg is deprecated .
Reopened since it still needs to be removed. /cc
Doh. Didn't mean to declare this fixed in that PR.
Closing this (again) as it is a dupe of
Change:
func getStatsSupportedSubsystems(cgroupPaths map[string]string) (*libcontainercgroups.Stats, error) { stats := libcontainercgroups.NewStats() <del> for _, sys := range getSupportedSubsystems() { </del> <ins> for sys, required := range getSupportedSubsystems() { </ins> if _, ok := cgroupPaths[sys.Name()]; !ok { <del> return nil, fmt.Errorf("Failed to find subsystem mount for subsystem: %v", sys.Name()) </del> <ins> if required { return nil, fmt.Errorf("Failed to find subsystem mount for required subsystem: %v", sys.Name()) } // the cgroup is not mounted, but its not required so continue... glog.V(6).Infof("Unable to find subsystem mount for optional subsystem: %v", sys.Name()) continue </ins> } if err := sys.GetStats(cgroupPaths[sys.Name()], stats); err != nil { return nil, fmt.Errorf("Failed to get stats for supported subsystems : %v", err)

Discussion:
If I run first time it goes fine (after reboot). For subsequent runs I get nodes NotReady. I've tried restarting docker but that won't help. Before christams this used to work all the time. Running Arch Linux if it helps. In I see
/sig node
ditto for me: Looking for a work around I noticed that HugePages recently moved to beta. I can get pods to start again by disabling the HugePages feature gate .
/assign
cc
default Arch kernel doesn't have a hugetlb cgroup controller compiled in(been there done that, I use Arch as well), so you have to prepare your own kernel to run it.
If it were a kernel problem I would have expected the kubelet to fail the first time it was started rather than the second time. This isn't confined to Arch, though. I'm having the same problem with the default Debian kernel:
can you check if your Kernel was compiled with flag? You can do it by running: I bet we have to add documentation, describing this behavior. On Ubuntu 16.04 machine:
Sure, looks like it was not: Documentation (especially in the error message) would be great, but if the kubelet isn't going to survive a restart, I would prefer that it not start the first time. Better to fail immediately than eventually.
can you please check if works (as in fails!) for you?
No, this doesn't resolve the issue. Logs from the first start: Logs from the second start:
Do you have the directory? in that case what i have is insufficient :( If you don't have that directory, then we should probably look for a better spot to put that check? any advice?
No, that directory is missing on my system:
I'm seeing this issue as well.
I am preparing a fix to not fail when hugetlb mount is not present. Will post a fix shortly.
I posted a fix here:
Change:
Ports:     []v1.EndpointPort{}, }}, }) <ins> if !reflect.DeepEqual(originalService, service) { t.Fatalf("syncing endpoints changed service: %s", diff.ObjectReflectDiff(service, originalService)) } </ins> endpointsHandler.ValidateRequestCount(t, 1) endpointsHandler.ValidateRequest(t, testapi.Default.ResourcePath("endpoints", ns, "foo"), "PUT", &data) }

Discussion:
bug (): Originally posted by in cc /sig network /priority critical-urgent
fix in
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍