jiebi/CodeConvo huggingface dataset:
Change:
break } } <del> dropDisabledFields(crd, nil) </del> } // PrepareForUpdate clears fields that are not allowed to be set by end users on update.

Discussion:
This is the tracking issue of promoting CRD validation rules to GA: Listed the blocking issues/features below: [x] [x] [x] [x] Issues be aware of but should not be a GA blocker [ ] [ ] [ ] [ ] [ ] /sig api-machinery /triage accepted
/assign
/cc
Change:
MarkVolumeAsUnmounted(podName volumetypes.UniquePodName, volumeName v1.UniqueVolumeName) error // Marks the specified volume as having been globally mounted. <del> MarkDeviceAsMounted(volumeName v1.UniqueVolumeName) error </del> <ins> MarkDeviceAsMounted(volumeName v1.UniqueVolumeName, devicePath string) error </ins> // Marks the specified volume as having its global mount unmounted. MarkDeviceAsUnmounted(volumeName v1.UniqueVolumeName) error

Discussion:
We fixed invalid device path in bunch of places via - but call still could use invalid device path. That check can sometimes use invalid path and hence can cause UnmountDevice operation to fails even though device has already been unmounted. /sig storage /sig openstack /assign
Actually this does not affect version 1.10 onwards. Not sure if 1.9 is still supported. I think I will close this for now. /close
I just noticed that 1.9 is still supported and hence it is probably worth fixing there for now.
How come the check can "sometimes" use invalid device path?
So on Cinder for example - call would return something like as attach device path. But if you see the linked PR(), will do a and use that device path for global mount. In general it is always a good idea to use device path returned by as single source of truth. This applies to something like EBS with NVMe too where device is discovered via call (but nvme disks aren't directly affected by this bug because returned device path on EBS is bogus).
So on EBS with NVMe for example - check will always fail (but still return success) because it will use something like as device path which does not actually exist on the node.
You said the issue only happens "sometimes". Can you clarify why it only happens occasionally?
doesn't the linked PR make it clear? detection based on the drive serial number (aka It's cinder ID) on the kubelet itself. As for why - Cinder sometimes returns wrong device path on call, I don't know. But it happens and we have worked around it.
Fixed by
Change:
return &api.Pod{}, nil } <ins> func (c *FakePods) Watch(label, field labels.Selector, resourceVersion string) (watch.Interface, error) { c.Fake.Actions = append(c.Fake.Actions, FakeAction{Action: "watch-pods", Value: resourceVersion}) return c.Fake.Watch, c.Fake.Err } </ins> func (c *FakePods) Bind(bind *api.Binding) error { c.Fake.Actions = append(c.Fake.Actions, FakeAction{Action: "bind-pod", Value: bind.Name}) return nil

Discussion:
PodInterface should have Watch method behaving in the same way as ServiceInterface.Watch does. Use case: a monitoring system (namely Prometheus) expects to get the list of monitored servers performing a DNS-SD query. Special service (similar to kube2sky shipped with Kubernetes) mirrors status of running Pods into etcd, which is in turn monitored by SkyDNS server and exported as DNS-SD. Schematically the data flow looks like this: Kubernetes -kube2sky -etcd -SkyDNS -Prometheus. The biggest challenge is to deliver list of all running pods from Kubernetes to kube2sky. Currently kube2sky can only poll Kubernetes with PodInterface.List() each N seconds, which is not efficient. Having a Watch method would be much better.
cc Do you know why we do not support watch?
Every object should support Watch.
Watching status doesn't currently work -- that's .
I agree with OP. This is just an accident of history; some boilerplate in the client isn't completely filled out. As Brian mentions, not every field is currently watchable but that's being addressed elsewhere.
This is relevant to your interests potentially w/ your work on
This is a pretty simple change if someone wants to get their feet wet. :)
I'll work on it.
Change:
--can-ip-forward  --metadata-from-file "$3" "$4"; then if (( attempt > 5 )); then <del> echo -e "${color_red}Failed to create instance template $1 ${color_norm}" </del> <ins> echo -e "${color_red}Failed to create instance template $1 ${color_norm}" >&2 </ins> exit 2 fi <del> echo -e "${color_yellow}Attempt $(($attempt+1)) failed to create instance template $1. Retrying.${color_norm}" </del> <ins> echo -e "${color_yellow}Attempt $(($attempt+1)) failed to create instance template $1. Retrying.${color_norm}" >&2 </ins> attempt=$(($attempt+1)) else break

