jiebi/CodeConvo huggingface dataset:
Change:
to.LogWriter = ginkgo.GinkgoWriter } else { test := ginkgo.CurrentGinkgoTestDescription() <ins> // Clean up each individual component text such that // it contains only characters that are valid as file // name. </ins> reg := regexp.MustCompile("[^a-zA-Z0-9_-]+") <ins> var components []string for _, component := range test.ComponentTexts { components = append(components, reg.ReplaceAllString(component, "_")) } </ins> // We end the prefix with a slash to ensure that all logs // end up in a directory named after the current test. // <del> // TODO: use a deeper directory hierarchy once gubernator // supports that (https://github.com/kubernetes/test-infra/issues/10289). </del> <ins> // Each component name maps to a directory. This // avoids cluttering the root artifact directory and // keeps each directory name smaller (the full test // name at one point exceeded 256 characters, which was // too much for some filesystems). </ins> to.LogPathPrefix = framework.TestContext.ReportDir + "/" + <del> reg.ReplaceAllString(test.FullTestText, "_") + "/" </del> <ins> strings.Join(components, "/") + "/" </ins> } podlogs.CopyAllLogs(ctx, cs, ns, to)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Currently test names are formed by concatenating the ginkgo context's together. The testname is used to create a directory. This creates a limit on the length of the the testname, as most operating systems can only support a filename of up to 255 bytes. This concatenating is done by the logging library (I think) A way to break up the long test names by ginkgo context. Why is this needed: This test () failed on PR Current workarounds are simple by shortening the test names. However this is not desirable if we wish to support more nesting of ginkgo contexts in order to reduce boilerplate testing code by sharing common setup. This is also not desirable because it limits the ability to communicate the intent of the .
/sig testing
why are we using the testname to create a directory? even if we do need to create a directory per test we should probably use something more unique. sometimes multiple storage test entries wind up with the same test name
/sig storage
I assume this is about the artifacts, for example in The test name is guaranteed to be unique per test run. It was chosen because then developers can find the artifacts for a certain test. The alternative might be to split at component texts, see
In this example, the directory might then become (I'm guessing a bit what the component texts are - I'm not sure).
Oh, there's an old todo about doing exactly that. It wasn't possible at the time because gubernator couldn't handle deeply nested directories:
Thank you all!
Change:
} func (c *LRUExpireCache) Get(key lru.Key) (interface{}, bool) { <del> c.lock.RLock() defer c.lock.RUnlock() </del> <ins> c.lock.Lock() defer c.lock.Unlock() </ins> e, ok := c.cache.Get(key) if !ok { return nil, false

Discussion:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): "LRUExpireCache" Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT What happened: requires write lock since needs to manipulate its list to track recently used item. Currently it uses read lock so it may introduce race condition. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else do we need to know:
This was fixed in
Change:
package factory <del> import "testing" </del> <ins> import ( "k8s.io/kubernetes/plugin/pkg/scheduler/algorithm" "k8s.io/kubernetes/plugin/pkg/scheduler/api" "testing" ) </ins> func TestAlgorithmNameValidation(t *testing.T) { algorithmNamesShouldValidate := []string{

Discussion:
Weight is an int (see ). Priority can take the range 1-10. Total priority for a node is sum of weight  priority for each priority function, and the sum is accumulated into an int (see ). So obviously the total priority can overflow if someone sets the weight(s) too high. The weights of all priority functions are compiled in (or specified in config file), so we can check to make sure maximum total priority can't overflow an int (take sum over all priority functions of 10  weight of that priority function, and make sure that's smaller than int(MaxUint 1) which according to StackOverflow is the way to find out what is max int (math package has max Int32, Int64, etc. but not max Int). Note that scheduler extender is OK because although the policy runs in a separate process, the weight is specified in scheduler config file (ExtenderConfig struct) and the priority is bounded 1-10 as usual.
We really should also make "score" be an abstract datatype rather than a raw int that is manipulated directly, so we can do things like make sure it is in the range 1-10 (or 0-10 if that's what we want); today the range is inconistent (we say 1-10, but sometimes use 0; probably we should change it to 0-9..).
I volunteer myself to do this.
I think we can check weight overflow in after we get all PriorityConfig. what do you think about this?
As for "score" I think we can use
Fixed by - closing.
Tim that PR was closed, not merged. I don't think this is fixed yet.
whoops, good catch, just removing milestone then. There was a shift that happened yesterday where a bunch of items suddenly came into the 1.6 query.
do we still want this fixed? I can re-pick this.
AFAIK it's still broken. cc/
Ok, I will open a PR tomorrow.
Change:
"--use-service-account-credentials=true", "--controllers=*,bootstrapsigner,tokencleaner", "--allocate-node-cidrs=true", <del> "--cluster-cidr=bar", </del> <ins> "--cluster-cidr=10.0.1.15/16", "--node-cidr-mask-size=24", }, }, { cfg: &kubeadmapi.MasterConfiguration{ Networking:        kubeadmapi.Networking{PodSubnet: "2001:101:115::/48"}, CertificatesDir:   testCertsDir, KubernetesVersion: "v1.7.0", }, expected: []string{ "kube-controller-manager", "--address=127.0.0.1", "--leader-elect=true", "--kubeconfig=" + kubeadmconstants.KubernetesDir + "/controller-manager.conf", "--root-ca-file=" + testCertsDir + "/ca.crt", "--service-account-private-key-file=" + testCertsDir + "/sa.key", "--cluster-signing-cert-file=" + testCertsDir + "/ca.crt", "--cluster-signing-key-file=" + testCertsDir + "/ca.key", "--use-service-account-credentials=true", "--controllers=*,bootstrapsigner,tokencleaner", "--allocate-node-cidrs=true", "--cluster-cidr=2001:101:115::/48", "--node-cidr-mask-size=64", </ins> }, }, }

Discussion:
/kind bug What happened: Currently, if the user sets the cidr with --pod-network-cidr with kubeadm, the kube-controller-manager is passed the cidr with the --cluster-cidr arg. --node-cidr-mask-size is not passed to the kube-controller-manager and the controller-manager used the default value of 24 The default value of 24 if good for IPv4, but for IPv6 the controller-manager throws an error because the node-cidr-mask-size is incorrect. What you expected to happen: The user should be able to specify the node-cidr-mask-size for IPv6 How to reproduce it (as minimally and precisely as possible): Use Kubeadm specify an IPv6 address with --pod-network-cidr. with a subnet greater than 24. For example kubeadm init --pod-network-cidr=2001:101::0/64 Anything else we need to know?: Environment: IPv6 Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/area ipv6 /area kubeadm
/assign rpothier
Change:
// Check validates http connectivity type, direct or via proxy. func (hst HTTPProxyCheck) Check() (warnings, errors []error) { <del> url := fmt.Sprintf("%s://%s", hst.Proto, hst.Host) </del> <ins> u := (&url.URL{Scheme: hst.Proto, Host: hst.Host}).String() </ins> <del> req, err := http.NewRequest("GET", url, nil) </del> <ins> req, err := http.NewRequest("GET", u, nil) </ins> if err != nil { return nil, []error{err} }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When setting an HTTPPROXY with an IPv6 address, the is no HTTPProxy warning. What you expected to happen: There should be a warning that a proxy is being used. How to reproduce it (as minimally and precisely as possible): Use Kubeadm with IPv6 addresses, and IPv6 proxy in the environment. Such as: NOPROXY=2001:420:2c50:2021::/64 Anything else we need to know?: Environment: Kubernetes version (use ): 9 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign rpothier
/sig cluster-lifecycle
/area ipv6
Change:
const ( ProviderName     = "openstack" AvailabilityZone = "availability_zone" <ins> defaultTimeOut   = 60 * time.Second </ins> ) var ErrNotFound = errors.New("Failed to find object")

Discussion:
What happened: We use OpenStack as our cloud provider. We meet an issue that some controllers stuck because all workers routine stuck at http call to OpenStack services because of rabbitmq issues. Stuck routine call stack: Checked the openstack cloud provider that there is no HttpClient.Timeout set which means no timeout during http call. I think we should set at least the default http timeout value. Environment: Kubernetes version (use ): v1.6.3 Cloud provider or hardware configuration**: OpenStack
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig openstack /kind feature PTAL PR .
Change:
err := ds.checkpointManager.GetCheckpoint(podSandboxID, checkpoint) // Return empty portMappings if checkpoint is not found if err != nil { <del> if err == utilstore.ErrKeyNotFound { </del> <ins> if err == errors.ErrCheckpointNotFound { </ins> return nil, nil } <ins> errRem := ds.checkpointManager.RemoveCheckpoint(podSandboxID) if errRem != nil { glog.Errorf("Failed to delete corrupt checkpoint for sandbox %q: %v", podSandboxID, errRem) } </ins> return nil, err } _, _, _, checkpointedPortMappings, _ := checkpoint.GetData()

Discussion:
/kind bug are failing. seems like the likely cause. cc /assign
ping
seems one test still failing.
Change:
"type": "array" } }, <del> "required": [ "sources" ], </del> "type": "object" }, "io.k8s.api.core.v1.QuobyteVolumeSource": {

Discussion:
What happened: I created a Pod with a ProjectedVolume with an empty array of , but Kubernetes transformed that value to . Some clients are happy with either value (e.g. Go) while others are not (e.g. Python). For example, the following is accepted and stored by Kubernetes, but cannot be read by the Python client: The field has been transformed to : Even a JSON patch has no effect: What you expected to happen: I expected the required (OpenAPI) field of core/v1.ProjectedVolumeSource to be returned as the empty array I submitted. How to reproduce it (as minimally and precisely as possible): Create the above Pod: See that has been transformed to : See that the officially-supported Python client is unable to deserialize the Pod: Anything else we need to know?: I recognize there's a lot of layers involved in the steps above. The ineffectiveness of the JSON patch is what makes me think the culprit is somewhere in the field spec or API somehow. /sig api-machinery Environment: Kubernetes version (use ): [official-clients]:
/remove-sig api-machinery /sig storage the issue is in the API definition, which does not indicate the sources field is optional (even though it is)
/cc
Change:
"//pkg/client/metrics/prometheus:go_default_library", "//pkg/version/prometheus:go_default_library", "//plugin/cmd/kube-scheduler/app:go_default_library", <ins> "//vendor/k8s.io/apiserver/pkg/util/flag:go_default_library", </ins> "//vendor/k8s.io/apiserver/pkg/util/logs:go_default_library", ], )

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: I pull the latest code, and run with below cmd. But the cluster is not up. And I notice the kube-, 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 ): GitCommit:"" Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig cluster-lifecycle
/assign
Can you please try the fix above?
/assign
/unassign
your pr does not fix it yet? If not, I can help.
The fix from works for me! o/
ok, thanks
reopen , make less modifications.
sorry, i miss hyper...
Change:
}, } <del> o.DeleteFlags.AddFlags(cmd) </del> o.PrintFlags.AddFlags(cmd) o.RecordFlags.AddFlags(cmd)

