jiebi/CodeConvo huggingface dataset:
Change:
} } <del> // TODO(mkwiek): test if the petset.Status.Replicas is actually correct func TestPetSetReplicaCount(t *testing.T) { </del> <ins> func TestSyncPetSetBlockedPet(t *testing.T) { </ins> psc, fc := newFakePetSetController() ps := newPetSet(3) i, _ := psc.syncPetSet(ps, fc.getPodList())

Discussion:
Is this a request for help? Nope What keywords did you search in Kubernetes issues before filing this one? petset replicas current desired Is this a BUG REPORT or FEATURE REQUEST? BUG Kubernetes version Client Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"", Minor:"", GitVersion:"v0.0.0-master+", GitCommit:"", GitTreeState:"not a git tree", BuildDate:"2016-09-01T10:49:36Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"} Environment: Cloud provider or hardware configuration: 24 cores, 64 GB RAM OS Arch Linux Kernel (e.g. ): Linux hostname 4.4.13-1-lts SMP Wed Jun 8 16:44:31 CEST 2016 x86_64 GNU/Linux Install tools: local-cluster- Others: What happened: While creating PetSet based on this tutorial: first PetSet pod was stuck in pending state due to lack of PersistentVolumes in cluster. When getting the petset info via I expected to see "CURRENT" set to 1, while the kubectl output was as follows: While clearly shows that only one pod is created: In json and yaml output, status.replicas value was also 2. What you expected to happen: I expected that CURRENT value shown by kubectl would be due to only one pod being created. How to reproduce it (as minimally and precisely as possible): Create via on empty cluster and run and . Anything else do we need to know: Nope
CURRENT is the number of pods that have been created, not that they are READY. See for example the latest api change for replica sets where we exactly for this reason. All controllers (petsets, daemonsets, deployments, etc.) should have ReadyReplicas cc:
See also
I guess it doesn't work anyway, since only one pod was created for this PetSet, but the CURRENT says that 2 were created. I will change bug description then.

Hmm, the idea is to sync every pet periodically, but only create them one at a time. The logic that counts status.replicas is wrong. This counter shouldn't be incremented in the case where we didn't update/sync or create a pet: Today we do increment it all pet creation is blocked on the first pet becoming unhealthy. Should be an easy fix if anyone wants to jump in ( fyi) otherwise I'll get to it once 1.4 is out.
I can try to fix it if that's OK. Thanks for the pointer to the source code!
Please do, co-assigned
Change:
docker push ${REGISTRY}/${IMAGE}-${arch}:${TAG} done <ins> kube::util::ensure-gnu-sed </ins> # Make archs list into image manifest. Eg: 'amd64 ppc64le' to '${REGISTRY}/${IMAGE}-amd64:${TAG} ${REGISTRY}/${IMAGE}-ppc64le:${TAG}' manifest=$(echo $archs | ${SED} -e "s~[^ ]*~$REGISTRY/$IMAGE-&:$TAG~g") docker manifest create --amend ${REGISTRY}/${IMAGE}:${TAG} ${manifest}

