jiebi/CodeConvo huggingface dataset:
Change:
What would you like to be : Currently, specifying multiple aliases for a single host using results in a line for each alias in . Example: leads to an file containing something like Why is this needed: Having multiple entries for the same IP address in can break DNS resolution for some software. See for more details <!-- DO NOT EDIT BELOW THIS LINE --/kind feature
/sig node

Discussion:
var buffer bytes.Buffer buffer.WriteString("n") buffer.WriteString("# Entries added by HostAliases.n") <del> // write each IP/hostname pair as an entry into hosts file </del> <ins> // for each IP, write all aliases onto single line in hosts file </ins> for _, hostAlias := range hostAliases { <del> for _, hostname := range hostAlias.Hostnames { buffer.WriteString(fmt.Sprintf("%st%sn", hostAlias.IP, hostname)) } </del> <ins> buffer.WriteString(fmt.Sprintf("%st%sn", hostAlias.IP, strings.Join(hostAlias.Hostnames, "t"))) </ins> } return buffer.Bytes() }

123.45.67.89	some.domain # Entries added by HostAliases. <del> 123.45.67.89	foo 123.45.67.89	bar 123.45.67.89	baz </del> <ins> 123.45.67.89	foo	bar	baz </ins> `, }, {

12.34.56.78	another.domain # Entries added by HostAliases. <del> 123.45.67.89	foo 123.45.67.89	bar 123.45.67.89	baz 456.78.90.123	park 456.78.90.123	doo 456.78.90.123	boo </del> <ins> 123.45.67.89	foo	bar	baz 456.78.90.123	park	doo	boo </ins> `, }, }

203.0.113.1	podFoo.domainFoo	podFoo # Entries added by HostAliases. <del> 123.45.67.89	foo 123.45.67.89	bar 123.45.67.89	baz </del> <ins> 123.45.67.89	foo	bar	baz </ins> `, }, {

203.0.113.1	podFoo.domainFoo	podFoo # Entries added by HostAliases. <del> 123.45.67.89	foo 123.45.67.89	bar 123.45.67.89	baz 456.78.90.123	park 456.78.90.123	doo 456.78.90.123	boo </del> <ins> 123.45.67.89	foo	bar	baz 456.78.90.123	park	doo	boo </ins> `, }, }

