jiebi/CodeConvo huggingface dataset:
Change:
github.com/quobyte/api # github.com/robfig/cron v1.1.0 => github.com/robfig/cron v1.1.0 github.com/robfig/cron <del> # github.com/rubiojr/go-vhd v0.0.0-20160810183302-0bfd3b39853c => github.com/rubiojr/go-vhd v0.0.0-20160810183302-0bfd3b39853c </del> <ins> # github.com/rubiojr/go-vhd v0.0.0-20200706105327-02e210299021 => github.com/rubiojr/go-vhd v0.0.0-20200706105327-02e210299021 </ins> github.com/rubiojr/go-vhd/vhd # github.com/russross/blackfriday v1.5.2 => github.com/russross/blackfriday v1.5.2 github.com/russross/blackfriday

Discussion:
I ran an OSS license scan of a codebase that has this project as a dependency and came across an interesting hit. This go-vhd dependency specified here: has a snippet of code from StackOverflow which is license under creative commons sharealike. Here's the code in question: I'm not a license expert, so I don't know if there are any real issues/conflicts here or not, but wanted to share to see what you all think. Here's SO's license info for reference: My understanding is that the potential issue would be with this clause: which could potentially require go-vhd and projects that depend on it to use the Creative Commons license as well.
Thanks for the report! can you please take a look if this is concerning? If so, we'll check if we can avoid this dependency (looks unlikely unless we duplicate what it's ) or we'll follow up upstream to update the code. /cc OWNERS for this repo
CC-BY-SA can be problematic in Apache-2.0 projects like k8s because of the ShareAlike aspect as noted. I'd recommend working with upstream to rewrite just that one function particularly since it looks like it's fairly limited.
let's please move this issue to kubernetes/kubernetes?
/provider azure
/sig release /area code-organization
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig release /area code-organization 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
cc /assign
/area code-organization
/assign
/milestone v1.19 /priority important-soon
Not a huge difference, but this is likely actually licensed under , not 4.0. See
the k/k code actually does not reference , since that function is in , do you mean we should remove from k/k totally?
Yes, we would either need to remove from k/k or ask the maintainers of to update . This means that (and k/k if we end up using it) would need to be licensed until CC-BY-SA.
Would this ultimately be backported to older versions of k8s or would you just do it in 1.19?

thanks, Let me remove the code in v1.19, actually that part of functionality is deprecated in Azure cloud provider already. My initial thought is only do this in v1.19
/kind bug /priority important-soon /sig cloud-provider /area provider/azure
Since it isn't trivial to remove as a dependency entirely (), I've created upstream to track updating the code there.
Change:
tags = ["automanaged"], deps = [ "//pkg/probe:go_default_library", <ins> "//pkg/version:go_default_library", </ins> "//vendor/github.com/golang/glog:go_default_library", "//vendor/k8s.io/apimachinery/pkg/util/net:go_default_library", ],