Discussion:
[X] "goproxy" to "" [X] "jessie-dnsutils" to "" [X] "redis" to "" [X] "serve-hostname" to ""
/assign /assign
we can use to iterate
/sig testing
tip for uploading is here -
should be published to now. I'm rerunning for the other 3 images.
I think the and images were published successfully this time. :
can you please try ?
should now be published too thanks to PR.
related to
Change:
glog.Errorf("error getting instance ip address for %s: %v", node.Name, err) } else { address := api.NodeAddress{Type: api.NodeLegacyHostIP, Address: hostIP.String()} <del> node.Status.Addresses = append(node.Status.Addresses, address) </del> <ins> api.AddToNodeAddresses(&node.Status.Addresses, address) </ins> } } } else {

Discussion:
Since we append hostips to the list on every node controller run invocation which happens at 10s intervals, this list grows pretty large pretty soon: Maybe: would still satisfy the requirements?
Fix is here I think we generally use list instead of map
This could have been P1, but I just merged a fix so I'll leave at P2. Remaining work to do: Add to validation something that limits the number of IP addresses. (and maybe checks dups?)
Yeah, I'll add validation later.
Change:
podutil "k8s.io/kubernetes/pkg/api/pod" api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/serviceaccount" <ins> "k8s.io/utils/pointer" </ins> ) const (

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 --my mutating webhook calculates a hash of the , allows reinvocation; no side effects my validating webhook validates the hash of the and fails because the has changed webhook auditing indicates that my webhooks are the only ones processing the upon serializing the spec to JSON for both the mutator and validator, the only change is related to the "kube-api-access-xyz" projected volume, managed by a built-in k8s admission plugin the aforementioned plugin does not appear to mutate the reinvocation context, even through it may mutate a pod (robbing other mutators of the chance to observe the change): it appears that both my hooks see the injected volume, but the validation hook sees the injected SA volume with a "defaultMode" field set, and my mutation hook does NOT see this field set my validation hook should calculate the same hash mutating, validating webhooks are implemented atop controller-runtime v0.8.3, pod objects are being decoded into targets Kubernetes version (use ): 1.21.3 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 api-machinery
cc
interesting... defaults are applied when going from versioned → internal server decodes v1 Pod request → applies defaults → converts to internal Pod -in admission control operates on the internal Pod service account admission injects the kube-api-access volume admission is called internal Pod → converts to v1 Pod → serializes → sends to mutating webhook mutating webhook returns patch patch is applied to v1 Pod JSON resulting v1 Pod JSON is decoded → defaults applied (defaultMode is set on the api-token volume here) → converted to internal Pod webhook admission is called internal Pod → converts to v1 Pod → serializes → sends to validating webhook That means if any built-in admission plugin sets up data that would be modified by applying defaulting to the pod, the data sent to mutating webhooks will be missing those applied defaults until the first mutating webhook that returns a patch that changes the object
Possible solutions: defaults are applied to the internal → versioned object before invoking webhooks built-in admission always populates data matching default values for unset fields
As an aside, I'm not sure what you're using the hashing for, but be aware that hashing is fragile in the presence of defaults and new fields over time. A hash you add to a pod spec in one release might not match a hash computed in a different release, or with different admission in place.
/triage accepted /assign /priority backlog
Change:
APIServerTracing featuregate.Feature = "APIServerTracing" // owner: @linxiulei <del> // beta: v1.30 </del> <ins> // alpha: v1.30 </ins> // // Enables serving watch requests in separate goroutines. APIServingWithRoutine featuregate.Feature = "APIServingWithRoutine"

Discussion:
The code says this (): While the comment says this (): So..., what happened? The feature is still Alpha or it is a Beta? Be consistent about the features we add or change. Read the code. No response 30.0 <details</details<details</details<details</details<details</details<details</details
According to the changelog: This feature has been demoted from Beta to Alpha. That is fine. We need to revise the code comment then.
/sig api-machinery (not sure who owns it per se)
not worry, i think this can be resolved with
I found same like this inconsistency between the comment and the actual feature gate definition for APIServingWithRoutine in due to this
I want to raise PR on this if need another PR separately
Looks like this comment should be updated to alpha based on . Thanks for catching. if you'd like to raise a PR to fix the comment that'd be great!
/triage accepted
sure I will raise
Change:
// CreatePD creates a persistent volume func (p *Provider) CreatePD(zone string) (string, error) { pdName := fmt.Sprintf("%s-%s", framework.TestContext.Prefix, string(uuid.NewUUID())) <del> _, diskURI, _, err := p.azureCloud.CreateVolume(pdName, "" /* account */, "" /* sku */, "" /* location */, 1 /* sizeGb */) if err != nil { return "", err </del> <ins> volumeOptions := &azure.ManagedDiskOptions{ DiskName:           pdName, StorageAccountType: compute.StandardLRS, ResourceGroup:      "", PVCName:            pdName, SizeGB:             1, Tags:               nil, AvailabilityZone:   zone, DiskIOPSReadWrite:  "", DiskMBpsReadWrite:  "", </ins> } <del> return diskURI, nil </del> <ins> return p.azureCloud.CreateManagedDisk(volumeOptions) </ins> } // DeletePD deletes a persistent volume func (p *Provider) DeletePD(pdName string) error { <del> if err := p.azureCloud.DeleteVolume(pdName); err != nil { </del> <ins> if err := p.azureCloud.DeleteManagedDisk(pdName); err != nil { </ins> framework.Logf("failed to delete Azure volume %q: %v", pdName, err) return err }

Discussion:
I am trying to run Azure e2e tests: The test creates a volume in the cloud + runs a pod with the volume as in-line. The pod never starts: The test creates a "blob" disk, while the Azure machine expects "managed" disk. Does anyone run storage e2e tests on Azure regularly? Was it ever working? Managed disks are provisioned . Should the test suite create "managed" disks by default too? Environment: Kubernetes version (use ): v1.17.0-alpha.0.1089+-dirty
/sig azure
/sig cloud-provider
managed disk should be the default, the azure disk storage class in the test case may have
The volume is created outside of kubernetes dynamic provisioning to test pre-provisioned and inline volumes: I wonder if anyone actually runs the tests.
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. set -o errexit set -o nounset set -o pipefail KUBE_ROOT=$(dirname "${BASH_SOURCE}")/.. source "${KUBE_ROOT}/cluster/kube-env.sh" source "${KUBE_ROOT}/cluster/${KUBERNETES_PROVIDER}/util.sh" ${KUBE_ROOT}/hack/e2e-suite/goe2e.sh -tTestNetwork </ins>

Discussion:
Twice in the last two weeks I have dealt with "bugs" which turned out to be due to the fact that the fundamental requirements of pod networking were not being met. We need a way for a user to very quickly verify that the basic assumptions are met: pods can talk to pods, master can talk to pods, pods can talk to master, services work, etc.
Sounds like something that should have a dual life as an e2e test.
Yes, I ran into the similar issues when I tried to have containervm image as the default one. It turns out just some simple network configuration issues.
Service and replication controller that creates two pods, where the pod takes the kube service as an argument and tries to connect to the other pods described by endpoints?
Yeah that's sorta what I was thinking, too.
After gets merged, I think the easiest path to finishing this off is to just parameterize so that it's easy to point it at an existing cluster and run only the network test.
This is fixed by
Not completely fixed yet; need simple way to run it on existing cluster.
Remaining action item: Write a go script (bash if you must) that runs the networking test from against an existing cluster. Something that you can run via "go run" would be great, or adding flags to such that you can run it with something like "_output/go/bin/e2e -test=network" would be great too.
Reopening. Along the way in , we're moving the e2e script. But I also noticed this is relying on test assets. If you're trying to ship something to users, isn't something we ship to users.
Running will work after . We might end up renaming the test as part of the Ginkgo migration, in which case we can update this issue to indicate the correct invocation.
Closing this as is merged.
Change:
SupportedEtcdVersion = map[uint8]string{ 8:  "3.0.17", 9:  "3.1.10", <del> 10: "3.1.11", </del> <ins> 10: "3.1.10", </ins> } )