buf.ReadFrom(rc) hostsFileContent := buf.String() <del> if !strings.Contains(hostsFileContent, "123.45.67.89tfoo") || !strings.Contains(hostsFileContent, "123.45.67.89tbar") { </del> <ins> if !strings.Contains(hostsFileContent, "123.45.67.89tfootbar") { </ins> return fmt.Errorf("expected hosts file to contain entries from HostAliases. Got:n%+v", hostsFileContent) }
Change:
<!-- 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!--What happened: Followup to In 1.15, we can merge this commit: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign
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. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale

Discussion:
"k8s.io/klog" <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> storage "k8s.io/api/storage/v1" apierrs "k8s.io/apimachinery/pkg/api/errors" meta "k8s.io/apimachinery/pkg/apis/meta/v1"

klog.V(4).Info(log("attacher.Attach finished OK with VolumeAttachment object [%s]", attachID)) <del> // TODO(71164): In 1.15, return empty devicePath return attachID, nil </del> <ins> // Don't return attachID as a devicePath. We can reconstruct the attachID using getAttachmentName() return "", nil </ins> } func (c *csiAttacher) WaitForAttach(spec *volume.Spec, _ string, pod *v1.Pod, timeout time.Duration) (string, error) {

csiAttacher := attacher.(*csiAttacher) <del> go func(spec *volume.Spec, id, nodename string, fail bool) { </del> <ins> go func(spec *volume.Spec, nodename string, fail bool) { </ins> attachID, err := csiAttacher.Attach(spec, types.NodeName(nodename)) if !fail && err != nil { t.Errorf("expecting no failure, but got err: %v", err)

if fail && err == nil { t.Errorf("expecting failure, but got no err") } <del> if attachID != id && !fail { t.Errorf("expecting attachID %v, got %v", id, attachID) </del> <ins> if attachID != "" { t.Errorf("expecting empty attachID, got %v", attachID) </ins> } <del> }(tc.spec, tc.attachID, tc.nodeName, tc.shouldFail) </del> <ins> }(tc.spec, tc.nodeName, tc.shouldFail) </ins> var status storage.VolumeAttachmentStatus if tc.injectAttacherError {

} csiAttacher := attacher.(*csiAttacher) <del> go func(spec *volume.Spec, id, nodename string, fail bool) { </del> <ins> go func(spec *volume.Spec, nodename string, fail bool) { </ins> attachID, err := csiAttacher.Attach(spec, types.NodeName(nodename)) if fail != (err != nil) { t.Errorf("expecting no failure, but got err: %v", err) } <del> if attachID != id && !fail { t.Errorf("expecting attachID %v, got %v", id, attachID) </del> <ins> if attachID != "" { t.Errorf("expecting empty attachID, got %v", attachID) </ins> } <del> }(tc.spec, tc.attachID, tc.nodeName, tc.shouldFail) </del> <ins> }(tc.spec, tc.nodeName, tc.shouldFail) </ins> var status storage.VolumeAttachmentStatus if tc.injectAttacherError {

if err != nil { t.Errorf("Attach() failed: %s", err) } <del> if expectAttach && attachID == "" { t.Errorf("Expected attachID, got nothing") } if !expectAttach && attachID != "" { </del> <ins> if attachID != "" { </ins> t.Errorf("Expected empty attachID, got %q", attachID) } }(spec, test.expectVolumeAttachment)
Change:
What happened: I noticed some surprising behavior of , which I'm not sure is intentional, but is very unexpected, in that will auto-create namespaces if it doesn't exist. This behavior does not seem to be documented anywhere. For example, if I run: against the following Role: Then the namespace gets created. This is confirmed when enabling logs in kubectl: What you expected to happen: is described in the CLI description as "preferred to 'apply' for RBAC resources so that proper rule coverage checks are done." However, this cannot be used as a drop-in replacement for apply as it requires additional privileges on the client, and the behavior is not symmetrical when the namespaces do not exist. I would expect the command to fail if the namespace does not exist. In the case of you simply get NotFound Environment: Kubernetes version (use ): /sig cli /sig auth <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
It seems that this is a intended feature
The code that backs is used on the server side as well. Hence the namespace creation was in . I made it best effort in which will land in 1.13.
Changing it to best effort doesn't actually help our specific situation because the deployment tool we are building (Argo CD), relies on running the kubectl CLI to perform deployments, and has root access. After changing the command from: to: Suddenly we were creating namespaces in some situations when we didn't expect it to be created, whereas before we could rely on an error coming back from about the missing namespace. Since Argo CD runs as root, best effort doesn't help. The simple workaround on our end is to just preface it with a : But I would suggest documenting this behavior at least.
It is intentional. +1 for documenting.
/assign opened

Discussion:
reconcileLong = templates.LongDesc(` Reconciles rules for RBAC Role, RoleBinding, ClusterRole, and ClusterRole binding objects. <del> This is preferred to 'apply' for RBAC resources so that proper rule coverage checks are done.`) </del> <ins> Missing objects are created, and the containing namespace is created for namespaced objects, if required. Existing roles are updated to include the permissions in the input objects, and remove extra permissions if --remove-extra-permissions is specified. Existing bindings are updated to include the subjects in the input objects, and remove extra subjects if --remove-extra-subjects is specified. This is preferred to 'apply' for RBAC resources so that semantically-aware merging of rules and subjects is done.`) </ins> reconcileExample = templates.Examples(` # Reconcile rbac resources from a file
Change:
Execute make test WHAT=./pkg/api/testing/ And it failed with information: /kind failing-test
/sig api-machinery
what's the urgency of fixing this? Is it a release blocker?
i don't see it as a release blocker. but the problem is in client-go, so it's important to get fixed.

Discussion:
rs := &apps.ReplicaSet{} rc := &api.ReplicationController{} <ins> extGroup := schema.GroupVersion{Group: "apps", Version: "v1"} extCodec := legacyscheme.Codecs.LegacyCodec(extGroup) </ins> <del> extGroup := testapi.Apps defaultGroup := testapi.Default </del> <ins> defaultGroup := schema.GroupVersion{Group: "", Version: "v1"} defaultCodec := legacyscheme.Codecs.LegacyCodec(defaultGroup) </ins> fuzzInternalObject(t, schema.GroupVersion{Group: "apps", Version: runtime.APIVersionInternal}, rs, rand.Int63())

} t.Logf("rs._internal.apps -> rs.v1.apps") <del> data, err := runtime.Encode(extGroup.Codec(), rs) </del> <ins> data, err := runtime.Encode(extCodec, rs) </ins> if err != nil { t.Fatalf("unexpected encoding error: %v", err) }

decoder := legacyscheme.Codecs.DecoderToVersion( legacyscheme.Codecs.UniversalDeserializer(), runtime.NewMultiGroupVersioner( <del> *defaultGroup.GroupVersion(), schema.GroupKind{Group: defaultGroup.GroupVersion().Group}, schema.GroupKind{Group: extGroup.GroupVersion().Group}, </del> <ins> defaultGroup, schema.GroupKind{Group: defaultGroup.Group}, schema.GroupKind{Group: extGroup.Group}, </ins> ), )

} t.Logf("rc._internal -> rc.v1") <del> data, err = runtime.Encode(defaultGroup.Codec(), rc) </del> <ins> data, err = runtime.Encode(defaultCodec, rc) </ins> if err != nil { t.Fatalf("unexpected encoding error: %v", err) }
Change:
<!-- 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!--What happened: From , it took around a minute for the CSI plugin to register. It would be good to understand why it took so long and if it's normal/expected. <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
is this a blocker for 1.13? do we have a baseline of how long its expected to take for the registration?
I took a look at this. Looks like the external sidecar causes the delay (see ): So, failed to connect to CSI driver, and took a minute to fail. Here are the logs from the host path CSI driver side (see ): So it looks like the tries to open a connection a split second before the CSI hostpath driver starts listening: And the takes a minute to fail/recover from that. Based on this, the issue does not seem to be due to any code in . And is not a blocker for 1.13. I will open an issue on the driver-registrar to track if this delay can be reduced.
Opened Closing this.
Good investigation! Then, should we add some codes to check if driver-registrar complete driver registration with more than 1 minute timeout? IIUC, tests may flake by trying to attach volume before driver become ready in any tests, unless we don't add this kind of logic. To achieve it, I think that we would be able to check string from driver-registrar pod by the same way to , at the end of each driver's .
Can we try the grpc options used in other spots? Looks like the current options for the connect are here: cadvisor for example has and
will do!

Discussion:
"involvedObject.namespace": f.Namespace.Name, "reason":                   "Failed", }.AsSelector().String() <del> err = framework.WaitTimeoutForPodEvent(f.ClientSet, pod.Name, f.Namespace.Name, selector, errorMsg, framework.PodEventTimeout) </del> <ins> err = framework.WaitTimeoutForPodEvent(f.ClientSet, pod.Name, f.Namespace.Name, selector, errorMsg, framework.PodStartTimeout) </ins> Expect(err).NotTo(HaveOccurred(), "while waiting for failed event to occur") }
Change:
<!-- 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!--What happened: I think these jobs do not have the flexvolume directory properly configured. 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: <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/assign

Discussion:
// On gci, root is read-only and controller-manager containerized. Assume // controller-manager has started with --flex-volume-plugin-dir equal to this // (see cluster/gce/config-test.sh) <del> gciVolumePluginDir        = "/home/kubernetes/flexvolume" gciVolumePluginDirLegacy  = "/etc/srv/kubernetes/kubelet-plugins/volume/exec" gciVolumePluginDirVersion = "1.10.0" detachTimeout             = 10 * time.Second </del> <ins> gciVolumePluginDir = "/home/kubernetes/flexvolume" detachTimeout      = 10 * time.Second </ins> ) // testFlexVolume tests that a client pod using a given flexvolume driver

func getFlexDir(c clientset.Interface, node *v1.Node, vendor, driver string) string { volumePluginDir := defaultVolumePluginDir if framework.ProviderIs("gce") { <del> if node == nil && framework.MasterOSDistroIs("gci", "ubuntu") { v, err := getMasterVersion(c) if err != nil { framework.Failf("Error getting master version: %v", err) } if v.AtLeast(versionutil.MustParseGeneric(gciVolumePluginDirVersion)) { volumePluginDir = gciVolumePluginDir } else { volumePluginDir = gciVolumePluginDirLegacy } } else if node != nil && framework.NodeOSDistroIs("gci", "ubuntu") { if getNodeVersion(node).AtLeast(versionutil.MustParseGeneric(gciVolumePluginDirVersion)) { volumePluginDir = gciVolumePluginDir } else { volumePluginDir = gciVolumePluginDirLegacy } } </del> <ins> volumePluginDir = gciVolumePluginDir </ins> } flexDir := path.Join(volumePluginDir, fmt.Sprintf("/%s~%s/", vendor, driver)) return flexDir
Change:
What happened: During investigation of nil pointer dereference panic, i've found that has an issue: don't check 1st return value of to : but could return : So, if finds plugin by name, but this plugin isn't a , it will cause a nil pointer dereference panic in What you expected to happen: should check How to reproduce it (as minimally and precisely as possible): Unfortunately, i can't reproduce it Anything else we need to know?: advised to change signature to <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
/sig storage
how often have you run in to this? can you help put together a fix?
We could fix this but IMO this should never be reproducible because this panic will only happen if function finds a plugin but the plugin is not attachable. This could never happen because we only initialize attachable volume plugins in attach/detach controller and hence will ALWAYS return error because it will not be able to find a non-attachable plugin with that name.
Yes that makes sense. We need more info from Also do you have any modification or are you running a standard k8s?
it could be argued that - we should still fix this for sake for clarity. I will do that post 1.13. /assign
I've sent a PR to fix this issue: We it in about 30 minutes during rolling update, and, unfortunately, we're unable to reproduce it. It was k8s with modified apiserver & kubelet, but there was no modifications in kube-controller-manager. Panic trace:

Discussion:
return volumetypes.GeneratedOperations{}, volumeToDetach.GenerateErrorDetailed("DetachVolume.SplitUniqueName failed", err) } attachableVolumePlugin, err = og.volumePluginMgr.FindAttachablePluginByName(pluginName) <del> if err != nil { return volumetypes.GeneratedOperations{}, volumeToDetach.GenerateErrorDetailed("DetachVolume.FindAttachablePluginBySpec failed", err) </del> <ins> if err != nil || attachableVolumePlugin == nil { return volumetypes.GeneratedOperations{}, volumeToDetach.GenerateErrorDetailed("DetachVolume.FindAttachablePluginByName failed", err) </ins> } }
Change:
<!-- 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!--What happened: I'm trying to test Eviction functionality in my program, but running into some inconsistencies around how Evictions are handled in the fake SimpleClient in the client-go testing functionality. Most notably, creates a different from , and both are missing information. issues a with set to (seems to be the only Fake that has this mismatch) on the subresource of . It is missing all the extra information in the eviction, i.e. the . issues a on the subresource of the resource. This is wrong, because aren't created, they're only posted and handled immediately. The Action is missing a Namespace. What you expected to happen: I want to be able to add my own reactor to the SimpleClient to handle this special case. I propose we change both cases to a with set to the . This will ensure it's not handled by the current SimpleClient ObjectReaction, and makes it so users can implement whatever they want themselves. I'd be happy to make a PR with these changes. How to reproduce it (as minimally and precisely as possible): Output: Environment: git revision of : <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
POST requests are create requests. It doesn't matter if the object is persisted or not.
/sig api-machinery
cc

Discussion:
) func (c *FakeEvictions) Evict(eviction *policy.Eviction) error { <del> action := core.GetActionImpl{} action.Verb = "post" </del> <ins> action := core.CreateActionImpl{} action.Verb = "create" </ins> action.Namespace = c.ns action.Resource = schema.GroupVersionResource{Group: "", Version: "", Resource: "pods"} action.Subresource = "eviction" <ins> action.Object = eviction </ins> _, err := c.Fake.Invokes(action, eviction) return err }

