jiebi/CodeConvo huggingface dataset:
Change:
"net/url" "os" "path" <ins> sysruntime "runtime" </ins> "sort" "strings" "sync"

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: If I have the a psp with apparmor annotations: and I deploy a windows pod it gets blocked: What you expected to happen: Apparmor check is ignored for windows pods How to reproduce it (as minimally and precisely as possible): see above Anything else we need to know?: Should be fixed/documented with work around as per Environment: Kubernetes version (use ): kubectl version Client Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-06-26T03:47:41Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"18", GitVersion:"v1.18.5", GitCommit:"", GitTreeState:"clean", BuildDate:"2020-06-26T19:51:26Z", GoVersion:"go1.13.6", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g: ): windows/unbuntu Kernel (e.g. ): Install tools: aks-engine Network plugin and version (if this is a network-related bug): Others:
/sig windows
/assign I can fix it, it may take some time
I don't actually see anything in that suggests we should ignore windows nodes for apparmor. Can you link to it?
That issue doesn't have guidance explicitly, was more about the need for someone to look into it. I did some investigation with outcomes on the comment and the spread sheet has each PSP detailed with what applies to windows as of now:
Change:
// based on cached predicate results func (ec *EquivalenceCache) PredicateWithECache( podName, nodeName, predicateKey string, <del> equivalenceHash uint64, </del> <ins> equivalenceHash uint64, needLock bool, </ins> ) (bool, []algorithm.PredicateFailureReason, bool) { <del> ec.RLock() defer ec.RUnlock() </del> <ins> if needLock { ec.RLock() defer ec.RUnlock() } </ins> glog.V(5).Infof("Begin to calculate predicate: %v for pod: %s on node: %s based on equivalence cache", predicateKey, podName, nodeName) if algorithmCache, exist := ec.algorithmCache[nodeName]; exist {

