jiebi/CodeConvo huggingface dataset:
Change:
github.com/containerd/ttrpc v1.0.2/go.mod h1:UAxOpgT9ziI0gJrmKvgcZivgxOp8iFPSk8httJEt98Y= github.com/containerd/typeurl v1.0.1 h1:PvuK4E3D5S5q6IqsPDCy928FhP0LUIGcmZ/Yhgp5Djw= github.com/containerd/typeurl v1.0.1/go.mod h1:TB1hUtrpaiO88KEK56ijojHS1+NeF0izUACaJW2mdXg= <del> github.com/containernetworking/cni v0.8.0 h1:BT9lpgGoH4jw3lFC7Odz2prU5ruiYKcgAjMCbgybcKI= github.com/containernetworking/cni v0.8.0/go.mod h1:LGwApLUm2FpoOfxTDEeq8T9ipbpZ61X79hmU3w8FmsY= </del> <ins> github.com/containernetworking/cni v0.8.1 h1:7zpDnQ3T3s4ucOuJ/ZCLrYBxzkg0AELFfII3Epo9TmI= github.com/containernetworking/cni v0.8.1/go.mod h1:LGwApLUm2FpoOfxTDEeq8T9ipbpZ61X79hmU3w8FmsY= </ins> github.com/coredns/corefile-migration v1.0.11 h1:ptBYGW2ADXIB7ZEBPrhhTvNwJLQfxE3Q9IUMBhJCEeI= github.com/coredns/corefile-migration v1.0.11/go.mod h1:RMy/mXdeDlYwzt0vdMEJvT2hGJ2I86/eO0UdXmH9XNI= github.com/coreos/bbolt v1.3.2/go.mod h1:iRUV2dpdMOn7Bo10OQBFzIJO9kkE559Wcmn+qkEiiKk=

Discussion:
is identified with with severity rating as high. This is found using snyk scan while running against k/k master We're not using directly however, it gets tagged for vulnerability scans as we use . The fix is already present in and we can bump the dep. Bump dep to which has the mentioned CVE fix. and check Kubernetes version (use ): n/a Cloud provider or hardware configuration: any OS (e.g: ): n/a Kernel (e.g. ): n/a Install tools: n/a Network plugin and version (if this is a network-related bug): n/a Others: n/a /sig architecture /area code-organization for the dependency
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
Change:
"k8s.io/apimachinery/pkg/fields" "k8s.io/apimachinery/pkg/labels" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/util/wait" </ins> "k8s.io/apimachinery/pkg/watch" restclient "k8s.io/client-go/rest" "k8s.io/client-go/tools/record"