func (c *FakePods) Evict(eviction *policy.Eviction) error { action := core.CreateActionImpl{} action.Verb = "create" <ins> action.Namespace = c.ns </ins> action.Resource = podsResource action.Subresource = "eviction" action.Object = eviction

) func (c *FakeEvictions) Evict(eviction *policy.Eviction) error { <del> action := core.GetActionImpl{} action.Verb = "post" </del> <ins> action := core.CreateActionImpl{} action.Verb = "create" </ins> action.Namespace = c.ns action.Resource = schema.GroupVersionResource{Group: "", Version: "v1", Resource: "pods"} action.Subresource = "eviction" <del> action.Name = eviction.Name </del> <ins> action.Object = eviction </ins> _, err := c.Fake.Invokes(action, eviction) return err }
Change:
<!-- 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!--What happened: kube-controller-manager starts but listens insecurely on IPv6, even if --secure-port and --bind-address is set What you expected to happen: kube-controller-manager just listens securely when settings are provided How to reproduce it (as minimally and precisely as possible): Start a cluster on v1.12.0 and set the systemd as follows: <pre<code--bind-address=127.0.0.1  --kubeconfig=/REDACTED/controller-manager.kubeconfig  --cluster-cidr=your-pod-cidr  --cluster-name=clustername  --cluster-signing-cert-  --cluster-signing-key-  --controllers=*,bootstrapsigner,tokencleaner  --leader-elect=true  --profiling=false  --root-ca-  --service-account-private-key-  --service-cluster-ip-range=your-svc-cidr  --use-service-account-credentials=true  --secure-port=  --v=2</code</preAnything else we need to know?: --kubeconfig is deprecated but the binary does not start without it --authorization-kubeconfig is documented where? (I cannot find it in the docs, maybe my fault) the cluster bootstraps correctly and network (weave) + dns (coredns) is working scheduling of pods work csr of nodes get approved and issued Environment: Kubernetes version (use ): 1.12.0 Cloud provider or hardware configuration: bare-metal OS (e.g. from /etc/os-release): Ubuntu 18.04.01 LTS Kernel (e.g. ): 4.15.0-34-generic Install tools: self-made (Kelseys Hard-Way guide) Others: <!-- DO NOT EDIT BELOW THIS LINE --/area controller-manager /sig cluster-lifecycle
you must set to disable insecure serving. unfortunately, the help text telling you this is hidden because the flag is marked as deprecated. opened to fix this and will pick to 1.13.x / 1.12.x