Discussion:
Grabbed tcpdump of a readiness probe - the src ip was the bridge address (10.244.1.1), but apart from this, there is no identifying information in the HTTP request that this is a Kubernetes daemon requesting readiness checks - this might help QoS/priority assignment by the container application.
IIUC, you mean we should add a better when kubernetes daemon request a readiness check to identify this request comes from kubernetes daemon?
Yes, we should override the default net/http user-agent with our own. Better usability for users and we have no future upgrade hazards if users start hardcoding and expecting this default User-Agent string in their analytic tools.
Any news about this one? It would be nice! I've this little hack in my nginx configuration (in order to not be spamed by health check in logs) :)
This can probably be closed now that probes have support.
Change:
import ( "fmt" <del> "reflect" </del> "time" apps "k8s.io/api/apps/v1beta1" "k8s.io/api/core/v1" "k8s.io/api/extensions/v1beta1" policy "k8s.io/api/policy/v1beta1" <ins> apiequality "k8s.io/apimachinery/pkg/api/equality" </ins> "k8s.io/apimachinery/pkg/api/errors" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/types"

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: There are too many pdb update operations compared with other resources. ! That is, there are many "Put" operations for pdb periodically in kube-apiserver log. In my view, the amount of pdb operations is connected with disruption controller's resyncPeriod and pdb's quantity in cluster. For example: disruption-controlle's default resyncPeriod is 30s, and there are 100 pdbs in cluster. We can find that the update operation times per minute is about 200. The data is reasonable, explanation is as follows: According to disruption-controlle's design, there is one resync every 30s. One resync means to call updatePdbStatus function for every pdb, so there are 200 times updatePdbStatus. Function updatePdbStatus judges whether the pdb is changed. If changed, call apiserver to update the pdb' status. When no eviction happens, disruptedPods is empty. In this situation, disruptedPods is an empty map, but pdb.Status.DisruptedPods is nil, empty map is not equal to nil. So reflect.DeepEqual(pdb.Status.DisruptedPods, disruptedPods) returns false. The pdb is thought to has be changed, then apiserver is called to update the pdb' status. In fact, there is no change for the pdb when disruptedPods is an empty map and pdb.Status.DisruptedPods is nil. What you expected to happen: There shouldn't be so many pdb update operations. That is, when pdb has no change, apiserver shouldn't be called to update its status. How to reproduce it (as minimally and precisely as possible): Create some pdbs in cluster, you will see many "Put" operations for pdb periodically in kube-apiserver log. Anything else we need to know?: Environment: kubernetes v1.13.2 Fix suggestions: The bug is caused by the mixed usage of empty and nil for disruptedPods, the type of which is map[string]metav1.Time.

There are two fix suggestions for it: one of empty map and nil for disruptedPods, use it consistently and refuse to mix empty map and nil. For example, when disruptedPods is empty or nil, save it as an empty map in etcd. Then every client gets pdb from etcd, the pdb.Status.DisruptedPods is an empty map. get pdb for etcd, assign an empty map to it if pdb.Status.DisruptedPods is nil. Maybe the mixed usage of empty and nil for map is a common problem in k8s design, not just for disruptedPods. I will propose a work around solution for the problem. If the solution has any problem, please let me know and I can modify the code.
/sig apps
/assign Morten can you PTAL and the open PR. I reviewed as well.
ref
Change:
" No preemption is performed.") } else { preemptionStartTime := time.Now() <del> sched.preempt(pod, fitError) </del> <ins> sched.preempt(fwk, pod, fitError) </ins> metrics.PreemptionAttempts.Inc() metrics.SchedulingAlgorithmPremptionEvaluationDuration.Observe(metrics.SinceInSeconds(preemptionStartTime)) metrics.DeprecatedSchedulingAlgorithmPremptionEvaluationDuration.Observe(metrics.SinceInMicroseconds(preemptionStartTime))

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : When preempting a pod that is a that permit plugins are waiting for , we need send a message(actually send a ) to the , otherwise permit plugins might wait until time out, and do not know the pod has been preempted. Why is this needed: /sig scheduling /kind cleanup /assign
cc
Interesting interaction between the permit and preempt, I will take a look at the PR you sent, thanks!
Change:
By("deleting host1Pod") framework.ExpectNoError(podClient.Delete(host1Pod.Name, api.NewDeleteOptions(0)), "Failed to delete host1Pod") <ins> By("Test completed successfully, waiting for PD to safely detach") waitForPDDetach(diskName, host0Name) waitForPDDetach(diskName, host1Name) </ins> return })

Discussion:
PD E2E tests have very aggressive clean up routine that does not wait for volumes to safely detached. After the test completes, the test cleanup routine unilaterally detaches the PD (instead of waiting for k8s to do it cleanly). Although this does not cause the test to fail, it results in errors in the kernel logs: We should modify these tests to wait for k8s to safely detach the disk.
Change:
- source_hash: {{ etcd_tar_hash }} - archive_format: tar - if_missing: /usr/local/src/etcd-{{ etcd_version }}-linux-amd64 <ins> {% if grains['saltversioninfo'] <= (2014, 7, 0, 0) %} </ins> - tar_options: xz <ins> {% endif %} </ins> file.directory: - name: /usr/local/src/etcd-{{ etcd_version }}-linux-amd64 - user: root

Discussion:
I now see this in /var/log/salt/minion I think this is the problem: (They just pushed a new version of SaltStack, 2014.7.1 which includes the issue) I think it's an easy fix; we just change the options from "xz" to "z". PR on its way...
Ugh... even after changing xz -z, that exposes another bug where salt messed up quoting: If we don't pass tar_options at all, there is yet another code path, which isn't broken but uses the built-in Python tarfile library to extract the tar file. I think that's our only option, unless we want to revert to the old saltstack until the new one becomes stable.
Appears fixed.
Change:
for _, ipInfo := range apiPodStatus.PodIPs { podStatus.IPs = append(podStatus.IPs, ipInfo.IP) } <ins> if len(podStatus.IPs) == 0 && len(apiPodStatus.PodIP) > 0 { podStatus.IPs = []string{apiPodStatus.PodIP} } </ins> // Record the time it takes for the pod to become running. existingStatus, ok := kl.statusManager.GetPodStatus(pod.UID) if !ok || existingStatus.Phase == v1.PodPending && apiPodStatus.Phase == v1.PodRunning &&

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: is unset on a networking daemonset pod used by (read via the downward api). Previously this was reliably set to match the hostIP. What you expected to happen: This should be the hostIP (which is set). How to reproduce it (as minimally and precisely as possible): We know the kind CI tests cover this ,%20master%20(dev)%20%5Bnon-serial%5D&show-stale-tests=&width=5 Anything else we need to know?: This is also tracked in , we observed this change in Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig network /cc /priority important-soon
/assign
Change:
label := labels.SelectorFromSet(labels.Set(map[string]string{"name": name})) pods, err := podsCreated(f.Client, f.Namespace.Name, name, replicas) <ins> Expect(err).NotTo(HaveOccurred()) </ins> By("Ensuring each pod is running")