Discussion:
Fix this TODO (raised by : Part of: One thoughts to fix this is, we can redesign the equivalence cache data structure to: bool instead of deleting the entry. certain version tag in the entry, update the version per WRITE op (Update and Invalidate). the version after eCache predicate, and check it before update eCache.
Another possible approach is: eCache before running a predicate. the predicate. the eCache for the predicate. eCache. Basically, in the existing code all predicates are run first and their results are collected and then at the end of the function the eCache is updated. Instead of that, we can move the eCache update for each predicate inside the for loop and next to each predicate execution and synchronize before start of the execution of each predicate. The downside to my suggested approach is that performance may suffer due to frequent locking and unlocking.
Prefer to bsalamat@ 's option which is simpler :). Comparing to performance improvement by eCache, the lock is acceptable to me.
yup same here, going with the locking is easier and is acceptable. - also using a flag for invalidation might just move the problem from eCache to the flag ?
Oh I missed this notification somehow, busy on cleaning scheduler integration test. Yep so if locking is acceptable, it should be cleanest way to fix this, optimistic control would be a more complicated story.
- are you handling this one ?
Already been taken by volunteer days ago :)
Change:
return } } klog.V(4).Infof("updatePod %s/%s for node %s", pod.Namespace, pod.Name, pod.Spec.NodeName) <ins> startTime := time.Now() </ins> g.graph.AddPod(pod) <ins> klog.V(5).Infof("updatePod %s/%s for node %s completed in %v", pod.Namespace, pod.Name, pod.Spec.NodeName, time.Since(startTime)) </ins> } func (g *graphPopulator) deletePod(obj interface{}) {

Discussion:
Log statements and metrics indicating when the node authorizer graph has be updated for a pod. There is already a log statement for when the graph starts an update, but this is before the graph lock is obtained and doesn't tell when the graph update is completed. We are seeing node authorizer failures which prevent pods from starting for extended periods of time. It is believed that this is caused by a race between: the node authorizer graph being updated the node requesting the secret It is important to have logging that indicates when the graph finished updating in order to reflect lock contention on the graph.
/sig auth
/triage accepted Seems like a reasonable feature request.
Hi, folks I would like to work on this. /assign
Hi Fixed this issue here PTAL!
Change:
if err := kubeoptions.DefaultAdvertiseAddress(s.GenericServerRunOptions, s.InsecureServing); err != nil { return err } <del> _, apiServerServiceIP, err := master.DefaultServiceIPRange(s.ServiceClusterIPRange) </del> <ins> serviceIPRange, apiServerServiceIP, err := master.DefaultServiceIPRange(s.ServiceClusterIPRange) </ins> if err != nil { return fmt.Errorf("error determining service IP ranges: %v", err) } <ins> s.ServiceClusterIPRange = serviceIPRange </ins> if err := s.SecureServing.MaybeDefaultWithSelfSignedCerts(s.GenericServerRunOptions.AdvertiseAddress.String(), []string{"kubernetes.default.svc", "kubernetes.default", "kubernetes"}, []net.IP{apiServerServiceIP}); err != nil { return fmt.Errorf("error creating self-signed certificates: %v", err) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Running kube-apiserver without specifing "--service-cluster-ip-range" will print “no --service-cluster-ip-range specified” and exit. But it provide a default value "10.0.0.0/24". Do we need remove validation of --service-cluster-ip-range specified? What you expected to happen: Since we have provided the default value '10.0.0.0/24', user need not to specify --service-cluster-ip-range in command line. How to reproduce it (as minimally and precisely as possible): Run kube-apiserver without "--service-cluster-ip-range". kube-apiserver --etcd-servers="http://localhost:2379" --storage-backend="etcd2" Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.0.572+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-13T05:45:41Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.0.584+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-09-13T08:56:26Z", GoVersion:"go1.8.3", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ):4.10.0-33-generic Install tools: Others:
/sig api-machinery
I think the problem is that we do not set the default value for the ServiceClusterIPRange, we can see the code: and so the validation will fail.
No, it had set the default value in
We can see the execution sequence In the function we do not set the value and then we go to the function ,so there is something wrong. And the Line you point out is for construct . Maybe there is a little confusion.

So, I think why we must validate service-cluster-ip-range specificaiton which have been provided a default value after validation: )
I first think there may other use for Validate and ServiceClusterIPRange, So we can directly set the value for ServiceClusterIPRange and should not use DefaultServiceIPRange everywhere. I think you PR may be better
cc
Change:
# Starts cluster autoscaler. function start-cluster-autoscaler { <del> if [[ "${ENABLE_NODE_AUTOSCALER:-}" == "true" || "${ENABLE_CLUSTER_AUTOSCALER:-}" == "true" ]]; then </del> <ins> if [[ "${ENABLE_CLUSTER_AUTOSCALER:-}" == "true" ]]; then </ins> echo "Start kubernetes cluster autoscaler" prepare-log-file /var/log/cluster-autoscaler.log

Discussion:
In kube-up we use var while in GKE, documentation, issues etc I think we call it cluster autoscaler. We should make it consistent.
I assume this is what you were already thinking, but: I think we should change it to cluster autoscaler (everywhere). You scale the cluster by adding/removing nodes. You scale a node by adding/removing resources to/from the node, so node autoscaler isn't the right term IMO.
Change:
func main() { rootCmd := &cobra.Command{ Use:     "app", <del> Version: "2.25", </del> <ins> Version: "2.26", </ins> } rootCmd.AddCommand(auditproxy.CmdAuditProxy)

Discussion:
<!-- STOP -- PLEASE READ! GitHub is not the right place for support requests. If you're looking for help, check the or our . You can also post your question on the or the forum. If the matter is security related, please disclose it privately via --s390x support for nonewprivs image was in and the commit from was cherry picked in to fix agnhost broken on s390x. However, the post merge job failed for both( ) as image builder was broken. Now that image builder has been fixed in , these jobs need to be restarted to push s390x tags of agnhost and nonewprivs in staging bucket. cc
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
/sig testing
as you are on call this week, can you please run the CI job mentioned by hand?
, when I try to run the job with , it failed with . So I went over and looked at the history and found that this job was deleted by on 11/11. I don't think prow allows running a job that doesn't exist in its configmap, and searching the prow history with got: This is the list of jobs that have ever ran since prow keeps all history in GCS, which indicates that not all of the new jobs in has ran yet, can you take a look at and let us know which job is that you want?
thanks for looking. let's ask what jobs need to be triggered.
Hello, The post-kubernetes-push-e2e-test-images has been split into individual jobs for individual images and are now triggered by changes made in that image's folder. The jobs haven't been run yet since the split. You can trigger a job by sending a PR (e.g.: bumping the VERSION) and getting it merged.
/reopen Still failing according should fix it.
Reopened this issue. <detailsIn response to : /reopen Still failing according should fix it. 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
/close I am closing this issue as the agnhost job passed and the multiarch image is now available, it works fine for s390x as conformance job passed with the same
Closing this issue. <detailsIn response to : /close I am closing this issue as the agnhost job passed and the multiarch image is now available, it works fine for s390x as conformance job passed with the same 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:
reviewers: - sig-instrumentation-reviewers labels: <del> - sig/gcp </del> <ins> - area/provider/gcp </ins> - sig/instrumentation

Discussion:
Some owners files attempt to auto apply the no longer existing label, which is now : This is present in 4 owners files: /assign /area oncall-hotlist
/sig cloud-provider
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
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Change:
ptrLookup := fmt.Sprintf("%s.in-addr.arpa.", strings.Join(reverseArray(strings.Split(ptrLookupIP, ".")), ".")) ptrRecByUDPFileName := fmt.Sprintf("%s_udp@PTR", ptrLookupIP) ptrRecByTCPFileName := fmt.Sprintf("%s_tcp@PTR", ptrLookupIP) <del> probeCmd += fmt.Sprintf(`test -n "$$(dig +notcp +noall +answer +search %s PTR)" && echo OK > /results/%s;`, ptrLookup, ptrRecByUDPFileName) probeCmd += fmt.Sprintf(`test -n "$$(dig +tcp +noall +answer +search %s PTR)" && echo OK > /results/%s;`, ptrLookup, ptrRecByTCPFileName) </del> <ins> probeCmd += fmt.Sprintf(`check="$$(dig +notcp +noall +answer +search %s PTR)" && test -n "$$check" && echo OK > /results/%s;`, ptrLookup, ptrRecByUDPFileName) probeCmd += fmt.Sprintf(`check="$$(dig +tcp +noall +answer +search %s PTR)" && test -n "$$check" && echo OK > /results/%s;`, ptrLookup, ptrRecByTCPFileName) </ins> fileNames = append(fileNames, ptrRecByUDPFileName) fileNames = append(fileNames, ptrRecByTCPFileName) }

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If this may be security issue, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig testing What happened: Tests checking DNS responses can have false positives, such as "should provide DNS for services". The tests rely on dig-ing certain domain names [1]: test -n "$(dig +notcp +noall +answer +search kubernetes.default A)" && echo OK /results/ The problems could be that, if a host / container doesn't have any entries in their : ubuntu dig +notcp +noall +answer +search kubernetes.default A ;; connection timed out; no servers could be reached , causing the test to pass and to write "OK" into the results file. [1] What you expected to happen: The tests shouldn't be able to pass if dig failed. How to reproduce it (as minimally and precisely as possible): Comment all nameservers or configure a bogus DNS server in, and run: test -n "$(dig +notcp +noall +answer +search kubernetes.default A)" && echo OK Anything else we need to know?: Environment: Kubernetes version (use ): 1.9.6 Cloud provider or hardware configuration: N/A OS (e.g. from /etc/os-release): "Ubuntu 16.04.3 LTS" Kernel (e.g. ): Linux ubuntu 4.4.0-87-generic
/assign
: But one of the purpose of the test is to ensure that the DNS of the cluster is replying. In other words, if it does not reply then we EXPECT this test to fail. If you are not using DNS then isn't it better to SKIP the test ?
I believe means to say "false negatives" ... meaning that in some situations, the test will errantly pass, when it should fail.
oops . Looks like I misread the description, and agree that the dig should work.
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
Change:
"strings" "time" <ins> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/types" </ins> "k8s.io/kubernetes/pkg/api/v1" "k8s.io/kubernetes/pkg/client/clientset_generated/clientset" "k8s.io/kubernetes/pkg/cloudprovider/providers/vsphere" "k8s.io/kubernetes/test/e2e/framework" <del> . "github.com/onsi/ginkgo" . "github.com/onsi/gomega" </del> ) func DeleteCinderVolume(name string) error {

Discussion:
https://k8s-
See flakes on . This test needs to be quarantined until it's deflaked.
This test has been moved in the flaky suite ()
Could you please help triage and fix this test? CC
and I are looking into it...
After comparing the relevant passing and failing test logs in the Flaky suite, this appears to just be a timing issue. doesn't give the PD enough time to detach (5 min timeout). Adding above the delete allows a 10 minute detach window before deletion. This is the pattern we've used in other GCEPD tests and have yet to see similar flakes. I'll have a PR up in a bit to add the detach wait. If there's not more flakes for a week after it's merged, I'll submit a PR to pull the Flaky tag.
So I notice this happens when I upgrade a deployment that moves the pod to another node. I can pretty much recreate it at will now. Is the solution to wait 5 minutes before allowing a pod to be created after it was deleted?
After checking the log, there is something wrong at the node side when reconciler tries to unmount the device (global mount path) because there are still some references to the mount. But unmounting local mount point is successfully. Need to investigate more about this issue.
Change:
func (m *effectiveVersion) Validate() []error { var errs []error // Validate only checks the major and minor versions. <del> binaryVersion := m.binaryVersion.Load().WithPatch(0) </del> <ins> binaryVersion := m.BinaryVersion().WithPatch(0) </ins> emulationVersion := m.emulationVersion.Load() minCompatibilityVersion := m.minCompatibilityVersion.Load()

Discussion:
Starting in 1.31, --version no longer works to modify the build ID of the running components. /kind regression /priority important-soon Running kube-apiserver v1.31.0 with ignores the modified build ID and reports In 1.28, 1.29, and 1.30 (since ), this allowed modifying the build ID of the running server. /sig api-machinery /assign Run v1.31.0 with No response 31.0 n/a <details</details<details</details<details</details<details</details
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 think this broke in DefaultBuildEffectiveVersion() is grabbed in NewAPIServerCommand(), before the flag is parsed, so the GitVersion propagated into the snapshot effectiveVersion doesn't honor
cc
Change:
"testing" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> "k8s.io/apimachinery/pkg/api/meta" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/fields"

Discussion:
cc ref
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
- can you please take a look, you introduced this test and it may mean real problem with your code
I took a quick look and this is a test issue. The problem is that the implementation explicitly assumes there is at most one call to dispatchEvent at a given time. And this particular test breaks this assumption: The problem is that, a given iteration is finished when is closed, which may actually happen as a result of even before is called (since it's a different goroutine). And then may be called concurrently with the next iteration, which triggers a race. The fix is simple, we should ensure that all goroutines are finished before starting the next iteration.
/cc
Change:
out = klogPrefix.ReplaceAllString(out, "<klog> ") return out } <ins> var initFunc = regexp.MustCompile(`(init.+func|glob.+func)`) // normalizeInitFunctions maps both init.func (used by Go >= 1.22) and // glob..func (used by Go < 1.22) to <init.func>. func normalizeInitFunctions(in string) string { out := initFunc.ReplaceAllString(in, "<init.func>") return out } </ins>

Discussion:
Internal job that runs k8s UT with master golang. https://prow.ppc64le- UT is failing when run with golang tip version. Around 24th of August No response This being a negative test scenario, looking at the test log, it seems the failure message from rest client isn't matching the expected in the string at The part of the text that doesn't match is: Expected: Actual: Steps to reproduce: master golang version clone kubernetes/test/e2e/framework/pod test -v -run TestFailureOutput /sig testing
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
/remove-kind failing-test /kind cleanup
is it happening in x86 too? is a golang bug ? there is also another bigger problem
Yes it is happening in x86 too. Yes, it could even be a golang bug too. But thought some upgrades in golang might require modification here in k8s. The above panic error that you pointed out already has an issue
This issue is introduced post addition of https://go- Global level functions are getting wrapped by synthetic init and so is getting changed to in actual traceback. Fix strategy has to be decided to support golang change mentioned above. Tagging others to request more inputs. /cc
^^
I think the output test is too strict: it shouldn't depend on the name given to anonymous functions. On the other hand, it should still ensure that functions like are printed as expected. This can be solved by further transforming the text during - I'll prepare a PR. /assign
Change:
} func probeNetworkPluginsWithVendorCNIDirPrefix(pluginDir, vendorCNIDirPrefix string) []network.NetworkPlugin { <del> configList := make([]network.NetworkPlugin, 0) network, err := getDefaultCNINetwork(pluginDir, vendorCNIDirPrefix) if err != nil { return configList } return append(configList, &cniNetworkPlugin{ defaultNetwork: network, </del> <ins> plugin := &cniNetworkPlugin{ defaultNetwork: nil, </ins> loNetwork:      getLoNetwork(vendorCNIDirPrefix), execer:         utilexec.New(), <del> }) </del> <ins> } plugin.syncNetworkConfig(pluginDir, vendorCNIDirPrefix) // sync network config from pluginDir periodically to detect network config updates go wait.Forever(func() { plugin.syncNetworkConfig(pluginDir, vendorCNIDirPrefix) }, 10*time.Second) return []network.NetworkPlugin{plugin} </ins> } func ProbeNetworkPlugins(pluginDir string) []network.NetworkPlugin {

Discussion:
Host network pods should be able to be created before the container network exists. Pod syncs for pods on the container network should fail until the container network is configured. cc
ref:
I think this is a thing we should make working before v1.4, so adding the milestone. Complain if you disagree. Also, does volunteer to make a PR? :)
Going to make a first pass at this in
Great!
/cc