Discussion:
} fs.IPVar(&s.BindAddress, "address", s.BindAddress, <del> "DEPRECATED: see --bind-address instead.") </del> <ins> "The IP address on which to serve the insecure --port (set to 0.0.0.0 for all IPv4 interfaces and :: for all IPv6 interfaces).") </ins> fs.MarkDeprecated("address", "see --bind-address instead.") <ins> fs.Lookup("address").Hidden = false </ins> <del> fs.IntVar(&s.BindPort, "port", s.BindPort, "DEPRECATED: see --secure-port instead.") </del> <ins> fs.IntVar(&s.BindPort, "port", s.BindPort, "The port on which to serve unsecured, unauthenticated access. Set to 0 to disable.") </ins> fs.MarkDeprecated("port", "see --secure-port instead.") <ins> fs.Lookup("port").Hidden = false </ins> } // ApplyTo adds DeprecatedInsecureServingOptions to the insecureserverinfo amd kube-controller manager configuration.
Change:
<!-- 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!--What happened: Test pod is not created successfully, likely due to it being scheduled in a different zone from where the PD is provisioned. <!-- DO NOT EDIT BELOW THIS LINE --/kind failing-test
/sig storage /assign /priority critical-urgent

Discussion:
f := input.f skipExecTest(input.resource.driver) <del> testScriptInPod(f, input.resource.volType, input.resource.volSource) </del> <ins> testScriptInPod(f, input.resource.volType, input.resource.volSource, input.config.NodeSelector) </ins> }) } <del> func testScriptInPod(f *framework.Framework, volumeType string, source *v1.VolumeSource) { </del> <ins> func testScriptInPod( f *framework.Framework, volumeType string, source *v1.VolumeSource, nodeSelector map[string]string) { </ins> const ( volPath = "/vol1" volName = "vol1"

}, }, RestartPolicy: v1.RestartPolicyNever, <ins> NodeSelector:  nodeSelector, </ins> }, } By(fmt.Sprintf("Creating pod %s", pod.Name))
Change:
As far as I know the busybox image doesn't contain , only so I don't understand how the PR that changed from to has passed the CI What happened: 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. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /kind bug cc
/sig network
NetworkPolicy tests are a and so don't get run by default. But I imagine at least some of the CI test environments implement NetworkPolicy (e2e-gce?) so probably we should fix that. So 2 fixes: Make the tests pass again; probably requires changing the test image from busybox to something else. I bet there are other tests in that they switched from wget to curl where they did remember to change the image (because the tests would have failed otherwise) so this should just be a matter of seeing what image they used there, and use it here too. Make at least one of the CI tests test NetworkPolicy /good-first-issue (at least the first part anyway)
/remove-good-first-issue /remove-help (after someone asked me about this, I realized that trying to run tests that don't get run by CI is kind of complicated...)

Discussion:
package network import ( <del> "k8s.io/api/core/v1" </del> <ins> v1 "k8s.io/api/core/v1" </ins> networkingv1 "k8s.io/api/networking/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/intstr"

Args: []string{ "/bin/sh", "-c", <del> fmt.Sprintf("for i in $(seq 1 5); do curl -s -m 8 %s.%s:%d && exit 0 || sleep 1; done; exit 1", </del> <ins> fmt.Sprintf("for i in $(seq 1 5); do nc -vz -w 8 %s.%s %d && exit 0 || sleep 1; done; exit 1", </ins> targetService.Name, targetService.Namespace, targetPort), }, },