Discussion:
the timing is suspicious. Your pull merged, right?
it did, i will take a look.
Change:
if opts.AllowNonStructural || len(structuralschema.ValidateStructural(nil, ss)) == 0 { schema = ss <ins> // This adds ValueValidation fields (anyOf, allOf) which may be stripped below if opts.StripValueValidation is true schema = schema.Unfold() </ins> if opts.StripValueValidation { schema = schema.StripValueValidations() } if opts.StripNullable { schema = schema.StripNullable() } <del> schema = schema.Unfold() </del> } } }

Discussion:
With in a CRD we get: This is because gnostic's OpenAPI proto types have no nullable support. Luckily CRDs keep working because in the upper error case we don't stop serving, just set the SSA schema to nil.
Thanks for reporting!
I think it should be "This is because gnostic's OpenAPI v2 proto types have no nullable support.". The problem is that we're not supposed to pass-in v3.
Source:
OK, We'll write a test and fix this, thanks Stefan!
/reopen This still happens in slightly different shape: This comes from :
That's a fairly different bug but yes, thanks!
Is this related to the stating that use of "anyOf" wouldn't be allowed after 1.16? We're seeing issue on OpenFaaS after going to 1.17.5 and 1.18. Usually upgrading K8s versions hasn't caused breaking changes and we're trying to figure out where to start with this one.
No. That post was about structural schemas. v1 CRDs are limited to structural schemas. v1beta1 CRDs can continue to create non-structural schemas until v1beta1 is no longer served (in 1.22) Also, is not completely disallowed, specific restrictions inside an clause (like ) are what are not allowed ("logical constraints using oneOf, allOf, anyOf, not are allowed").
extracted the newly found issue to to track separately with isolated reproducer /close
Closing this issue. <detailsIn response to : extracted the newly found issue to to track separately 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:
Containers: []api.Container{ { Name:    "tester", <del> Image:   "busybox", </del> <ins> Image:   "gcr.io/google_containers/busybox", </ins> Command: []string{"sleep", "600"}, Lifecycle: &api.Lifecycle{ PreStop: &api.Handler{

Discussion:
Testgrid; https://k8s- Sample Failure: The problem seems to be that Kube-anywhere isn't working since commit /sig cluster-lifecycle /kind failing-test /priority important-soon cc:
/milestone v1.13
sent possible fix PR:
sent new PR might get merged once github is back on track.
Reopening, because the test isn't passing yet. /reopen
Reopening this issue. <detailsIn response to : Reopening, because the test isn't passing yet. 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
true, i was almost sure that the solution in that last PR won't be sufficient... will investigate more tomorrow.
/assign
I see https://k8s- job failing as well. Will the 2 open PRs address this failure as well?
all the kubeadm-gce-x tests are broken at the moment due to the e2e refactor. we will hopefully decide on how to approach the issue today.
latest efforts:
the tests are working on the cluster up/down side, except that they fail when dumping the node logs. looking into it.
should be green by tomorrow.
Looks good, thanks! One flake in the last run - let's keep an eye on it but it should be fine. /cc /close
Closing this issue. <detailsIn response to : Looks good, thanks! One flake in the last run - let's keep an eye on it but it should be fine. 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:
case "${platform}" in "linux/arm") export CGO_ENABLED=1 <del> export CC=arm-linux-gnueabihf-gcc </del> <ins> export CC=${KUBE_LINUX_ARM_CC:-arm-linux-gnueabihf-gcc} </ins> ;; "linux/arm64") export CGO_ENABLED=1 <del> export CC=aarch64-linux-gnu-gcc </del> <ins> export CC=${KUBE_LINUX_ARM64_CC:-aarch64-linux-gnu-gcc} </ins> ;; "linux/ppc64le") export CGO_ENABLED=1 <del> export CC=powerpc64le-linux-gnu-gcc </del> <ins> export CC=${KUBE_LINUX_PPC64LE_CC:-powerpc64le-linux-gnu-gcc} </ins> ;; "linux/s390x") export CGO_ENABLED=1 <del> export CC=s390x-linux-gnu-gcc </del> <ins> export CC=${KUBE_LINUX_S390X_CC:-s390x-linux-gnu-gcc} </ins> ;; esac fi

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : There should be a way to override the default gcc compliers mentioned in the file with custom gcc compilers for different platforms. Also, cross compilation should be supported on platforms other than amd64. Why is this needed: Right now, there seems to be no way to override the platform specific cc flags that kubernetes sets. We should be able to override those values. For example, bottlerocket sets customized CC flags for different platforms using this . We should be able to override the default values in kubernetes using environment variables or build time flags and build kubernetes with customized gcc variants that bottlerocket uses. Also, we need an option to set gcc compilers for amd64 platform, so that amd64 targets can be built on different platforms.
/sig release
Sure, that will require cross building the build toolset itself, which nobody has taken up yet.
Change:
#   foo: true #   bar: false for gate in $(echo ${FEATURE_GATES} | tr ',' ' '); do <del> echo $gate | sed -e 's/(.*)=(.*)/  1: 2/' </del> <ins> echo $gate | ${SED} -e 's/(.*)=(.*)/  1: 2/' </ins> done fi >>/tmp/kube-proxy.yaml

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: After running (on master branch), a new file named left as a surprise. and the file is not matched by git ignore so it's tracked by git which is really disturbing. I tried to find out where it's created but failed. Any one has a context w/ it? Environment: OS (e.g. from /etc/os-release): Darwin Kernel Version 17.6.0: Tue May 8 15:22:16 PDT 2018; root:xnu-4570.61.1~1/RELEASEX8664 x86_64
/sig instrumentation
the only piece of code in local-up-cluster that touches the file is
can't reproduce this. Two questions: Can you see this everytime? What is the SHA of the commit on master when you tried this? Can check with that too.
finally i realize that the cause is command is built receiving different flags between Linux and OSX. on Linux, you'll find that for linux sed the is explained as: '--in-place[=SUFFIX]' This option specifies that files are to be edited in-place. GNU 'sed' does this by creating a temporary file and sending output to this file rather than to the standard output.(1). so the is optional. but for OSX, it is: Edit files in-place, saving backups with the specified extension. If a zero-length extension is given, no backup will be saved. It is not recommended to give a zero- length extension when in-place editing files, as you risk corruption or partial content in situations where disk space is exhausted, etc. the difference is that on OSX, flag is requiring a variable , so when we're using on OSX in the script: the which is supposed to be received as a flag will be a suffix for the backup file. then the magic happened.will raise a fix for this. /assign
linking the difference between and
Change:
package azure import ( <ins> "net/http" </ins> "strings" "github.com/Azure/azure-sdk-for-go/services/compute/mgmt/2019-07-01/compute"

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: check disk status before disk azure disk There is little possibility that attach disk would cost 10min, and disk could be attached, deleted in same time, that would cause race condition. 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: /kind bug /assign /priority important-soon /sig cloud-provider /area provider/azure
Change:
return &effectiveVersion{} } binaryVersion := version.MustParse(binaryVer) <del> return newEffectiveVersion(binaryVersion) </del> <ins> return newEffectiveVersion(binaryVersion, false) } func defaultBuildBinaryVersion() *version.Version { verInfo := baseversion.Get() return version.MustParse(verInfo.String()).WithInfo(verInfo) </ins> } // DefaultBuildEffectiveVersion returns the MutableEffectiveVersion based on the // current build information. func DefaultBuildEffectiveVersion() MutableEffectiveVersion { <del> verInfo := baseversion.Get() binaryVersion := version.MustParse(verInfo.String()).WithInfo(verInfo) </del> <ins> binaryVersion := defaultBuildBinaryVersion() </ins> if binaryVersion.Major() == 0 && binaryVersion.Minor() == 0 { return DefaultKubeEffectiveVersion() } <del> return newEffectiveVersion(binaryVersion) </del> <ins> return newEffectiveVersion(binaryVersion, true) </ins> } // DefaultKubeEffectiveVersion returns the MutableEffectiveVersion based on the // latest K8s release. func DefaultKubeEffectiveVersion() MutableEffectiveVersion { binaryVersion := version.MustParse(baseversion.DefaultKubeBinaryVersion).WithInfo(baseversion.Get()) <del> return newEffectiveVersion(binaryVersion) </del> <ins> return newEffectiveVersion(binaryVersion, false) </ins> } // ValidateKubeEffectiveVersion validates the EmulationVersion is equal to the binary version at 1.31 for kube components.

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:
"k8s.io/apiserver/pkg/server/healthz" "k8s.io/apiserver/pkg/server/mux" "k8s.io/apiserver/pkg/server/routes" <ins> "k8s.io/client-go/kubernetes/scheme" </ins> "k8s.io/client-go/tools/events" "k8s.io/client-go/tools/leaderelection" cliflag "k8s.io/component-base/cli/flag"

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: Kube-Scheduler exposes metrics in a secure manner (TLS and authentication required) on port by default. If one does not authenticate itself, the error message displayed is: What you expected to happen: Kube-Scheduler should emit a clear and understandable error message if authentication fails. Kube-Controller-Manager does that the following way: How to reproduce it (as minimally and precisely as possible): up a Kubernetes Cluster to access the exposed metrics endpoint (https://metrics-server:/metrics) without authentication Anything else we need to know?: xref: Environment: Kubernetes version (use ): 1.18.6 Cloud provider or hardware configuration: Bare metal OS (e.g: ): Debian GNU/Linux 10 (buster) Kernel (e.g. ): 4.19.0-9-amd64 Install tools: Kubeadm (Kube-Scheduler )
/sig scheduling instrumentation
If ok, I can try this fix /assign
/assign
Change:
// CreatePodsOnNode creates a new pod accorting to the spec on the specified node. CreatePodsOnNode(nodeName, namespace string, template *api.PodTemplateSpec, object runtime.Object) error // DeletePod deletes the pod identified by podID. <del> DeletePod(namespace string, podID string) error </del> <ins> DeletePod(namespace string, podID string, object runtime.Object) error </ins> } // RealPodControl is the default implementation of PodControlInterface.

Discussion:
Currently RC emits an event when it's creating a pod: But nothing is emitted when a pod is deleted. We should create event for scaling both ways. cc
Change:
go_library( name = "go_default_library", <del> srcs = ["controller-manager.go"], </del> <ins> srcs = [ "controller-manager.go", "providers.go", ], </ins> importpath = "k8s.io/kubernetes/cmd/cloud-controller-manager", deps = [ "//cmd/cloud-controller-manager/app:go_default_library",

Discussion:
make verify WHAT=typecheck-providerless outputs /cc /milestone v1.19
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
see example successful run:
For reference -
fix in
screaming
Change:
// IPVS service was changed, update the existing one // During updates, service VIP will not go down glog.V(3).Infof("IPVS service %s was changed", svcName) <del> if err := proxier.ipvs.UpdateVirtualServer(appliedVirtualServer); err != nil { </del> <ins> if err := proxier.ipvs.UpdateVirtualServer(vs); err != nil { </ins> glog.Errorf("Failed to update IPVS service, err:%v", err) return 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?: /kind bug What happened: IPVS proxier update service too slow, it waits until a sync period. What you expected to happen: Any k8s service update should trigger IPVS virtual service update. How to reproduce it (as minimally and precisely as possible): a k8s service its session affinity type see if ipvs virtual service has changed - NO! Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig network /area ipvs
Change:
# check right pod exists kube::test::get_object_assert 'pods a' "{{${id_field}}}" 'a' # apply svc and don't prune pod a by overwriting whitelist <del> kubectl apply --prune -l prune-group=true -f hack/testdata/prune/svc.yaml -w core/v1/Service 2>&1 "${kube_flags[@]}" </del> <ins> kubectl apply --prune -l prune-group=true -f hack/testdata/prune/svc.yaml --prune-whitelist core/v1/Service 2>&1 "${kube_flags[@]}" </ins> kube::test::get_object_assert 'service prune-svc' "{{${id_field}}}" 'prune-svc' kube::test::get_object_assert 'pods a' "{{${id_field}}}" 'a' # apply svc and prune pod a with default whitelist

Discussion:
When writing the docs for , I found there is a flag with short hand flag has been add to in 1.5. The flag is mostly used by add-on manger. I think we only give the flag that is very commonly used a shorthand flag. I think we should keep and save it for other flags in the future. We can make the change before it goes out in 1.5. cc:
Change:
return nil, err } <del> if fieldPatchStrategy == mergeDirective { </del> <ins> // Delete lists are handled the same way regardless of what the field's patch strategy is if fieldPatchStrategy == mergeDirective || isDeleteList { </ins> return mergeSlice(typedOriginal, typedPatch, schema, fieldPatchMergeKey, mergeOptions, isDeleteList) } else { return typedPatch, nil

Discussion:
This page explains that the deleteFromPrimitiveList should delete the specified items, but the specified items are kept, and the other items are deleted. The specified items in the deleteFromPrimitiveList should be removed. The result should be instead: No response <details</details<details</details<details</details<details</details<details</details<details</details
/sig api-machinery
Related:
/assign Could you take a look Antoine please? Thanks! /triage accepted
Simplest way to reproduce: It doesn't work with any kubectl version from 1.18 to 1.23 that I've tested.
I tried the exact same object, changing the finalizers works like a charm.
cc Want to give this one a try? :-)
Sure, I'll take a look at it... /assign
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]:
/remove-lifecycle stale
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]:
/remove-lifecycle stale
Change:
MUST cause pods created by that RC to be orphaned. release: v1.9 file: test/e2e/apimachinery/garbage_collector.go <ins> - testname: Namespace, apply changes to a namespace status codename: '[sig-api-machinery] Namespaces [Serial] should apply changes to a namespace status [Conformance]' description: Getting the current namespace status MUST succeed. The reported status phase MUST be active. Given the patching of the namespace status, the fields MUST equal the new values. Given the updating of the namespace status, the fields MUST equal the new values. release: v1.25 file: test/e2e/apimachinery/namespace.go </ins> - testname: namespace-deletion-removes-pods codename: '[sig-api-machinery] Namespaces [Serial] should ensure that all pods are removed when a namespace is deleted [Conformance]'