Discussion:
This might be fixed, haven't reproduced on latest upstream source. But in any case, I thought I'd create the issue. bug = i assume any failure in e2es shouldnt be b/c of a panic. ... I noticed a failure on Openshift today, which I think alludes to a possible issue in replica sets.
cc
cc
Yup, looks like a bug, and it looks like it's still there. The isn't checked, so can be nil, which will cause the panic on L102. cc
i think the iterators should be declarative here i.e. ? thats a better fix .... (update : nvm, i think its fine as is, just add a nil check: Because, the declarative won't work for the entire test, since the function for checking pod name responses requires a full )
Cc
Thanks, Jay. Even with this change, the test would have failed, so we should still debug the cause.
It seems we don't check err here: if return an error, will be nil.
Yup.... that is fixed in the PR, right?
Change:
return ioutil.NopCloser(bytes.NewReader([]byte(body))) } <ins> // TODO(jlowdermilk): refactor the Factory so we can test client versions properly, // with different client/server version skew scenarios. </ins> // Verify that resource.RESTClients constructed from a factory respect mapping.APIVersion <del> func TestClientVersions(t *testing.T) { f := cmdutil.NewFactory(nil) version := testapi.Version() mapping := &meta.RESTMapping{ APIVersion: version, } c, err := f.RESTClient(mapping) if err != nil { t.Errorf("unexpected error: %v", err) } client := c.(*client.RESTClient) if client.APIVersion() != version { t.Errorf("unexpected Client APIVersion: %s %v", client.APIVersion, client) } } </del> <ins> //func TestClientVersions(t *testing.T) { //	f := cmdutil.NewFactory(nil) // //	version := testapi.Version() //	mapping := &meta.RESTMapping{ //		APIVersion: version, //	} //	c, err := f.RESTClient(mapping) //	if err != nil { //		t.Errorf("unexpected error: %v", err) //	} //	client := c.(*client.RESTClient) //	if client.APIVersion() != version { //		t.Errorf("unexpected Client APIVersion: %s %v", client.APIVersion, client) //	} //} </ins> func ExamplePrintReplicationController() { f, tf, codec := NewAPIFactory()

Discussion:
This seems like a bug to me No output, and command exits success... wat. Have to explicitly pass to see expected output. If the client version is greater the server version, it should be making requests based on the server's newest accepted apiversion.
cc
Change:
t.Errorf("Expected %v, but got %v", e, a) } <ins> // Test a scheme + name + port (using second ip). location, _, err = redirector.ResourceLocation(ctx, "https:foo-second-ip:p") if err != nil { t.Errorf("Unexpected error: %v", err) } if location == nil { t.Errorf("Unexpected nil: %v", location) } if e, a := "https://[2001:db7::]:93", location.String(); e != a { t.Errorf("Expected %v, but got %v", e, a) } </ins> // Test a non-existent name + port. location, _, err = redirector.ResourceLocation(ctx, "foo:q") if err == nil { t.Errorf("Unexpected nil error") } <ins> // Test a non-existent name + port (using second ip). location, _, err = redirector.ResourceLocation(ctx, "foo-second-ip:q") if err == nil { t.Errorf("Unexpected nil error") } </ins> // Test error path if _, _, err = redirector.ResourceLocation(ctx, "bar"); err == nil { t.Errorf("unexpected nil error")

