jiebi/CodeConvo huggingface dataset:
Change:
func TestModifyHostConfig(t *testing.T) { setNetworkHC := &dockercontainer.HostConfig{} <ins> // When we have Privileged pods, we do not need to use the // Masked / Readonly paths. </ins> setPrivSC := &runtimeapi.LinuxContainerSecurityContext{} setPrivSC.Privileged = true <ins> setPrivSC.MaskedPaths = []string{"/hello/world/masked"} setPrivSC.ReadonlyPaths = []string{"/hello/world/readonly"} </ins> setPrivHC := &dockercontainer.HostConfig{ Privileged: true, } <ins> unsetPrivSC := &runtimeapi.LinuxContainerSecurityContext{} unsetPrivSC.Privileged = false unsetPrivSC.MaskedPaths = []string{"/hello/world/masked"} unsetPrivSC.ReadonlyPaths = []string{"/hello/world/readonly"} unsetPrivHC := &dockercontainer.HostConfig{ Privileged:    false, MaskedPaths:   []string{"/hello/world/masked"}, ReadonlyPaths: []string{"/hello/world/readonly"}, } </ins> setCapsHC := &dockercontainer.HostConfig{ CapAdd:  []string{"addCapA", "addCapB"}, CapDrop: []string{"dropCapA", "dropCapB"},

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: kind bug What happened: After execute kubeadm init during kube-proxy pod initialization there is CrashLoopBackOff error all the time Logs from pod: [centos ~]$ kubectl logs kube-proxy-8gs45 -n kube-system What you expected to happen: kube-proxy pod run properly How to reproduce it (as minimally and precisely as possible): follow instruction: try to execute: Environment: Kubernetes version (use ):Cloud provider or hardware configuration:OS (e.g. from /etc/os-release):Kernel (e.g. ):Install tools:Others:
/sig network
I have exactly the same problem with the 1.12.0-beta.1. Does kube-proxy really need access to /proc/sys/* in this case?
Same problem with Ubuntu
Does that mean kube-proxy can only be run outside of container?
/sig cluster-lifecycle
/milestone v1.12
Looks like docker inspect shows masked and read-only paths (looking at ) even when the pod is
It being close to release, since this is not urgent, please save this for 1.13! /milestone clear /milestone v1.13
/milestone v1.13
/priority critical-urgent /milestone v1.12 Sorry the activity and urgency is reflected in the PR :)
welp! sorry about that!
I'm still seeing this on RC1, did this land before the release was cut? /cc
update from :
I just verified on release-1.12 branch and it's good.
Change:
- file: /etc/init.d/kubelet {% endif %} - file: /var/lib/kubelet/kubernetes_auth <del> {% if grains.network_mode is defined and grains.network_mode == 'openvswitch' %} - sls: sdn {% endif %} </del>

Discussion:
It appears that the provision-network script that is run on the kubernetes-master can cause salt provisioning on the minions to fail or block in a forever retry timeout error loop. I think it's because of the service network.restart that happens after openvswitch is installed in provision-network. I only say this because when I disable installing docker on kubernetes-master in vagrant, I do not have an issue. - is there a different way we can structure this on the kubernetes-master? For example, could we run the script in or something?
Change:
t.Errorf("expected success or bad request err, got %#v", err) } }) <ins> t.Run("ApplyPatchType should handle a valid patch just under the max limit", func(t *testing.T) { patchBody := []byte(`{"apiVersion":"v1","kind":"Secret"` + strings.Repeat(" ", 3*1024*1024-100) + `}`) err = rest.Patch(types.ApplyPatchType).Param("fieldManager", "test").AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")). Body(patchBody).Do().Error() if err != nil { t.Errorf("unexpected error: %v", err) } }) </ins> t.Run("Delete should limit the request body size", func(t *testing.T) { err = c.Delete().AbsPath(fmt.Sprintf("/api/v1/namespaces/default/secrets/test")). Body(hugeData).Do().Error()

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: It returns an error when I create a pod of yaml file over 1M. I checked the codes and found that the coded wrong. It should be “json.Unmarshal(p.patchBytes, &v)”, not “json.Unmarshal(p.patchBytes, v)” in the 344 and 368 line. What you expected to happen: It can be parsed correctly. How to reproduce it (as minimally and precisely as possible): Look at the code and you'll see or you can test it. Anything else we need to know?: no. Environment: Kubernetes version (use ): Community latest code 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
/sig api-machinery
/assign
Change:
onExecuteFunc := func() { firstRunning.Done() <del> firstRunning.Wait() sendSignals() </del> fakeFilter.wait() allRunning.Done()

Discussion:
Testgrid doesn't load kubernetes/test-infra From: /sig api-machinery
/assign /triage accepted
Yes. It looks like a bug. There are many calls to , and they are not all guaranteed to happen before the second . I will revise.
Change:
"strings" "testing" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/runtime" "k8s.io/apimachinery/pkg/runtime/schema" <ins> "k8s.io/apimachinery/pkg/util/json" </ins> "k8s.io/cli-runtime/pkg/genericclioptions" "k8s.io/cli-runtime/pkg/resource" "k8s.io/client-go/rest/fake"

Discussion:
Currently, the cmd output msg is not distinguished between label and unlabel (using suffix ), both of them response . To distinguish between label and unlabel msg: , just like .
/sig cli
/triage accepted
Change:
listerWatcher ListerWatcher // backoff manages backoff of ListWatch backoffManager wait.BackoffManager <del> // initConnBackoffManager manages backoff the initial connection with the Watch call of ListAndWatch. initConnBackoffManager wait.BackoffManager resyncPeriod           time.Duration </del> <ins> resyncPeriod   time.Duration </ins> // clock allows tests to manipulate time clock clock.Clock // paginatedResult defines whether pagination should be forced for list calls.

Discussion:
Currently, reflector uses two backoff managers: One is used for initial list call and other for watch call. Imagine following scenaraion when k8s apiserver is under very heavy load: the beginning, reflector spams k8s apiserver (with exponential backoff) with calls until one of them succeeds (due to APF throtling and receiving ) tries to run request and uses separate backoffManager - so again spams k8s apiserver with requests Watch does not succeed during Etcd compaction window (2.5 - 5 minutes usually) at some point it will receive and go back to point 1, spamming k8s apiserver again with List calls (because first backoffManager for List got reseted after 2 minutes of retries for Watch requests) I propose we combine these two backoff managers into one. If we combine these two backoffManagers into one, it will work like this: At the beginning, reflector spams k8s apiserver (still with exponential backoff) with calls until one of them succeeds Tries to make first watch call instantly (as there is no backoff on this path) If it fails, it will makre retries every (30, 60)s If watch request fails all the times during Etcd compaction window it will go back to List call, but already being throttled with (30, 60)s window. /sig scalability
/cc
/assign
I think the proposed solution makes sense to me. Probably before we start, we should to understand why we ended up with two back off managers by looking into PRs touching them. Maybe the code authors had some specific case in mind.
for thoughts too I agree it makes sense, but I don't know the historical context here.
/sig api-machinery
/triage accepted
Change:
return nil, err } <ins> emptyDuration := MyDuration{} if cfg.Metadata.RequestTimeout == emptyDuration { cfg.Metadata.RequestTimeout.Duration = time.Duration(defaultTimeOut) } provider.HTTPClient.Timeout = cfg.Metadata.RequestTimeout.Duration </ins> os := OpenStack{ provider:     provider, region:       cfg.Global.Region,

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:
"//pkg/kubelet/apis/kubeletconfig:go_default_library", "//pkg/kubelet/checkpointmanager:go_default_library", "//pkg/kubelet/checkpointmanager/checksum:go_default_library", <ins> "//pkg/kubelet/checkpointmanager/errors:go_default_library", </ins> "//pkg/kubelet/cm:go_default_library", "//pkg/kubelet/container:go_default_library", "//pkg/kubelet/dockershim/cm:go_default_library",

Discussion:
/kind bug are failing. seems like the likely cause. cc /assign
ping
seems one test still failing.
Change:
"${NODE_INSTANCE_PREFIX}-group") if [[ "$deleteCmdOutput" != ""  ]]; then # Managed instance group deletion is done asyncronously, we must wait for it to complete, or subsequent steps fail <del> deleteCmdOperationId=$(echo $deleteCmdOutput | grep "Operation:" | sed "s/.*Operation:s//" | sed "s/s.*//" | sed "s/ //g") </del> <ins> deleteCmdOperationId=$(echo $deleteCmdOutput | grep "Operation:" | sed "s/.*Operation:[[:space:]]*([^[:space:]]*).*/1/g") </ins> if [[ "$deleteCmdOperationId" != ""  ]]; then deleteCmdStatus="PENDING" while [[ "$deleteCmdStatus" != "DONE" ]] do <del> sleep 5 </del> <ins> sleep 5 </ins> deleteCmdOperationOutput=$(gcloud preview managed-instance-groups --zone "${ZONE}" get-operation $deleteCmdOperationId) <del> deleteCmdStatus=$(echo $deleteCmdOperationOutput | grep -i "status:" | sed "s/.*status:s//" | sed "s/s.*//" | sed "s/ //g") </del> <ins> deleteCmdStatus=$(echo $deleteCmdOperationOutput | grep -i "status:" | sed "s/.*status:[[:space:]]*([^[:space:]]*).*/1/g") </ins> echo "Waiting for MIG deletion to complete. Current status: " $deleteCmdStatus done fi

Discussion:
is running in to an issue where the operation ID pulled from the MIG delete command during GCE kube-down is incorrect:
Looks like this is caused by OS X using non-GNU . A couple of different possible fixes, one is to force check for and use that when available. Another approach, courtesy of is to just limit our self to non-GNU .
Change:
{HostPort: 443, ContainerPort: 444}, }, }, <ins> { "", []api.Port{}, }, </ins> } for _, tt := range testCases { ports := portsFromString(tt.spec)

Discussion:
$ run thockin/hostnametcp 1 hostname-tcp E1002 14:48:23. ] Container port is not integer: strconv.ParseInt: parsing "": invalid syntax
Change:
return nil } <ins> func makeEnvVariableName(str string) string { return strings.ToUpper(strings.Replace(str, "-", "_", -1)) } </ins> func makeLinkVariables(service api.Service, machine string) []api.EnvVar { <del> prefix := strings.ToUpper(service.ID) </del> <ins> prefix := makeEnvVariableName(service.ID) </ins> var port string if service.ContainerPort.Kind == util.IntstrString { port = service.ContainerPort.StrVal } else { port = strconv.Itoa(service.ContainerPort.IntVal) } <del> portPrefix := prefix + "_PORT_" + strings.ToUpper(strings.Replace(port, "-", "_", -1)) + "_TCP" </del> <ins> portPrefix := prefix + "_PORT_" + makeEnvVariableName(port) + "_TCP" </ins> return []api.EnvVar{ { Name:  prefix + "_PORT",

Discussion:
In issue it appeared that consensus was reached that a service id could contain a hyphen, but that it would be translated to an underscore in the environment variables (this issues was the root problem, back in ). However, the replacement does not appear to have been done: hyphens are still not replaced with underscores in env-var names. (Although now underscores are blocked in service names!)
Hm, that's weird. I thought that this code was doing replacement. Did that get removed?
Thanks for looking into this lavalamp. Was your question directed at me? I don't see any string replacement code in the code you linked to, at least not for the (I do see escaping for the port in line 198)
Ah, no, I was just thinking out loud there. Maybe knows what happened?
Ah, that's an oversight. We do it for the Docker link style variables, but not the old school ones. I'll send a PR.
PR sent.
Change:
visibility = ["//visibility:public"], deps = [ "//pkg/api/v1/pod:go_default_library", <ins> "//pkg/apis/core/validation:go_default_library", </ins> "//pkg/scheduler/algorithmprovider:go_default_library", "//pkg/scheduler/apis/config:go_default_library", "//pkg/scheduler/apis/config/scheme:go_default_library",

Discussion:
What happened: When a pod can't be scheduled and the cardinality of taints on nodes is high, the Note field in the event can become bigger than the 1024 allowed and the event isn't sent. The pod stays in a state of without en event which makes the User Experience very bad What you expected to happen: I would expect the Kube-scheduler to be able to send the event no matter how many different taints are on nodes How to reproduce it (as minimally and precisely as possible): add many different taints to nodes and then trying to schedule something which can't be successfully scheduled (higher CPU/memory than any node has) Anything else we need to know?: In this case the length of the message was 1334 characters. Environment: Kubernetes version (use ): 1.18.9 Cloud provider or hardware configuration: bare metal Possible solutions: make event size configurable, it's now hardcoded to 1024 characters make scheduler note aware of that limit and work around I, if length 1024 then truncate the string (so at least something is shown) produce N events splitting the text (preferred one): change event Note to be to something like: (the whole complete information would still be present in the pod status field. for debugging purposes)
/sig scheduling
/triage accepted /cc
I could provide the fix in case we define which solution is best
This is a consequence of I think we can just drop some reasons when we are building the status message if the message is too large. This comes from here /help
/remove-help /assign
how many different taints did you have? I think in all cases we should truncate the message as well:
Another remidiation is to supress outoutping nil fields (such as GenerateName:"", SelfLink:"", UID:"", ResourceVersion:"", etc.) in the EventRecorder side.
The size limit we're hitting is specifically on the field
Completely agreed
good issue~
/assign
/unassign
Change:
return fmt.Errorf("pod %s on node %s had incorrect containers: %#v", pod.Name, pod.Spec.NodeName, pod.Status.ContainerStatuses) } <del> if status := findContainerStatusInPod(pod, "blocked"); status != nil { </del> <ins> if status := e2epod.FindContainerStatusInPod(pod, "blocked"); status != nil { </ins> if (status.Started != nil && *status.Started == true) || status.LastTerminationState.Terminated != nil || status.State.Waiting == nil { return fmt.Errorf("pod %s on node %s should not have started the blocked container: %#v", pod.Name, pod.Spec.NodeName, status) } } <del> status := findContainerStatusInPod(pod, "fail") </del> <ins> status := e2epod.FindContainerStatusInPod(pod, "fail") </ins> if status == nil { return fmt.Errorf("pod %s on node %s had incorrect containers: %#v", pod.Name, pod.Spec.NodeName, pod.Status) }

Discussion:
We would like to know early if the behavior is broken on any container runtime implementation. This is motivated by the discussion under the PR:
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 node
/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
Change:
// applySandboxLinuxOptions applies LinuxPodSandboxConfig to dockercontainer.HostConfig and dockercontainer.ContainerCreateConfig. func (ds *dockerService) applySandboxLinuxOptions(hc *dockercontainer.HostConfig, lc *runtimeapi.LinuxPodSandboxConfig, createConfig *dockertypes.ContainerCreateConfig, image string) error { // Apply Cgroup options. <del> // TODO: Check if this works with per-pod cgroups. hc.CgroupParent = lc.GetCgroupParent() </del> <ins> cgroupParent, err := ds.GenerateExpectedCgroupParent(lc.GetCgroupParent()) if err != nil { return err } hc.CgroupParent = cgroupParent </ins> // Apply security context. applySandboxSecurityContext(lc, createConfig.Config, hc, ds.networkPlugin)

Discussion:
Kubernetes version (use ): v1.5.0-alpha.1.2189+-dirty docker: 1.12.3 Environment: fedora24 docker-engine-1.12.3-1.fc24.x86_64 What happened: if docker Cgroup Driver=cgroupfs, and set --cgroup-driver=systemd in kubelet, then enable --experimental-cgroups-per-qos=true; The container cgroup some is not correct. How to reproduce it (as minimally and precisely as possible): Anything else do we need to know: 1) docker Cgroup Driver=cgroupfs and --cgroup-driver=cgroupfs in kubelet works well 2) docker Cgroup Driver=systemd and --cgroup-driver=systemd in kubelet works well
help check, thanks.
In Kubernetes 1.6, we can work to detect this case and return an error. IMHO its a configuration error to have docker running with a cgroupfs driver paired with the kubelet running the systemd cgroup driver. /cc
We can also document the compatibility matrix for now.
Change:
type priorityMetadata struct { podLimits               *schedulernodeinfo.Resource podSelector             labels.Selector <del> controllerRef           *metav1.OwnerReference </del> podFirstServiceSelector labels.Selector podTopologySpreadMap    *podTopologySpreadMap }

Discussion:
/sig scheduling /priority important-soon See as an example. Part of This shouldn't need a PostFilter Plugin, it is not worth caching the result of metav1.GetControllerOf. /assign
Change:
o.Encoder = f.JSONEncoder() o.ShortOutput = cmdutil.GetFlagString(cmd, "output") == "name" o.Record = cmdutil.GetRecordFlag(cmd) <ins> o.Local = cmdutil.GetFlagBool(cmd, "local") </ins> o.ChangeCause = f.Command(cmd, false) o.PrintObject = f.PrintObject o.Cmd = cmd

Discussion:
It tries to contact the api server for the discovery docs and fails because no api server is running. Could first look in its local cache if it's passed --local?
I think here has similar meaning as , it will not contact api-server to do real patch, but it will fetch the resource from api-server. What you mean look in it's local cache? to find the resource in local cache? I think you have specified the resource in your command line.
Use of --local flag should completely eliminate communication with api-server I have sent a PR which should fix this issue A command like kubectl set image --local -f busybox=busybox:1.26 -o yaml should load the local yaml file and print out the patched version (image should get updated to busybox:1.26) in yaml format on the screen. With the submitted patch such behavior is achived
Change:
r.backoff.UpdateBackoff(r.URL(), err, resp.StatusCode) } if err != nil { <del> // "Connection reset by peer", "Connection refused" or "apiserver is shutting down" are usually a transient errors. </del> <ins> // "Connection reset by peer" or "apiserver is shutting down" are usually a transient errors. </ins> // Thus in case of "GET" operations, we simply retry it. // We are not automatically retrying "write" operations, as // they are not idempotent.

Discussion:
/kind bug changed behavior of client-go on connection refused errors, which changed a short wait and an "invalid host/port" error into a long retry wait and a confusing "internal server" error /assign Originally posted by in
/sig api-machinery
/milestone v1.18
I linked
Hello, bug-triage here. Just want to make sure we are still staffed and on-track for v1.18 code freeze
thanks, I will get to this tomorrow.
gentle ping
Change:
"k8s.io/apimachinery/pkg/util/intstr" "k8s.io/apimachinery/pkg/util/validation" "k8s.io/apimachinery/pkg/util/validation/field" <del> utilfeature "k8s.io/apiserver/pkg/util/feature" </del> "k8s.io/kubernetes/pkg/apis/apps" api "k8s.io/kubernetes/pkg/apis/core" apivalidation "k8s.io/kubernetes/pkg/apis/core/validation" <del> "k8s.io/kubernetes/pkg/features" </del> ) // ValidateStatefulSetName can be used to check whether the given StatefulSet name is valid.

Discussion:
This applies to StatefulSetStartOrdinal feature gate. Field validation should be done regardless of the feature gate state. From
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 apps
Change:
framework.Logf("Pod %v succeeded ", pod.Name) return nil } <ins> func conditionType(condition interface{}) string { return string(condition.(v1.PersistentVolumeClaimCondition).Type) } </ins>

Discussion:
[x] test approval issue : [x] test pr : [x] Flake [x] two weeks soak end date : 31 Oct 2023 [X] test promotion pr : [X] remove endpoint from According to following APIsnoop query, there are three PersistentVolume and three PersistentVolumeClaim endpoints that are untested. Using a number of existing e2e test practices a new has been created to provide future Conformance coverage for the 6 endpoints. The e2e logs for this test are listed below. This query shows the following PV and PVC endpoints are hit within a short period of running this e2e test. If a test with these calls gets merged, test coverage will go up by 6 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance
/triage accepted /cc
/reopen For tracking the rest of the steps to Promotion
Reopened this issue. <detailsIn response to : /reopen For tracking the rest of the steps to Promotion 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