jiebi/CodeConvo huggingface dataset:
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-alpha-features Which test(s) are failing: [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of same group but different versions [sig-api-machinery] CustomResourceConversionWebhook [Feature:CustomResourceWebhookConversion] Should be able to convert a non homogeneous list of CRs [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for CRD without validation schema` [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of same group and version but different kinds [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] updates the published spec when one versin gets renamed [sig-api-machinery] CustomResourceConversionWebhook [Feature:CustomResourceWebhookConversion] Should be able to convert from CR v1 to CR v2 [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of different groups [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] removes definition from spec when one versin gets changed to not be served Since when has it been failing: Failing since 5/16 . There were two PRs related to API machinery and tests that were merged during this period and Testgrid link: Reason for failure: The first failure seems to be this: [sig-api-machinery] CustomResourcePublishOpenAPI [Feature:CustomResourcePublishOpenAPI] works for multiple CRDs of same group but different versions /cc /priority critical-urgent /kind failing test /milestone v1.15 /cc
/assign sttts
/assign
looks like there were some alpha gated tests that need adjusting after
/unassign
On it.
another PR touching CRD OpenAPI publishing was merged yesterday and we didn't run alpha presubmit test let me know if you think it's specific to CRD openapi publishing and I can look into it
debugging now
is now green /close
Closing this issue. <detailsIn response to : is now green 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

Discussion:
} crd, err := crd.CreateMultiVersionTestCRD(f, group, func(crd *v1beta1.CustomResourceDefinition) { <del> apiVersions := []v1beta1.CustomResourceDefinitionVersion{} for _, version := range versions { v := v1beta1.CustomResourceDefinitionVersion{ </del> <ins> var apiVersions []v1beta1.CustomResourceDefinitionVersion for i, version := range versions { apiVersions = append(apiVersions, v1beta1.CustomResourceDefinitionVersion{ </ins> Name:    version, Served:  true, <del> Storage: false, } apiVersions = append(apiVersions, v) </del> <ins> Storage: i == 0, }) </ins> } <del> apiVersions[0].Storage = true </del> <ins> crd.Spec.Versions = apiVersions </ins> crd.Spec.Validation = &v1beta1.CustomResourceValidation{ OpenAPIV3Schema: props,
Change:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: ci-kubernetes-e2e-gci-gce-serial Which test(s) are failing: [sig-network] DNS configMap nameserver [IPv4] Change stubDomain should be able to change stubDomain configuration [Slow][Serial] [sig-network] DNS configMap nameserver [IPv4] Forward external name lookup should forward externalname lookup to upstream nameserver [sig-network] DNS configMap nameserver [IPv4] Forward PTR lookup should forward PTR records lookup to upstream nameserver [Slow][Serial] Since when has it been failing: These tests have been failing since 5/18. Testgrid link: Reason for failure: All of these have this failure message in common: The failures coincide with for which the possible fix is . However, we are filing these failures separate from to see if there are any additional steps that need to be done for these series of tests. /cc /priority critical-urgent /kind failing test /milestone v1.15 /cc
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign
/remove-triage unresolved
Tests have been green since 6/1

Discussion:
valid1 := map[string]string{ "Corefile": fmt.Sprintf(`.:53 { health <ins> ready </ins> kubernetes %v in-addr.arpa ip6.arpa { pods insecure upstream

valid2 := map[string]string{ "Corefile": fmt.Sprintf(`:53 { health <ins> ready </ins> kubernetes %v in-addr.arpa ip6.arpa { pods insecure upstream

t.setConfigMap(&v1.ConfigMap{Data: map[string]string{ "Corefile": fmt.Sprintf(`.:53 { health <ins> ready </ins> kubernetes %v in-addr.arpa ip6.arpa { pods insecure upstream
Change:
Right now cri-tools only include tarballs for linux /cc /cc
/sig release
/area release-eng /milestone v1.16 /help /priority important-soon
This request has been marked as needing help from a contributor. 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 : /area release-eng /milestone v1.16 /help /priority important-soon 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
Hello! I'm a bug triage shadow for the 1.16 release cycle and considering this issue is tagged for 1.16, I'd like to check its status. Code freeze is starting on August 29th (about 2 days from now). Do we still target this issue to be fixed for 1.16?
No, nobody is working on this for 1.16. cc
/milestone clear
anything we can do in release team to move this forward?
I'm working on this one now if nobody else minds. :) /assign

Discussion:
name = "cri-tools-data-%s" % goarch, package_dir = "/usr/bin", tags = ["manual"], <del> deps = ["@cri_tools_%s//file" % goarch], </del> <ins> deps = ["@cri_tools_linux-%s//file" % goarch], </ins> ) for goarch in NODE_PLATFORMS["linux"]] [k8s_deb(

[pkg_rpm_for_goarch( name = "cri-tools", data = [ <del> "@cri_tools_{GOARCH}//file", </del> <ins> "@cri_tools_linux-{GOARCH}//file", </ins> ], goarch = arch, spec_file = "cri-tools.spec",

CRI_TOOLS_VERSION = "1.16.1" _CRI_TARBALL_ARCH_SHA256 = { <del> "amd64": "19fed421710fccfe58f5573383bb137c19438a9056355556f1a15da8d23b3ad1", "arm": "367826f3eb06c4d923f3174d23141ddacef9ffcb0c902502bd922dbad86d08dd", "arm64": "62b60ab7046b788df892a1b746bd602c520a59c38232febc0580692c9805f641", "ppc64le": "d6464188a5011242b8dad22cb1e55d8cb29d6873f3d1f3f3c32bb236d3fca64e", "s390x": "f3d5e707810d7985f6a470ea439ca5989c0ee218a824795ed1726f4958281a2d", </del> <ins> "linux-386": "35b721a7a90a12cf9689fb1f4fe5b50f73520200130a52b552234bd798d2ae9f", "linux-amd64": "19fed421710fccfe58f5573383bb137c19438a9056355556f1a15da8d23b3ad1", "linux-arm": "367826f3eb06c4d923f3174d23141ddacef9ffcb0c902502bd922dbad86d08dd", "linux-arm64": "62b60ab7046b788df892a1b746bd602c520a59c38232febc0580692c9805f641", "linux-ppc64le": "d6464188a5011242b8dad22cb1e55d8cb29d6873f3d1f3f3c32bb236d3fca64e", "linux-s390x": "f3d5e707810d7985f6a470ea439ca5989c0ee218a824795ed1726f4958281a2d", "windows-386": "b7564675f69aa2a01b092874c9c9aeda084204384d711a6fb85c6d2328ca5c7d", "windows-amd64": "7d092dcb3b1af2edf75477d5d049a70e8c0d1ac8242b1dff2de7e6aa084e3615", </ins> } ETCD_VERSION = "3.3.15"

name = "cri_tools_%s" % arch, downloaded_file_path = "cri_tools.tgz", sha256 = sha, <del> urls = mirror("https://github.com/kubernetes-incubator/cri-tools/releases/download/v%s/crictl-v%s-linux-%s.tar.gz" % (CRI_TOOLS_VERSION, CRI_TOOLS_VERSION, arch)), </del> <ins> urls = mirror("https://github.com/kubernetes-incubator/cri-tools/releases/download/v%s/crictl-v%s-%s.tar.gz" % (CRI_TOOLS_VERSION, CRI_TOOLS_VERSION, arch)), </ins> ) # Use go get -u github.com/estesp/manifest-tool to find these values
Change:
What happened: Created a daemonset ala but missing the master toleration. The created pods are running on every node, including the master. What you expected to happen: Lacking the master toleration, I would expect there to be no pod from the daemonset running on the master. Realized the master Node is missing the master taint. How to reproduce it (as minimally and precisely as possible): Created a daemonset on GCE with no tolerations. (You may need to set the priorityClassName: system-cluster-critical) Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: GCE OS (e.g: ): Kernel (e.g. ): 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

Discussion:
#TODO(mikedanese): allow static pods to start before creating a client #flags+=" --bootstrap-kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig" #flags+=" --kubeconfig=/var/lib/kubelet/kubeconfig" <ins> flags+=" --register-with-taints=node-role.kubernetes.io/master=:NoSchedule" </ins> flags+=" --kubeconfig=/var/lib/kubelet/bootstrap-kubeconfig" flags+=" --register-schedulable=false" fi
Change:
What happened: The following error occurs when creating kube-dns in local-up- What you expected to happen: hack/local-up- should be able to create kube-dns successfully. How to reproduce it (as minimally and precisely as possible): Run ./hack/local-up- Anything else we need to know?: The memory limit in kube- has been changed to "pillar['dnsmemorylimit']" by But local-up- does not transform it into a value. 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 testing

Discussion:
ENABLE_NODELOCAL_DNS=${KUBE_ENABLE_NODELOCAL_DNS:-false} DNS_SERVER_IP=${KUBE_DNS_SERVER_IP:-10.0.0.10} LOCAL_DNS_IP=${KUBE_LOCAL_DNS_IP:-169.254.20.10} <ins> DNS_MEMORY_LIMIT=${KUBE_DNS_MEMORY_LIMIT:-170Mi} </ins> DNS_DOMAIN=${KUBE_DNS_NAME:-"cluster.local"} KUBECTL=${KUBECTL:-"${KUBE_ROOT}/cluster/kubectl.sh"} WAIT_FOR_URL_API_SERVER=${WAIT_FOR_URL_API_SERVER:-60}

cp "${KUBE_ROOT}/cluster/addons/dns/kube-dns/kube-dns.yaml.in" kube-dns.yaml ${SED} -i -e "s/{{ pillar['dns_domain'] }}/${DNS_DOMAIN}/g" kube-dns.yaml ${SED} -i -e "s/{{ pillar['dns_server'] }}/${DNS_SERVER_IP}/g" kube-dns.yaml <ins> ${SED} -i -e "s/{{ pillar['dns_memory_limit'] }}/${DNS_MEMORY_LIMIT}/g" kube-dns.yaml </ins> # TODO update to dns role once we have one. # use kubectl to create kubedns addon ${KUBECTL} --kubeconfig="${CERT_DIR}/admin.kubeconfig" --namespace=kube-system create -f kube-dns.yaml
Change:
What would you like to be : Put non-ignorable extenders ahead of ignorable extenders in genericScheduler#extenders Why is this needed: In genericScheduler#processPreemptionWithExtenders, we iterate over genericScheduler#extenders. If an ignorable extender gives error, the error is ignored and loop continues. It seems we should place non-ignorable extenders ahead of ignorable extenders so that the preemption can bail out early if a non-ignorable extender gives error.
/sig scheduling

Discussion:
var extenders []algorithm.SchedulerExtender if len(policy.ExtenderConfigs) != 0 { ignoredExtendedResources := sets.NewString() <ins> var ignorableExtenders []algorithm.SchedulerExtender </ins> for ii := range policy.ExtenderConfigs { klog.V(2).Infof("Creating extender with config %+v", policy.ExtenderConfigs[ii]) extender, err := core.NewHTTPExtender(&policy.ExtenderConfigs[ii]) if err != nil { return nil, err } <del> extenders = append(extenders, extender) </del> <ins> if !extender.IsIgnorable() { extenders = append(extenders, extender) } else { ignorableExtenders = append(ignorableExtenders, extender) } </ins> for _, r := range policy.ExtenderConfigs[ii].ManagedResources { if r.IgnoredByScheduler { ignoredExtendedResources.Insert(string(r.Name)) } } } <ins> // place ignorable extenders to the tail of extenders extenders = append(extenders, ignorableExtenders...) </ins> predicates.RegisterPredicateMetadataProducerWithExtendedResourceOptions(ignoredExtendedResources) } // Providing HardPodAffinitySymmetricWeight in the policy config is the new and preferred way of providing the value.
Change:
The flag has been deprecated for many releases and can be removed. The depreciation guide specifies that admin-only CLI flags can be removed after 6 months: /kind cleanup /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/remove-triage unresolved
Thanks In future, please comment/check when taking on an issue, I didn't realize someone was going to do this.
Sorry, I'll comment on the issue and check next time.
That's okay, I only wasted a few minutes on it before I noticed the PR.

Discussion:
"strings" "time" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> v1meta "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/serializer"

"Maximum number of NAT connections to track (0 to leave as-is). This overrides conntrack-max-per-core and conntrack-min.") fs.MarkDeprecated("conntrack-max", "This feature will be removed in a later release.") <del> fs.BoolVar(&o.CleanupAndExit, "cleanup-iptables", o.CleanupAndExit, "If true cleanup iptables and ipvs rules and exit.") fs.MarkDeprecated("cleanup-iptables", "This flag is replaced by --cleanup.") </del> fs.StringVar(&o.config.ResourceContainer, "resource-container", o.config.ResourceContainer, "Absolute name of the resource-only container to create and run the Kube-proxy in (Default: /kube-proxy).") fs.MarkDeprecated("resource-container", "This feature will be removed in a later release.") }
Change:
What would you like to be : TestSelectNodesForPreemption should assign pod.Status.StartTime for test Pod Why is this needed: We can see the following in the output of TestSelectNodesForPreemption: This is due to missing assignment to Status.StartTime
/sig scheduling
/assign

Discussion:
} for _, test := range tests { t.Run(test.name, func(t *testing.T) { <ins> assignDefaultStartTime(test.pods) </ins> nodes := []*v1.Node{} for _, n := range test.nodes { node := makeNode(n, 1000*5, priorityutil.DefaultMemoryRequest*5)

} for _, test := range tests { t.Run(test.name, func(t *testing.T) { <ins> assignDefaultStartTime(test.pods) </ins> nodes := []*v1.Node{} for _, n := range test.nodes { nodes = append(nodes, makeNode(n, priorityutil.DefaultMilliCPURequest*5, priorityutil.DefaultMemoryRequest*5))

}) } } <ins> func assignDefaultStartTime(pods []*v1.Pod) { now := metav1.Now() for i := range pods { pod := pods[i] if pod.Status.StartTime == nil { pod.Status.StartTime = &now } } } </ins>
Change:
<!-- 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: After deleting a pod and scaling up the statefulset with different valid envs in the same container simultaneously, then the output events of executing the command is below: What you expected to happen: update successfully. How to reproduce it (as minimally and precisely as possible): a statefulset. apply this statefulset's yaml: After a while, execute , and the pod is running a new stateful's yaml, which a new env key and more replicas. the pod and apply a new stateful's yaml the statefulset Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-28T13:37:52Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.4", GitCommit:"", GitTreeState:"clean", BuildDate:"2019-02-28T13:30:26Z", GoVersion:"go1.11.5", Compiler:"gc", Platform:"linux/amd64"}
/sig apps
Meet same problem while using kube-addon-manager. vs and patchStrategy
+1
In some cases, add in the env which using can solve the problem.
/assign
I think the root cause of this is the strategic patch. As mentioned, we have to use the to fix the problem which tells the strategic patch to remove the field so the spec could pass the validation process of statefulsets. It would lead to API broken if we change the behaviour of strategic merge patch, I'll dig around in the apps validation process and try to find out the solution to this.
Thank you for your reply. According to your advice, I tried to add in my second statefulset's yaml, but I still could not update statefulset correctly. How to fix my yamls to get around the problem?
/unassign Sorry, I do not have enough time for this, anyone interested could take it from here.
I don't think the problem comes from your YAML, the problem comes from the controller that doesn't update the fields properly.
/assign

Discussion:
# install.  See https://github.com/saltstack/salt-bootstrap/issues/270 # # -M installs the master <del> curl -L http://bootstrap.saltstack.org | sh -s -- -M -X </del> <ins> curl -L http://bootstrap.saltstack.com | sh -s -- -M -X </ins> echo $MASTER_HTPASSWD > /srv/salt/nginx/htpasswd

# # We specify -X to avoid a race condition that can cause minion failure to # install.  See https://github.com/saltstack/salt-bootstrap/issues/270 <del> curl -L http://bootstrap.saltstack.org | sh -s -- -X </del> <ins> curl -L http://bootstrap.saltstack.com | sh -s -- -X </ins>
Change:
What happened: Some of the Azure CSI translation checks in and needs to perform NPE checks for pointer based fields as pointed out in and What you expected to happen: NPE checks should be there How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.15 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:
/assign
/sig storage
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
/remove-lifecycle rotten
/priority critical-urgent

Discussion:
CSI: &v1.CSIPersistentVolumeSource{ Driver:           AzureDiskDriverName, VolumeHandle:     azureSource.DataDiskURI, <del> ReadOnly:         *azureSource.ReadOnly, FSType:           *azureSource.FSType, </del> VolumeAttributes: map[string]string{azureDiskKind: "Managed"}, }, }, AccessModes: []v1.PersistentVolumeAccessMode{v1.ReadWriteOnce}, }, } <ins> if azureSource.ReadOnly != nil { pv.Spec.PersistentVolumeSource.CSI.ReadOnly = *azureSource.ReadOnly } </ins> <del> if *azureSource.CachingMode != "" { </del> <ins> if azureSource.CachingMode != nil && *azureSource.CachingMode != "" { </ins> pv.Spec.PersistentVolumeSource.CSI.VolumeAttributes[azureDiskCachingMode] = string(*azureSource.CachingMode) } <del> if *azureSource.FSType != "" { </del> <ins> if azureSource.FSType != nil { pv.Spec.PersistentVolumeSource.CSI.FSType = *azureSource.FSType </ins> pv.Spec.PersistentVolumeSource.CSI.VolumeAttributes[azureDiskFSType] = *azureSource.FSType } if azureSource.Kind != nil {
Change:
What happened: when running integration tags were missing on files What you expected to happen: add the needed tags on test/integration files How to reproduce it (as minimally and precisely as possible): add an integration test package under cc
/sig testing /priority important-soon /area build-release
/cc
if we want to assume that all tests in a certain directory are integration tests this is very easy to automate, here's an example that we do now to mark go tests and binaries as
Is the assumption that all tests in should be tagged as integration? I'd be happy to add this to the script, but would prefer to get in without conflicts first
/assign /lifecycle active

Discussion:
exit 1 fi <ins> # mark all ./test/integration/* targets as integration # see comment above re: buildozer exit codes buildozer -quiet 'add tags integration' '//test/integration/...:%go_test' && ret=$? || ret=$? if [[ $ret != 0 && $ret != 3 ]]; then exit 1 fi </ins> # we need to set this because gazelle doesn't support pkg-config, which would set this link option # see comment above re: buildozer exit codes buildozer -quiet 'set clinkopts select({"@io_bazel_rules_go//go/platform:linux":["-lseccomp",],"//conditions:default":[],})' //vendor/github.com/seccomp/libseccomp-golang:go_default_library && ret=$? || ret=$?
Change:
<!-- 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: 's memory usage is increasing over time. When more pods are run, it increases even more. What you expected to happen: it should not keep increasing How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 Cloud provider or hardware configuration: AKS OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others: !
/sig windows /sig azure
/assign

Discussion:
package stats import ( <ins> "fmt" </ins> "time" "github.com/Microsoft/hcsshim"

stats := make(map[string]*statsapi.NetworkStats) for _, c := range containers { <del> container, err := hcsshim.OpenContainer(c.ID) </del> <ins> cstats, err := fetchContainerStats(c) </ins> if err != nil { <del> klog.V(4).Infof("Failed to open container %q with error '%v', continue to get stats for other containers", c.ID, err) </del> <ins> klog.V(4).Infof("Failed to fetch statistics for container %q with error '%v', continue to get stats for other containers", c.ID, err) </ins> continue } <del> cstats, err := container.Statistics() if err != nil { klog.V(4).Infof("Failed to get statistics for container %q with error '%v', continue to get stats for other containers", c.ID, err) continue } </del> if len(cstats.Network) > 0 { stats[c.ID] = hcsStatsToNetworkStats(cstats.Timestamp, cstats.Network) }

return stats, nil } <ins> func fetchContainerStats(c hcsshim.ContainerProperties) (stats hcsshim.Statistics, err error) { var ( container hcsshim.Container ) container, err = hcsshim.OpenContainer(c.ID) if err != nil { return } defer func() { if closeErr := container.Close(); closeErr != nil { if err != nil { err = fmt.Errorf("failed to close container after error %v; close error: %v", err, closeErr) } else { err = closeErr } } }() return container.Statistics() } </ins> // hcsStatsToNetworkStats converts hcsshim.Statistics.Network to statsapi.NetworkStats func hcsStatsToNetworkStats(timestamp time.Time, hcsStats []hcsshim.NetworkStats) *statsapi.NetworkStats { result := &statsapi.NetworkStats{