Discussion:
Hi, I have a issue with a dualstack cluster for my Kubernetes Dashboard deployment. I opened a ticket here (), but I am informed that it is not related to Kubernetes Dashboard. What is the problem? Errors in kube-api: The service is created with the correct ipFamily (=IPv6). My endpoint is fully in IPv6. Indeed, my pod has one IP in IPv4 and another in IPv6. Do you have also the issue? Kubernetes version: 1.18 OS: RHEL7
/sig network /sig api-machinery
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think the following should fix the error you saw:
/remove-sig api-machinery
Change:
errs = append(errs, "must contain only alpha-numeric characters (a-z, 0-9), and hyphens (-)") } if !portNameOneLetterRegexp.MatchString(port) { <del> errs = append(errs, "must contain at least one letter or number (a-z, 0-9)") </del> <ins> errs = append(errs, "must contain at least one letter (a-z)") </ins> } if strings.Contains(port, "--") { errs = append(errs, "must not contain consecutive hyphens")

Discussion:
The only support at least one letterbut the error message is at least one letter or number. It will be error if portname only numbers, ex: '1-2' or '1' or '123'. Fix the error message or regex syntax No response at least 1.19+ None <details</details<details</details<details</details<details</details
/sig api-machinery
I would like to take up this issue. /assign
/triage accepted
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
Change:
"type": "array" }, "operations": { <del> "description": "Operations is the operations the admission hook cares about - CREATE, UPDATE, or * for all operations. If '*' is present, the length of the slice must be one. Required.", </del> <ins> "description": "Operations is the operations the admission hook cares about - CREATE, UPDATE, DELETE, CONNECT or * for all of those operations and any future admission operations that are added. If '*' is present, the length of the slice must be one. Required.", </ins> "items": { "type": "string" },

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: Working on other doc bugs, I went looking for what calls admission plugins. I found four call sites for validating plugins, documented in . They correspond to the verbs CONNECT, CREATE, DELETE, and UPDATE. But only two of those verbs are documented at What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
Looks like docs are correct in and
The API doc can be updated to call out all four operations and clarify that "all" means "all four admission operations"
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue </details
/assign
Change:
<ins> #!/bin/bash # Copyright 2014 Google Inc. All rights reserved. # # Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # #     http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. # Bring up a Kubernetes cluster. # # If the full release name (gs://<bucket>/<release>) is passed in then we take # that directly.  If not then we assume we are doing development stuff and take # the defaults in the release config. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. KUBE_CONFIG_FILE="config-default.sh" ${KUBE_ROOT}/hack/ginkgo-e2e.sh --ginkgo.focus=Networking </ins>  No newline at end of file

Discussion:
Compare requestdurationseconds, requestterminationstotal, requestabortstotal API server metrics between the two runs. The acceptable delta should be less than 20%. xref:
/sig auth /triage accepted
/assign ritazh /milestone v1.29
Change:
// BlockStorageOpts is used to talk to Cinder service type BlockStorageOpts struct { <del> BSVersion       string `gcfg:"bs-version"`        // overrides autodetection. v1 or v2. Defaults to auto TrustDevicePath bool   `gcfg:"trust-device-path"` // See Issue #33128 IgnoreVolumeAZ  bool   `gcfg:"ignore-volume-az"` </del> <ins> BSVersion             string `gcfg:"bs-version"`        // overrides autodetection. v1 or v2. Defaults to auto TrustDevicePath       bool   `gcfg:"trust-device-path"` // See Issue #33128 IgnoreVolumeAZ        bool   `gcfg:"ignore-volume-az"` NodeVolumeAttachLimit int    `gcfg:"node-volume-attach-limit"` // override volume attach limit for Cinder. Default is : 256 </ins> } // RouterOpts is used for Neutron routes

Discussion:
We merged to allow configurable volume limits for Cinder. But proposed adding such a limit to as well, among other things this will enable us to support node specific limits more easily - /sig openstack /sig storage /sig scheduling
/assign
cc
/kind feature
This will require updating in-tree Openstack cloudprovider code. are we onboard with that?
What would be the extent of the modification? It must not break current compatibility, and the in-tree provider is scheduled for removal this year. I'm ok with it as long as existing users aren't broken by it.
it should be a change into which would add a new configurable field. It would be backward compatible but would allow admins to configure different limits on a node if they must.
/milestone v1.14 We're entering and this looks relevant to the 1.14 release. Please if I am incorrect
Change:
authenticator := union.New(authenticators...) <del> authenticator = group.NewGroupAdder(authenticator, []string{user.AllAuthenticated}) </del> <ins> authenticator = group.NewAuthenticatedGroupAdder(authenticator) </ins> if config.Anonymous { // If the authenticator chain returns an error, return an error (don't consider a bad bearer token anonymous).

Discussion:
When an auth proxy tries to proxy an anonymous request, the user.Info ends up with the group system:authenticated, which is wrong.
Change:
// Get exist taints of node. nodeTaints := taintutils.TaintSetFilter(node.Spec.Taints, func(t *v1.Taint) bool { <ins> // only NoSchedule taints are candidates to be compared with "taints" later if t.Effect != v1.TaintEffectNoSchedule { return false } </ins> // Find unschedulable taint of node. if t.Key == algorithm.TaintNodeUnschedulable { return true

Discussion:
In autoscaling tests, we verify that when a node suddenly disappears from the cluster, Cluster Autoscaler will add another one to replace it. With TaintNodesByCondition (enabled by default in ), this is now failing: https://k8s- Every time a node disappears, a subset of pods become NodeLost and aren't rescheduled on a new node. /cc /sig node
I can work on this.
just got merged. Let's check result of autoscaling testings tomorrow: https://k8s-
latest autoscaling testing is green. I think we can close this issue.
Thanks for fixing this!