Discussion:
See issue as the roll-up for node upgrades. tl;dr: Update MIG template, then call a MIG rollingupdate. More details: When upgrading nodes, an in-place upgrade must worry about leftover state on the boot disk, VM configuration like IP tables, and the idempotency of salt. Getting a fresh VM instead would remove these concerns and provide a clean state for a new node. Furthermore, a versioned node spec () includes the tuple of (kubelet, kube-proxy, docker, kernel/OS). In the general case, changing docker or the kernel/OS means we have to stop the running pods. Once know we have to stop the pods, the simplest upgrade mechanism is to totally down the node and provision a new one. Provisioning a new node is also a great backup to have for node repairs. To be clear, though, this issue is entirely separate from node repairs; once we have the capability to grow the cluster by adding new nodes, this mechanism, and other repair mechanisms, will build on top of that capability. This was blocked by: nodes joining a running cluster (template-only metadata) References: The most relevant discussion regarding the worries of complications with state while doing in-place upgrades is .
FWIW, I think we need this as a fallback to repair completely borked nodes? That is, it may not be necessary for upgrades per se, but could end up being independently useful.
Thanks for the comment, I updated the description to be clear about what this issue is addressing. Having the ability to add new nodes to a cluster will both enable this upgrade path as well as give us a great "hammer" to use for repairs.
Working on this now.
Change:
} } <ins> func TestNodePortUDP(t *testing.T) { nodeIP := net.ParseIP("100.101.102.103") ipt := iptablestest.NewFake() ipvs := ipvstest.NewFake() ipset := ipsettest.NewFake(testIPSetVersion) fp := NewFakeProxier(ipt, ipvs, ipset, []net.IP{nodeIP}) svcIP := "10.20.30.41" svcPort := 80 svcNodePort := 3001 svcPortName := proxy.ServicePortName{ NamespacedName: makeNSN("ns1", "svc1"), Port:           "p80", } makeServiceMap(fp, makeTestService(svcPortName.Namespace, svcPortName.Name, func(svc *api.Service) { svc.Spec.Type = "NodePort" svc.Spec.ClusterIP = svcIP svc.Spec.Ports = []api.ServicePort{{ Name:     svcPortName.Port, Port:     int32(svcPort), Protocol: api.ProtocolUDP, NodePort: int32(svcNodePort), }} }), ) epIP := "10.180.0.1" makeEndpointsMap(fp, makeTestEndpoints(svcPortName.Namespace, svcPortName.Name, func(ept *api.Endpoints) { ept.Subsets = []api.EndpointSubset{{ Addresses: []api.EndpointAddress{{ IP: epIP, }}, Ports: []api.EndpointPort{{ Name: svcPortName.Port, Port: int32(svcPort), }}, }} }), ) fp.nodePortAddresses = []string{"0.0.0.0/0"} fp.syncProxyRules() // Check ipvs service and destinations epVS := &netlinktest.ExpectedVirtualServer{ VSNum: 2, IP: nodeIP.String(), Port: uint16(svcNodePort), Protocol: string(api.ProtocolTCP), RS: []netlinktest.ExpectedRealServer{{ IP: epIP, Port: uint16(svcPort), }}} checkIPVS(t, fp, epVS) // check ipSet rules epIPSet := netlinktest.ExpectedIPSet{ kubeNodePortSetUDP: {{ Port:     svcNodePort, Protocol: strings.ToLower(string(api.ProtocolUDP)), SetType:  utilipset.BitmapPort, }}, } checkIPSet(t, fp, epIPSet) // Check iptables chain and rules epIpt := netlinktest.ExpectedIptablesChain{ string(kubeServicesChain): {{ JumpChain: string(KubeNodePortChain), MatchSet: kubeNodePortSetUDP, }}, string(KubeNodePortChain): {{ JumpChain: string(KubeMarkMasqChain), MatchSet: "", }}, } checkIptables(t, ipt, epIpt) } </ins> func TestNodePort(t *testing.T) { ipt := iptablestest.NewFake() ipvs := ipvstest.NewFake()

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? /kind bug What happened: In ipvs proxy mode, most service functions like "nodeport/loadbalance" is realized by the association of iptables/ipset/ipvs, yet most ipvs proxier ut only verified ipvs rules, which can't ensure service is functional. What you expected to happen: Check both ipvs rules and iptables chains/rules, ipset entries in ipvsproxier ut.
/sig network /area ipvs /assign
What's the current UT coverage number?
Current is 50.2%.
So, can we achieve 70%?
Yeah, we can do that, and that's definitely necessary.
Change:
func TestProxyHandler(t *testing.T) { target := &targetHTTPHandler{} <del> targetServer := httptest.NewTLSServer(target) </del> <ins> targetServer := httptest.NewUnstartedServer(target) if cert, err := tls.X509KeyPair(svcCrt, svcKey); err != nil { t.Fatal(err) } else { targetServer.TLS = &tls.Config{Certificates: []tls.Certificate{cert}} } targetServer.StartTLS() </ins> defer targetServer.Close() tests := map[string]struct {

Discussion:
an APIService that routes to an external API server (e.g. service catalog) via a service in namespace a caBundle in the APIService the external API server with a certificate signed for Result: Normal API requests (get/put/post) work as expected Normal watch requests work as expected Upgrade requests (e.g. websocket watch requests) return a 500 error with text like cc
Change:
http_archive( name = "io_k8s_repo_infra", <del> sha256 = "462dcc769f29e9eee16499edb818e2fc2ffc24efea28300d53bbc098d27d322c", strip_prefix = "repo-infra-f85734f673056977d8ba04b0386394b684ca2acb", urls = mirror("https://github.com/kubernetes/repo-infra/archive/f85734f673056977d8ba04b0386394b684ca2acb.tar.gz"), </del> <ins> sha256 = "f6d65480241ec0fd7a0d01f432938b97d7395aeb8eefbe859bb877c9b4eafa56", strip_prefix = "repo-infra-9f4571ad7242bf3ec4b47365062498c2528f9a5f", urls = mirror("https://github.com/kubernetes/repo-infra/archive/9f4571ad7242bf3ec4b47365062498c2528f9a5f.tar.gz"), </ins> ) http_archive(

Discussion:
What happened: that uses Ubuntu image fails during Kubernetes installation: Full log: Indeed, is not present on nodes. Only and subdirectories are present in . I don't know what code removed (or did not package) and symlinks, but they should be there. What you expected to happen: Kubernetes is installed correctly and e2e tests start. How to reproduce it (as minimally and precisely as possible): Run in a PR. Anything else we need to know?: Prow job: It seems to be the only one that uses Ubuntu image. This command works and installs Kubernetes correctly: is present there. Dunno what the prow job does differently.
/sig testing
the nodes receive files staged via the release scripts and downloaded by the cluster/ scripts, I don't think sig testing will be the right group to fix this. SIG node has some owners related to the various images that might have some idea how this is setup
/sig release this is probably an issue in the release scripts
cc:
PTAL, it looks like a stupid bug somewhere.
Q: Did this ever run successfully?
Most probably not, I haven't found a working e2e tests on Ubuntu. Still, works well, there must be something slightly different in test setup scripts.
ping again? Short recap: This works: is there. ( is symlink to ) This does not work: Fails with: does not exist. The prow job must do something slightly different than kube-
The serial job is using GCI (COS): Is the non-serial job working? It uses ubuntu: If not, my guess from the last time I remember looking was checking the release bundle and ensuring it includes the ubuntu dir
No, same error. created by contains , released bundles (e.g. ) contains it too. Otherwise would not work with an Ubuntu image. So what does the prow job differently? Does something there prune the scripts? is just a symlink to , does it make a difference?
Found it, creates without any symlinks. It looks like bazel limitation. I filled to explicitly create the symlinks when tarball is created. BTW, if and use different way to produce tarballs, who / when tests the ones created by ?
Most of CI is using make release or equivalent. Presumbit uses bazel. Jan Šafránek <:
/area release-eng /milestone v1.16 /priority important
/priority important-soon
Change:
func IsDeleted(info *resource.Info, o *WaitOptions) (runtime.Object, bool, error) { endTime := time.Now().Add(o.Timeout) for { <ins> if len(info.Name) == 0 { return info.Object, false, fmt.Errorf("resource name must be provided") } </ins> gottenObj, err := o.DynamicClient.Resource(info.Mapping.Resource).Namespace(info.Namespace).Get(info.Name, metav1.GetOptions{}) if apierrors.IsNotFound(err) { return info.Object, true, nil

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: I created a job with metadata.generateName twice and waited for completion, but got: panic: interface conversion: runtime.Object is unstructured.UnstructuredList, not unstructured.Unstructured What you expected to happen: kubectl to wait for the last job to complete. How to reproduce it (as minimally and precisely as possible): kubectl create -f kubectl create -f kubectl wait --for=condition=complete -f (shortened): apiVersion: batch/v1 kind: Job metadata: generateName: my-job- Anything else we need to know?: Environment: Kubernetes version (use ): 1.11.3 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
I have to choose a sig, but I am not sure which one is right...
Reiterating the mentions to trigger a notification: <detailsIn response to : I have to choose a sig, but I am not sure which one is right... 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 cli /sig apps
/assign
kubectl get -f also doesn't work as expected.
/remove-sig apps
Change:
// schedulingTimeout is longer specifically because sometimes we need to wait // awhile to guarantee that we've been patient waiting for something ordinary // to happen: a pod to get scheduled and move into Ready <del> const schedulingTimeout = 5 * time.Minute </del> <ins> const schedulingTimeout = 10 * time.Minute </ins> var _ = framework.KubeDescribe("DisruptionController", func() { f := framework.NewDefaultFramework("disruption")

Discussion:
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .

https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite}
[FLAKE-PING] This flaky-test issue would love to have more attention.
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
https://k8s- Failed: [] DisruptionController evictions: too few pods, replicaSet, percentage =should not allow an eviction {Kubernetes e2e suite} Happened on a presubmit run in .
Change:
} baseNamespace := baseNamespaceObj.(*api_v1.Namespace) if baseNamespace.DeletionTimestamp != nil { <del> nc.delete(baseNamespace) </del> <ins> if err := nc.delete(baseNamespace); err != nil { glog.Errorf("Failed to delete %s: %v", namespace, err) nc.eventRecorder.Eventf(baseNamespace, api.EventTypeNormal, "DeleteFailed", "Namespace delete failed: %v", err) nc.deliverNamespace(namespace, 0, true) } </ins> return }

Discussion:
In PR the specific resource types are handled explicitly. Need to delete them in more generic way, in a similar way that namespace controller does.
- switching this to 1.6 as it's too late for 1.5. ok? (please switch it right back if you disagree)
did fix this?
Please close or move to next-candidate with work remaining to be done.
Yes fixed by
Change:
healthzServer:         healthzServer, ipvs:                  ipvs, ipvsScheduler:         scheduler, <del> ipGetter:              &realIPGetter{nl: NewNetLinkHandle()}, </del> <ins> ipGetter:              &realIPGetter{nl: NewNetLinkHandle(isIPv6)}, </ins> iptablesData:          bytes.NewBuffer(nil), filterChainsData:      bytes.NewBuffer(nil), natChains:             bytes.NewBuffer(nil), natRules:              bytes.NewBuffer(nil), filterChains:          bytes.NewBuffer(nil), filterRules:           bytes.NewBuffer(nil), <del> netlinkHandle:         NewNetLinkHandle(), </del> <ins> netlinkHandle:         NewNetLinkHandle(isIPv6), </ins> ipset:                 ipset, nodePortAddresses:     nodePortAddresses, networkInterfacer:     utilproxy.RealNetwork{},

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /area ipv6 /area ipvs /sig network What happened: In an ipv6-only cluster with proxy-mode=ipvs the entries for NodePort in ipvs are created for ipv4 addresses. The target's (if there are any) consists of ipv6 addresses (wrongly) interpreted as ipv4; Attempts to use the NodePort with ipv6 addresses are black-holed. What you expected to happen: Ipv6 addresses to the nodes should be used for NotePort and the LB-targets shall be the ipv6 address of the pods. Traffic to NodePorts shall be distributed among the (ipv6) endpoints. How to reproduce it (as minimally and precisely as possible): Setup an ipv6-only cluster Create a service with type with endpoints Try to connect to the NodePort Do Anything else we need to know?: The nodes have both ipv4 and ipv6 addresses and it is possible that if the nodes only had ipv6 addresses it would work (I havn't tested). But even in an ipv6-only k8s cluster the nodes almost always need ipv4 addresses for other purposes. Environment: Kubernetes version (use ):Cloud provider or hardware configuration: Kvm VMs on Ubuntu 18.04.01 LTS OS (e.g. from /etc/os-release): Own BusyBox based system Kernel (e.g. ):Install tools: None Others:
The NodeIPs() function seem to return only ipv4 addresses.
I can't see why (yet) since is used in the GetLocalAddresses function
/cc Please give a hint before I dive into the netlink code.
This issue is used as an example here;
The functions filters on Src != nil . But ipv6 addresses seems to have Src == nil always. As it is this function will never return any ipv6 addresses.
Change:
f.PodClient().DeleteSync(burstablePodName, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) f.PodClient().DeleteSync(bestEffortPodName, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) f.PodClientNS(kubeapi.NamespaceSystem).DeleteSync(criticalPodName, &metav1.DeleteOptions{}, framework.DefaultPodDeletionTimeout) <del> err := f.ClientSet.SchedulingV1().PriorityClasses().Delete(systemCriticalPriorityName, &metav1.DeleteOptions{}) framework.ExpectNoError(err) </del> // Log Events logPodEvents(f) logNodeEvents(f)

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Setting PodPriority directly when adminssion Priority enable,the Pod is rejected. To fix this, we need to create new priority classes for these tests. Which jobs are failing: Which test(s) are failing: I0822 19:01:41.165] should be able to create and delete a critical pod [It] Since when has it been failing: Testgrid link: Reason for failure: because adminssion Priority enableIf the priority class is not found, the Pod is rejected. Anything else we need to know:
/area e2e-test-framework /sig testing /kind bug /priority important-soon
This has now changed to this error: /reopen
Reopened this issue. <detailsIn response to : This has now changed to this error: /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
For reference: testgrid link /milestone v1.17
is this still in progress?
pr has updated, PTAL.
looks like has to merge for this to close
/milestone v1.18
Change:
http.NotFound(w, r) } } <ins> // GenerateExpectedCgroupParent returns cgroup parent in syntax expected by cgroup driver func (ds *dockerService) GenerateExpectedCgroupParent(cgroupParent string) (string, error) { if len(cgroupParent) > 0 { // if docker uses the systemd cgroup driver, it expects *.slice style names for cgroup parent. // if we configured kubelet to use --cgroup-driver=cgroupfs, and docker is configured to use systemd driver // docker will fail to launch the container because the name we provide will not be a valid slice. // this is a very good thing. if ds.cgroupDriver == "systemd" { systemdCgroupParent, err := kubecm.ConvertCgroupFsNameToSystemd(cgroupParent) if err != nil { return "", err } cgroupParent = systemdCgroupParent } } glog.V(3).Infof("Setting cgroup parent to: %q", cgroupParent) return cgroupParent, nil } </ins>

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.