Discussion:
uses non existing etcd version for k8s 1.10.0. /kind bug /sig cluster-lifecycle
Change:
package cache import ( <ins> "errors" </ins> "fmt" "math/rand" "strconv"

Discussion:
I saw this as well. Log: Brief discussion in
I think I have a fix for this
Just submitted a PR that I believe fixes this. I was able to get the flakes locally w/o my PR and haven't seen any with it. PTAL!
how did you repro locally? I tried ran this test 1,000 times last night and it passed 1,000 times.
Change the resync period from 1 milli to 1 microsecond. You can also add 'stress -c 8' to the mix. On Friday, May 20, 2016, Matt Liggett wrote:
- FYI
sent which should fix this
Change:
importpath = "k8s.io/kubernetes/pkg/apis/storage/validation", deps = [ "//pkg/apis/core:go_default_library", <ins> "//pkg/apis/core/helper:go_default_library", </ins> "//pkg/apis/core/validation:go_default_library", "//pkg/apis/storage:go_default_library", "//pkg/features:go_default_library",

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 --/kind feature The field essentially has the type , but currently there is no validation for set and map semantics, i.e. unique elements / keys. Having this validation at API level removes logic to validate at the volume plugin level. edit: this check will not be in cases where this makes it difficult to add other fields and make this field optional. /sig api-machinery /sig storage
/assign
Thanks for catching this. Would you be able to implement this for this release? We want to try to go beta if we can, and we won't be able to strengthen validation once that happens.
Yes will do!
Change:
// Here we set API QPS limit from default 5 to 60 in order to test real Kubelet performance. // Note that it will cause higher resource usage. tempSetCurrentKubeletConfig(f, func(cfg *kubeletconfig.KubeletConfiguration) { <del> framework.Logf("Old QPS limit is: %dn", cfg.KubeAPIQPS) </del> <ins> framework.Logf("Old QPS limit is: %d", cfg.KubeAPIQPS) </ins> // Set new API QPS limit cfg.KubeAPIQPS = int32(itArg.APIQPSLimit) })

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: is always appending a new line to its message: In some places of code, the message is already has a newline character and it leads to doubled new lines in the logs. What you expected to happen: I'm not sure what is the correct behavior here. One of the options could be to append a new line conditionally.
/sig testing
I'm new to Kubernetes and would like to start contributing. Is it ok if I assign myself this issue?
/assign MorrisLaw
GitHub didn't allow me to assign the following users: MorrisLaw. Note that only can be assigned. <detailsIn response to : /assign MorrisLaw 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
I can't assign this to myself, as I am not a member yet. But I am still going to take this issue.
I'll help him on reviews so assigning.
Change:
case corev1.ResourceQuotaScopeNotBestEffort: return !isBestEffort(pod), nil case corev1.ResourceQuotaScopePriorityClass: <ins> if selector.Operator == corev1.ScopeSelectorOpExists { // This is just checking for existence of a priorityClass on the pod, // no need to take the overhead of selector parsing/evaluation. return len(pod.Spec.PriorityClassName) != 0, nil } </ins> return podMatchesSelector(pod, selector) case corev1.ResourceQuotaScopeCrossNamespacePodAffinity: return usesCrossNamespacePodAffinity(pod), nil

Discussion:
If a Pod is subjected to a with "PriortyClass" as its scope, the quota's calculation is incorrect. See repo steps for more details. with "PriortyClass" as its scope can be calculated at all times. Create a PriorityClass named "p1"Create a quota with as its scope. Note: w/o specifying , this issue won't happenCreate a Job and wait for its completion.Check quota's usage calculation Here is incorrect - it should be . Worse calculation may happen if I create a regular pod and then delete the Job:The eventual result is totally incorrect. No response master, and possibly all versions. kind <details</details<details</details<details</details<details</details
/sig api-machinery /kind bug
/triage accepted
I would like to take this up!
is already in flight for this
Change:
* [API](api-conventions.md) * [Client libraries](client-libraries.md) <del> * [Command-line interface](cli.md) </del> <ins> * [Command-line interface](kubectl.md) </ins> * [UI](ux.md) * [Images and registries](images.md) * [Container environment](container-environment.md)

Discussion:
It's causing problems and is kind-of GCE dependent anyway, we should just use the kubecfg binary, and document the environment variables it uses.
I think its beneficial to keep something, but remove the GCE dependent pieces, i.e. "external-ip" piece.
I put together some instructions here:
We can remove this when kubecfg is deprecated .
Reopened since it still needs to be removed. /cc
Doh. Didn't mean to declare this fixed in that PR.
Closing this (again) as it is a dupe of
Change:
// does NOT work in 1809 if the socket file is created within a bind mounted directory by a container // and the FSCTL is issued in the host by the kubelet. <ins> // If the file does not exist, it cannot be a Unix domain socket. if _, err := os.Stat(filePath); os.IsNotExist(err) { return false, fmt.Errorf("File %s not found. Err: %v", filePath, err) } </ins> klog.V(6).InfoS("Function IsUnixDomainSocket starts", "filePath", filePath) // As detailed in https://github.com/kubernetes/kubernetes/issues/104584 we cannot rely // on the Unix Domain socket working on the very first try, hence the potential need to

Discussion:
No response No response /sig windows /kind failing-test
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
/assign
/sig windows
i think this problem can be fixed when it imports os/net in Am i right?
I also found some other unit test bugs in CI, such as running linux-related tests on windows. I will try to fix them. /assign
/cc
Thanks for opening the issue! I didn't notice the failure through the testgrid dashboard. I've sent a PR here: . While fixing this issue, I noticed there's one unit test that was failing, so that PR also addresses that as well.
Yep, the imports you mentioned are needed. Keep in mind that imports are in alphabetical order. But in addition to that, there was another failing unit test which was masked by this import errors.
Change:
defer httplog.NewLogged(req, &w).StacktraceWhen( httplog.StatusIsNot( http.StatusOK, <ins> http.StatusMovedPermanently, http.StatusTemporaryRedirect, </ins> http.StatusNotFound, ), ).Log()

Discussion:
I1218 02:32:15. 2704 ] GET /stats?numstats=9: (42.94us) 301 goroutine 74 [running]: (respLogger).WriteHeader(0xc2081a58c0, 0x12d) +0x9c net/http.Redirect(0x7f9f2806ecd0, 0xc2081a58c0, 0xc2083da1a0, 0xc208240520, 0x7, 0x12d) +0x473 net/http.(redirectHandler).ServeHTTP(0xc208116660, 0x7f9f2806ecd0, 0xc2081a58c0, 0xc2083da1a0) +0x5e net/http.(ServeMux).ServeHTTP(0xc2080ff560, 0x7f9f2806ecd0, 0xc2081a58c0, 0xc2083da1a0) +0x1a3 (Server).ServeHTTP(0xc208116620, 0x7f9f2806ec98, 0xc2081ba140, 0xc2083da1a0) +0x117 net/http.serverHandler.ServeHTTP(0xc2080046c0, 0x7f9f2806ec98, 0xc2081ba140, 0xc2083da1a0) +0x19f net/http.(conn).serve(0xc208120e80) +0xa7e created by net/http.(_Server).Serve +0x313
Change:
csitranslationplugins.CinderInTreePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigration) && utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationOpenStack) }, <ins> csitranslationplugins.AzureDiskInTreePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigration) && utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationAzureDisk) }, csitranslationplugins.AzureFileInTreePluginName: func() bool { return utilfeature.DefaultFeatureGate.Enabled(features.CSIMigration) && utilfeature.DefaultFeatureGate.Enabled(features.CSIMigrationAzureFile) }, </ins> } // Initializing the label management channels

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: azure disk migration does not work on CSINode 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:
corev1 "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/api/resource" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" <ins> "k8s.io/apimachinery/pkg/runtime" </ins> "k8s.io/apimachinery/pkg/runtime/schema" quota "k8s.io/apiserver/pkg/quota/v1" "k8s.io/apiserver/pkg/quota/v1/generic" utilfeature "k8s.io/apiserver/pkg/util/feature" <ins> "k8s.io/client-go/tools/cache" </ins> featuregatetesting "k8s.io/component-base/featuregate/testing" api "k8s.io/kubernetes/pkg/apis/core" "k8s.io/kubernetes/pkg/features"

Discussion:
If a Pod is subjected to a with "PriortyClass" as its scope, the quota's calculation is incorrect. See repo steps for more details. with "PriortyClass" as its scope can be calculated at all times. Create a PriorityClass named "p1"Create a quota with as its scope. Note: w/o specifying , this issue won't happenCreate a Job and wait for its completion.Check quota's usage calculation Here is incorrect - it should be . Worse calculation may happen if I create a regular pod and then delete the Job:The eventual result is totally incorrect. No response master, and possibly all versions. kind <details</details<details</details<details</details<details</details
/sig api-machinery /kind bug
/triage accepted
I would like to take this up!
is already in flight for this
Change:
- containerPort: 80 name: "http-server" volumeMounts: <del> - mountPath: "/var/www/html" </del> <ins> - mountPath: "/usr/share/nginx/html" </ins> name: mypd volumes: - name: mypd

Discussion:
The of the persistent-volumes walkthrough contains the volume mount which seems to be outdated for the used nginx conatiner which is by default serving from the folder. As a result, the data wrtitten in in the node will not be returned by the at the end of the walkthought. Proposed change: Update the path
Thanks for bringing up this issue, Would you be up for sending a pull request with the fix?