Discussion:
[x] test approval issue : [x] test pr : [x] two weeks soak end date : 1 Aug 2022 [x] test promotion pr : According to this APIsnoop query, there is still some remaining NamespaceStatus endpoints which are untested. readCoreV1NamespaceStatuspatchCoreV1NamespaceStatus Using a number of existing e2e test practices a new has been created for 2 namespace status endpoints. The e2e logs for this test are listed below. This query shows the endpoints hit within a short period of running the e2e test If a test with these calls gets merged, test coverage will go up by 3 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted
/reopen
Reopened this issue. <detailsIn response to : /reopen 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:
if len(missingPods) > 0 { if usageRatio < 1.0 { <del> // on a scale-down, treat missing pods as using 100% of the resource request </del> <ins> // on a scale-down, treat missing pods as using exactly the target amount </ins> for podName := range missingPods { metrics[podName] = metricsclient.PodMetric{Value: targetUtilization} }

Discussion:
Change the fallback consumption from to when pod metrics are missing on a scale down. Background from : The fallback value of 100% is supposed to be a safe overestimate of the desired value to dampen the magnitude of a potential scale down. However, if a metric target is set to more than 100% then this fallback typically becomes an underestimate that amplifies a potential scale down. Note that a metric target of over 100% is a valid HPA configuration. We could choose a fallback of instead. However, any safety margin would be arbitrary and I think it's better to opt for simplicity vs. precision in this corner case.
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 autoscaling
/assign
/assign