Discussion:
The command provides a flag but this doesn't do anything. most likely the flag shouldn't exist. I have no idea how kustomize could be useful here to start a single pod. This creates a pod, and shows that is ignored: No response <details</details<detailsAzure, K3OS</details<detailsOSX 11.6.1 (Big Sur) </detailsNo response No response No response
/sig cli
This comes from the inclusion of DeleteFlags: brings in FilenameFlags: has Kustomize, resulting in the flag: I suspect there are many flags from DeleteFlags that don't really apply to . : Not sure what this would do : seems to be ignored and : doesn't seem to be used : doesn't seem to be used : also probably doesn't apply There might be others as well...
It seems to delete object which created by command.
I agree, As far as I can see, , and have this deleteFlags exposure.
/assign
/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
/triage accepted
Change:
t.Errorf("error adding pod to meta: %v", err) } <ins> newState, err := getPreFilterState(cycleState) if err != nil { t.Errorf("failed to get preFilterState from cycleState: %v", err) } if !reflect.DeepEqual(newState.topologyToMatchedAntiAffinityTerms, test.expectedAntiAffinity) { t.Errorf("State is not equal, got: %v, want: %v", newState.topologyToMatchedAntiAffinityTerms, test.expectedAntiAffinity) } if !reflect.DeepEqual(newState.topologyToMatchedAffinityTerms, test.expectedAffinity) { t.Errorf("State is not equal, got: %v, want: %v", newState.topologyToMatchedAffinityTerms, test.expectedAffinity) } </ins> if !reflect.DeepEqual(allPodsState, state) { t.Errorf("State is not equal, got: %v, want: %v", state, allPodsState) }

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: Maybe it should be 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:
/sig Scheduling
I feel it is a valid error. But need confirmation from sig-scheduling maintainers. ... is it okay if I work on this?
ok
Yeah, this is a bug in preemption
/assign
Change:
status api.PodPhase test   string }{ <del> {&api.Pod{Spec: desiredState, Status: currentState}, api.PodPending, "waiting"}, </del> { &api.Pod{ Spec: desiredState,

Discussion:
I'm actually not sure if it's by design. But certainly replication controller doesn't behave like it expects this.
If restart policy is to restart always, they should be restarted, but in that case they shouldn't be reported as failed.
This is a known issue, and by design based on upper-level will observe the status reported from kubelet, but not check with RestartPolicy and generate PodCondition / PodStatus. When RestartPolicy is Always, even Kubelet reports all containers are at failed state, apiserver shouldn't mark Pod as failed state. This is why initially I want kubelet report Pod state / status / condiction.
As a quick fix, we could let apiserver populate the right state / status based on containerStatus and RestartPolicy for now. In a long term, I still think we should make kubelet smarter and atomic and self-contained component, not just a wrapper around docker.
Short term fix should be P1 then we can de-prio for a "realer" fix.
Yes, I am working on the short term fix, and should have it included in 0.6 cut.
are you still working on this?
Yes, I am working on this. Should finish it today.
Change:
if cpuUsage <= 0 { framework.Failf("Pod %s/%s reported usage is %v, but it should be greater than 0", p.Namespace, p.Name, cpuUsage) } <del> if cpuUsage >= .5*1.05 { framework.Failf("Pod %s/%s reported usage is %v, but it should not exceed limit by > 5%%", p.Namespace, p.Name, cpuUsage) </del> <ins> // Jobs can potentially exceed the limit for a variety of reasons on Windows. // Softening the limit margin to 8% and allow a occasional overload. // https://github.com/kubernetes/kubernetes/issues/124643 if cpuUsage >= .8*1.05 { framework.Failf("Pod %s/%s reported usage is %v, but it should not exceed limit by > 8%%", p.Namespace, p.Name, cpuUsage) </ins> } } })

Discussion:
Failed error: Since migration to containerd 1.7.x No response The expected cpu usage is set to 0.5, but the actual cpu usage could be around 0.52-0.6, hence exceeding the limit more than the threshold of 5%. /sig windows
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /sig sig-windows 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
/sig windows
cc:
/triage accepted I've reached out to some folks to see if the variance in the job limit is expected.
Jobs can potentially exceed the limit for a variety of reasons. If they do they get put into a deficit, so over time they would appear to be at the correct limit. Since we run for a short period of time we this is likely what we bumping into a scenario where the job happen to go over the limit. I would be in favor of softening the in this case since it appears we are just slightly over it occasionally. We can add a comment in the code that mention that it will even out over time.
Hi thank you for agreeing to soften the 5% check. Just check in to see the timeline for getting the limit updated? If needed, I can help with making the changes in a PR.
if you want to take a go at make this update, it would be appreciated!
/assign
Change:
if len(portProtocol) != 2 { return nil, fmt.Errorf("unexpected port protocol mapping: %s", protocolsSlice[ix]) } <ins> if len(portProtocol[0]) == 0 { return nil, fmt.Errorf("unexpected empty port") } if len(portProtocol[1]) == 0 { return nil, fmt.Errorf("unexpected empty protocol") } </ins> portProtocolMap[portProtocol[0]] = portProtocol[1] } return portProtocolMap, nil

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: construct a string for labels, and let consume it. For example, suppose label string is , then this function will return a map which indicates a label . construct a string for portProtocols, and let consume it. For example, suppose portProtocols string is , then this function will return a map which indicates a pair . What you expected to happen: I assume the key of a label should not be an empty string since it makes no sense. I assume neither the nor the of pair should not be an empty string since it makes no sense. 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /area kubectl
If it's a bug, I can help fix it.
There are no sig labels on this issue. Please by: 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. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig cli
Change:
if pod.Status.Info == nil { return api.PodPending, nil } <ins> // TODO(dchen1107): move the entire logic to kubelet? </ins> running := 0 <ins> waiting := 0 </ins> stopped := 0 <ins> failed := 0 succeeded := 0 </ins> unknown := 0 for _, container := range pod.Spec.Containers { if containerStatus, ok := pod.Status.Info[container.Name]; ok {

Discussion:
I'm actually not sure if it's by design. But certainly replication controller doesn't behave like it expects this.
If restart policy is to restart always, they should be restarted, but in that case they shouldn't be reported as failed.
This is a known issue, and by design based on upper-level will observe the status reported from kubelet, but not check with RestartPolicy and generate PodCondition / PodStatus. When RestartPolicy is Always, even Kubelet reports all containers are at failed state, apiserver shouldn't mark Pod as failed state. This is why initially I want kubelet report Pod state / status / condiction.
As a quick fix, we could let apiserver populate the right state / status based on containerStatus and RestartPolicy for now. In a long term, I still think we should make kubelet smarter and atomic and self-contained component, not just a wrapper around docker.
Short term fix should be P1 then we can de-prio for a "realer" fix.
Yes, I am working on the short term fix, and should have it included in 0.6 cut.
are you still working on this?
Yes, I am working on this. Should finish it today.
Change:
} printLabelsMultiline(w, "Labels", node.Labels) printAnnotationsMultiline(w, "Annotations", node.Annotations) <del> printNodeTaintsMultiline(w, "Taints", node.Spec.Taints) </del> w.Write(LEVEL_0, "CreationTimestamp:t%sn", node.CreationTimestamp.Time.Format(time.RFC1123Z)) <ins> printNodeTaintsMultiline(w, "Taints", node.Spec.Taints) w.Write(LEVEL_0, "Unschedulable:t%vn", node.Spec.Unschedulable) </ins> if len(node.Status.Conditions) > 0 { w.Write(LEVEL_0, "Conditions:n  TypetStatustLastHeartbeatTimetLastTransitionTimetReasontMessagen") w.Write(LEVEL_1, "----t------t-----------------t------------------t------t-------n")

Discussion:
Once that event expires I'm fairly certain I would have no idea that the node is cordoned.
can we add one line when , wdyt?
/assign
We should probably reflect the actual field, rather than call it Cordoned. We try to use (as much as possible) the same terminology in the UI as in the API. Unschedulable would probably be sufficient
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. Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale