jiebi/CodeConvo huggingface dataset:
Code change:
When creating a service passing the annotation , two IPs are created in the service, a private and a public: Having a private IP is not a desired scenario for service discovery in federated global environments. If we have, for example, a cluster in GKE and join a local OpenStack cluster, this private IP is written in the DNS zone but the GKE cluster won't be able to access it. We could add an annotation to say we don't want the private IP to be registered in service's LoadBalancer Ingress field, like: or And when it's false, only the public IP would be written in the service, therefore in the DNS zone /kind feature
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 /sig federation
'' sounds better.
I don't like adding annotations just to make things work. I counter-propose just not publishing the private IP whenever there is also a floating-ip (without a configuration option to control this behaviour).

Related discussion:
text: return nil, fmt.Errorf("Error creating LB floatingip %+v: %v", floatIPOpts, err) } } <ins> status := &v1.LoadBalancerStatus{} </ins> if floatIP != nil { <del> status.Ingress = append(status.Ingress, v1.LoadBalancerIngress{IP: floatIP.FloatingIP}) </del> <ins> status.Ingress = []v1.LoadBalancerIngress{{IP: floatIP.FloatingIP}} } else { status.Ingress = []v1.LoadBalancerIngress{{IP: loadbalancer.VipAddress}} </ins> } if lbaas.opts.ManageSecurityGroups {
Code change:
When creating a service passing the annotation , two IPs are created in the service, a private and a public: Having a private IP is not a desired scenario for service discovery in federated global environments. If we have, for example, a cluster in GKE and join a local OpenStack cluster, this private IP is written in the DNS zone but the GKE cluster won't be able to access it. We could add an annotation to say we don't want the private IP to be registered in service's LoadBalancer Ingress field, like: or And when it's false, only the public IP would be written in the service, therefore in the DNS zone /kind feature
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 /sig federation
'' sounds better.
I don't like adding annotations just to make things work. I counter-propose just not publishing the private IP whenever there is also a floating-ip (without a configuration option to control this behaviour).

Related discussion:
text: } status := &v1.LoadBalancerStatus{} <del> status.Ingress = []v1.LoadBalancerIngress{{IP: vip.Address}} </del> if floatingPool != "" && !internalAnnotation { floatIPOpts := floatingips.CreateOpts{ FloatingNetworkID: floatingPool,
Code change:
When creating a service passing the annotation , two IPs are created in the service, a private and a public: Having a private IP is not a desired scenario for service discovery in federated global environments. If we have, for example, a cluster in GKE and join a local OpenStack cluster, this private IP is written in the DNS zone but the GKE cluster won't be able to access it. We could add an annotation to say we don't want the private IP to be registered in service's LoadBalancer Ingress field, like: or And when it's false, only the public IP would be written in the service, therefore in the DNS zone /kind feature
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 /sig federation
'' sounds better.
I don't like adding annotations just to make things work. I counter-propose just not publishing the private IP whenever there is also a floating-ip (without a configuration option to control this behaviour).

Related discussion:
text: return nil, fmt.Errorf("Error creating floatingip for openstack load balancer %s: %v", name, err) } <del> status.Ingress = append(status.Ingress, v1.LoadBalancerIngress{IP: floatIP.FloatingIP}) </del> <ins> status.Ingress = []v1.LoadBalancerIngress{{IP: floatIP.FloatingIP}} } else { status.Ingress = []v1.LoadBalancerIngress{{IP: vip.Address}} </ins> } return status, nil
Code change:
<!-- 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: FC plugin returns TargetWWNs at GetVolumeName(), but TargetWWNs are not unique identifier if user has multiple volumes from same target wwn. As a result, after introducing attach/detach functions, FC plugin always fails to attach volumes if a pod requests 2+ luns. The GetVolumeName() is called from GetUniqueVolumeNameFromSpec() during Pod creation. FC plugin should return unique identifier in the GetVolumeName(). If user uses WWID to specify FC volume, this problem doesn't happen because the WWID is unique identifier. What you expected to happen: All FC volumes are attached to pod. How to reproduce it (as minimally and precisely as possible): Create two PVs and PVCs which uses same target wwn. Create Pod with these two PVCs Anything else we need to know?: Environment: Kubernetes version (use ):Install tools: local-up- /cc
/sig storage
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

Related discussion:
text: return "", err } <del> if len(volumeSource.TargetWWNs) != 0 { </del> <ins> // API server validates these parameters beforehand but attach/detach // controller creates volumespec without validation. They may be nil // or zero length. We should check again to avoid unexpected conditions. if len(volumeSource.TargetWWNs) != 0 && volumeSource.Lun != nil { </ins> // TargetWWNs are the FibreChannel target worldwide names <del> return fmt.Sprintf("%v", volumeSource.TargetWWNs), nil </del> <ins> return fmt.Sprintf("%v:%v", volumeSource.TargetWWNs, *volumeSource.Lun), nil </ins> } else if len(volumeSource.WWIDs) != 0 { // WWIDs are the FibreChannel World Wide Identifiers return fmt.Sprintf("%v", volumeSource.WWIDs), nil
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: If a pod is already running in the default namespace with the expected name (i.e. ), the PV recycle method just assumes it's a recycler pod. However, if it is not a recycler, it could result in the volume being reused without the data being cleared. What you expected to happen: The recycled volume should not be reused until the data has been verifiably deleted. The easiest approach would be to make it an error to not run the recycler pod successfully, i.e. delete these lines: I think that should be safe, since the recycler will retry. Other errors in that method should also be considered fatal, e.g.:
/cc
How about generating a unique name for each recycler pod so that it doesn't matter what existing pods are named?
Could someone from your team pick this up?
Ack
OpenShift runs the recycler pod in a dedicated namespace, not visible to users. Maybe it could be a good idea to do so also in Kubernetes. Anyway, killing the old recycler is probably the best option - it could be forged by user to block recycling and cheat quota. /assign
Agree with running in a dedicated namespace, but it sounds like this feature is just being deprecated, so it might not be worth the effort. Thanks for picking this up.

Related discussion:
text: // attempted before returning. // // In case there is a pod with the same namespace+name already running, this <del> // function assumes it's an older instance of the recycler pod and watches // this old pod instead of starting a new one. </del> <ins> // function deletes it as it is not able to judge if it is an old recycler // or user has forged a fake recycler to block Kubernetes from recycling.// </ins> // //  pod - the pod designed by a volume plugin to recycle the volume. pod.Name //        will be overwritten with unique name based on PV.Name.
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: If a pod is already running in the default namespace with the expected name (i.e. ), the PV recycle method just assumes it's a recycler pod. However, if it is not a recycler, it could result in the volume being reused without the data being cleared. What you expected to happen: The recycled volume should not be reused until the data has been verifiably deleted. The easiest approach would be to make it an error to not run the recycler pod successfully, i.e. delete these lines: I think that should be safe, since the recycler will retry. Other errors in that method should also be considered fatal, e.g.:
/cc
How about generating a unique name for each recycler pod so that it doesn't matter what existing pods are named?
Could someone from your team pick this up?
Ack
OpenShift runs the recycler pod in a dedicated namespace, not visible to users. Maybe it could be a good idea to do so also in Kubernetes. Anyway, killing the old recycler is probably the best option - it could be forged by user to block recycling and cheat quota. /assign
Agree with running in a dedicated namespace, but it sounds like this feature is just being deprecated, so it might not be worth the effort. Thanks for picking this up.

Related discussion:
text: {v1.EventTypeWarning, "Unable to mount volumes for pod "recycler-for-podRecyclerFailure_default(3c9809e5-347c-11e6-a79b-3c970e965218)": timeout expired waiting for volumes to attach/mount"}, {v1.EventTypeWarning, "Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "default"/"recycler-for-podRecyclerFailure". list of unattached/unmounted"}, }, <del> expectedError: "Pod was active on the node longer than specified deadline", </del> <ins> expectedError: "failed to recycle volume: Pod was active on the node longer than specified deadline", </ins> }, { // Recycler pod gets deleted
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: If a pod is already running in the default namespace with the expected name (i.e. ), the PV recycle method just assumes it's a recycler pod. However, if it is not a recycler, it could result in the volume being reused without the data being cleared. What you expected to happen: The recycled volume should not be reused until the data has been verifiably deleted. The easiest approach would be to make it an error to not run the recycler pod successfully, i.e. delete these lines: I think that should be safe, since the recycler will retry. Other errors in that method should also be considered fatal, e.g.:
/cc
How about generating a unique name for each recycler pod so that it doesn't matter what existing pods are named?
Could someone from your team pick this up?
Ack
OpenShift runs the recycler pod in a dedicated namespace, not visible to users. Maybe it could be a good idea to do so also in Kubernetes. Anyway, killing the old recycler is probably the best option - it could be forged by user to block recycling and cheat quota. /assign
Agree with running in a dedicated namespace, but it sounds like this feature is just being deprecated, so it might not be worth the effort. Thanks for picking this up.

Related discussion:
text: expectedEvents: []mockEvent{ {v1.EventTypeNormal, "Successfully assigned recycler-for-podRecyclerDeleted to 127.0.0.1"}, }, <del> expectedError: "recycler pod was deleted", </del> <ins> expectedError: "failed to recycle volume: recycler pod was deleted", </ins> }, { // Another recycler pod is already running <del> name:        "RecyclerRunning", existingPod: newPod("podOldRecycler", v1.PodRunning, ""), createPod:   newPod("podNewRecycler", v1.PodFailed, "mock message"), eventSequence: []watch.Event{ // Old pod succeeds newPodEvent(watch.Modified, "podOldRecycler", v1.PodSucceeded, ""), }, // No error = old pod succeeded. If the new pod was used, there // would be error with "mock message". expectedError: "", }, { // Another recycler pod is already running and fails name:        "FailedRecyclerRunning", existingPod: newPod("podOldRecycler", v1.PodRunning, ""), createPod:   newPod("podNewRecycler", v1.PodFailed, "mock message"), eventSequence: []watch.Event{ // Old pod failure newPodEvent(watch.Modified, "podOldRecycler", v1.PodFailed, "Pod was active on the node longer than specified deadline"), }, // If the new pod was used, there would be error with "mock message". expectedError: "Pod was active on the node longer than specified deadline", </del> <ins> name:          "RecyclerRunning", existingPod:   newPod("podOldRecycler", v1.PodRunning, ""), createPod:     newPod("podNewRecycler", v1.PodFailed, "mock message"), eventSequence: []watch.Event{}, expectedError: "old recycler pod found, will retry later", </ins> }, }
Code change:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: Kubeadm E2E test is currently broken due to the commit I report the same issue on my local cluster. If I revert PR , everything works fine. We believe the current weave-net plugin doesn't work with the CNI version change. Right now all kubeadm related development is blocked on this. Could we consider reverting this change from head until we figure out what's wrong in weave-net/CNI? More context in
/assign
Please reopen this in kubernetes/kubeadm. There is an issue as e2e tests & PR job are failing, but locally the CNI bit seem to work for me, so I think it has something with building the debs to do. Not technically. We just don't have any coverage right now. Not IMO. We just need to forward-fix the issue. Closing this; you can reopen in kubernetes/kubeadm
kubeadm e2e test still red. Do you have any progress or hint in terms how to fix it forward? Just to clarify, If I install k8s and kubeadm locally using deb, I can repro the issue on my test box. I could believe it's sth wrong with debs. In the meantime, CNI and plug-in like weave-net change is a big deal. We clearly didn't test it thoroughly for this PR. Reverting the change seems to be the clean solution.
FYI kubernetes/release bumps new CNI releases for deb/rpm packages.
Thanks.
Is this the fix needed to fix these tests?
I actually think that will take us in the other direction. During the kubeadm e2e tests, we use the deb packages built by bazel. During our official release process, we use the debs built by anago (in the release repo). Bumping CNI in our bazel build broken our e2e tests. Bumping CNI in the release repo scripts will similarly break our official release builds as well. If I understand the problem correctly, the only way to fix both of them is for the CNI providers like weave-net to be updated to handle the changes of upgrading CNI to 0.6.0.
I think this issue worth some more discussion. Re-open the case as it might not be affecting kubeadm only
sorry, i cannot reopen the issue as it's closed by But let's continue to discuss the option here.
Yes, I think so
This will be fixed by ; this was due to the CNI binaries being extracted in the wrong place. It is kind of a kubeadm packaging issue. (Reopening just to make the PR close this)
nice find!

Related discussion:
text: pkg_tar( name = "kubernetes-cni-data", <del> package_dir = "/opt/cni", </del> <ins> package_dir = "/opt/cni/bin", </ins> deps = ["@kubernetes_cni//file"], )
Code change:
/kind bug Right now we do not validate PV updates so admin can update at any time. Kubernetes has no facility to reflect this update - it won't magically re-mount an existing volume to e.g. a different NFS server. IMO the PersistentVolumeSource to be read-only and set to stone once created.
/assign
I think it is a good idea to make the VolumeSource read-only but I am afraid ship has sailed in v1 and existing code/tooling that relies on the ability to modify PVs will break as a result of this change.
- do you have any advice on how we should proceed on fixing this issue?

Related discussion:
text: func ValidatePersistentVolumeUpdate(newPv, oldPv *api.PersistentVolume) field.ErrorList { allErrs := field.ErrorList{} allErrs = ValidatePersistentVolume(newPv) <ins> // PersistentVolumeSource should be immutable after creation. if !apiequality.Semantic.DeepEqual(newPv.Spec.PersistentVolumeSource, oldPv.Spec.PersistentVolumeSource) { allErrs = append(allErrs, field.Forbidden(field.NewPath("spec", "persistentvolumesource"), "is immutable after creation")) } </ins> newPv.Status = oldPv.Status return allErrs }
Code change:
/kind bug Right now we do not validate PV updates so admin can update at any time. Kubernetes has no facility to reflect this update - it won't magically re-mount an existing volume to e.g. a different NFS server. IMO the PersistentVolumeSource to be read-only and set to stone once created.
/assign
I think it is a good idea to make the VolumeSource read-only but I am afraid ship has sailed in v1 and existing code/tooling that relies on the ability to modify PVs will break as a result of this change.
- do you have any advice on how we should proceed on fixing this issue?

Related discussion:
text: } <ins> func TestValidatePersistentVolumeSourceUpdate(t *testing.T) { validVolume := testVolume("foo", "", api.PersistentVolumeSpec{ Capacity: api.ResourceList{ api.ResourceName(api.ResourceStorage): resource.MustParse("1G"), }, AccessModes: []api.PersistentVolumeAccessMode{api.ReadWriteOnce}, PersistentVolumeSource: api.PersistentVolumeSource{ HostPath: &api.HostPathVolumeSource{ Path: "/foo", Type: newHostPathType(string(api.HostPathDirectory)), }, }, StorageClassName: "valid", }) validPvSourceNoUpdate := validVolume.DeepCopy() invalidPvSourceUpdateType := validVolume.DeepCopy() invalidPvSourceUpdateType.Spec.PersistentVolumeSource = api.PersistentVolumeSource{ FlexVolume: &api.FlexVolumeSource{ Driver: "kubernetes.io/blue", FSType: "ext4", }, } invalidPvSourceUpdateDeep := validVolume.DeepCopy() invalidPvSourceUpdateDeep.Spec.PersistentVolumeSource = api.PersistentVolumeSource{ HostPath: &api.HostPathVolumeSource{ Path: "/updated", Type: newHostPathType(string(api.HostPathDirectory)), }, } scenarios := map[string]struct { isExpectedFailure bool oldVolume         *api.PersistentVolume newVolume         *api.PersistentVolume }{ "condition-no-update": { isExpectedFailure: false, oldVolume:         validVolume, newVolume:         validPvSourceNoUpdate, }, "condition-update-source-type": { isExpectedFailure: true, oldVolume:         validVolume, newVolume:         invalidPvSourceUpdateType, }, "condition-update-source-deep": { isExpectedFailure: true, oldVolume:         validVolume, newVolume:         invalidPvSourceUpdateDeep, }, } for name, scenario := range scenarios { errs := ValidatePersistentVolumeUpdate(scenario.newVolume, scenario.oldVolume) if len(errs) == 0 && scenario.isExpectedFailure { t.Errorf("Unexpected success for scenario: %s", name) } if len(errs) > 0 && !scenario.isExpectedFailure { t.Errorf("Unexpected failure for scenario: %s - %+v", name, errs) } } } </ins> func TestValidateLocalVolumes(t *testing.T) { scenarios := map[string]struct { isExpectedFailure bool
Code change:
We should have e2e feature for resizing in GCE environment. Also add unit tests for node restrictions.
/sig storage /assign

Related discussion:
text: "persistent_volumes-vsphere.go", "pv_reclaimpolicy.go", "pvc_label_selector.go", <ins> "volume_expand.go", </ins> "volume_io.go", "volume_metrics.go", "volume_provisioning.go",
Code change:
<!-- 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: kubelet throws the exception when --cloud-provider=cloudstack is included: What you expected to happen: There shouldn't be an exception. How to reproduce it (as minimally and precisely as possible): Add the following line to /etc/systemd/system/kubelet.service.d/10- Environment="KUBELETEXTRAARGS=--cloud-provider=cloudstack --cloud-" and also configure the file. Anything else we need to know?: The condition check in the InstanceType() function in is wrong. It currently reads: but the correct code is (condition negated): Environment: Kubernetes version (use ): 1.8 Cloud provider or hardware configuration: cloudstack OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS (Xenial Xerus) Kernel (e.g. ): 4.4.0-98-generic Install tools: kubeadm Others: /sig cloudstack
I will have a look
/sig cluster-lifecycle /area cloudprovider

Related discussion:
text: // InstanceType returns the type of the specified instance. func (m *metadata) InstanceType(name types.NodeName) (string, error) { instanceType, err := m.get(metadataTypeInstanceType) <del> if err == nil { </del> <ins> if err != nil { </ins> return "", fmt.Errorf("could not get instance type: %v", err) }
Code change:
<!-- 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: The test has been failing since Nov 22nd. Looks like it is because the test restarts Kubelet and then calls getLocalNode() which checks for node readiness. Not sure why this problem only started to show up recently. 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 ): 1.9 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): COS Kernel (e.g. ): Install tools: Others:
/sig node
Hi, Just FYI, . Maybe it is helpful for you.

Related discussion:
text: Skip("Nvidia GPUs do not exist on the node. Skipping test.") } <ins> framework.WaitForAllNodesSchedulable(f.ClientSet, framework.TestContext.NodeSchedulableTimeout) </ins> By("Creating the Google Device Plugin pod for NVIDIA GPU in GKE") devicePluginPod = f.PodClient().CreateSync(framework.NVIDIADevicePlugin(f.Namespace.Name))
Code change:
<!-- 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: The test has been failing since Nov 22nd. Looks like it is because the test restarts Kubelet and then calls getLocalNode() which checks for node readiness. Not sure why this problem only started to show up recently. 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 ): 1.9 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): COS Kernel (e.g. ): Install tools: Others:
/sig node
Hi, Just FYI, . Maybe it is helpful for you.

Related discussion:
text: f.PodClient().Delete(devicePluginPod.Name, &metav1.DeleteOptions{}) By("Waiting for GPUs to become unavailable on the local node") Eventually(func() bool { <del> return framework.NumberOfNVIDIAGPUs(getLocalNode(f)) <= 0 </del> <ins> node, err := f.ClientSet.CoreV1().Nodes().Get(framework.TestContext.NodeName, metav1.GetOptions{}) framework.ExpectNoError(err) return framework.NumberOfNVIDIAGPUs(node) <= 0 </ins> }, 10*time.Minute, framework.Poll).Should(BeTrue()) By("Checking that scheduled pods can continue to run even after we delete device plugin.") count1, devIdRestart1 = getDeviceId(f, p1.Name, p1.Name, count1+1)