jiebi/CodeConvo huggingface dataset:
Change:
"k8s.io/klog" ) <del> // NewSchedulerCommand creates a *cobra.Command object with default parameters func NewSchedulerCommand() *cobra.Command { </del> <ins> // Option configures a framework.Registry. type Option func(framework.Registry) error // NewSchedulerCommand creates a *cobra.Command object with default parameters and registryOptions func NewSchedulerCommand(registryOptions ...Option) *cobra.Command { </ins> opts, err := options.NewOptions() if err != nil { klog.Fatalf("unable to initialize command options: %v", err)

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : As the is now implementable, it will be easier to add out of tree scheduler. And we are trying to use it to implement our plugins. The issue tracks following problems: Implement interface same as Custom Scheduler Plugins (out of tree)  to support out of tree scheduler Add support for scheduler to load and register user’s out of tree scheduling plugins that could be configured by admins. We could use to implement it, however it has some drawbacks as pointed out, e.g. We need find other ways, e.g. . /sig scheduling /assign
I did some investigation. It seems that is a better choice for the second part of this issue. I am making a prototype for it. Need I send a proposal at first? /cc
Just wrote a small proposal for it
Change:
By("deleting host0Pod") framework.ExpectNoError(podClient.Delete(host0Pod.Name, api.NewDeleteOptions(0)), "Failed to delete host0Pod") } <ins> By("Test completed successfully, waiting for PD to safely detach") waitForPDDetach(disk1Name, host0Name) waitForPDDetach(disk2Name, host0Name) </ins> }) })

Discussion:
PD E2E tests have very aggressive clean up routine that does not wait for volumes to safely detached. After the test completes, the test cleanup routine unilaterally detaches the PD (instead of waiting for k8s to do it cleanly). Although this does not cause the test to fail, it results in errors in the kernel logs: We should modify these tests to wait for k8s to safely detach the disk.
Change:
package e2e import ( <ins> "io/ioutil" "net/http" </ins> "strings" "time"

Discussion:
xref: /sig node /area test
I am working on this.
Can you update this with the types of tests that you are adding? Is this similar to ?
No, this is for running the existing GPU e2e tests on GKE which are currently running on only GCE.
The referenced PRs appear to have merged, closing.
Change:
{% if grains.cloud == 'azure' %} MACHINES="{{ salt['mine.get']('roles:kubernetes-pool', 'grains.items', expr_form='grain').values()|join(',', attribute='hostnamef') }}" {% set machines = "-machines $MACHINES" %} <del> {% elif grains.cloud is defined and grains.cloud == 'rackspace' %} MACHINES="{{ salt['mine.get']('roles:kubernetes-pool', 'grains.items', expr_form='grain').values()|map(attribute='ip_interfaces.eth2')|map('first')|join(',') }}" {% set machines = "-machines $MACHINES" %} {% set minion_regexp = "" %} </del> {% endif %} <del> {% if grains.cloud == 'vsphere' %} </del> <ins> {% if grains.cloud == 'rackspace' or grains.cloud == 'vsphere' %} </ins> # Collect IPs of minions as machines list. <del> # Use a bash array to build the value we need. It doesn't appear to be # possible call functions map or zip, or use lambda's from Jinja. </del> <ins> # # Use a bash array to build the value we need. Jinja 2.7 does support a 'map' # filter that would simplify this.  However, some installations (specifically # Debian Wheezy) only install Jinja 2.6. </ins> MACHINE_IPS=() {% for addrs in salt['mine.get']('roles:kubernetes-pool', 'network.ip_addrs', expr_form='grain').values() %} MACHINE_IPS+=( {{ addrs[0] }} ) {% endfor %} {% set machines = "-machines=$(echo ${MACHINE_IPS[@]} | xargs -n1 echo | paste -sd,)" %} <ins> {% set minion_regexp = "" %} </ins> {% endif %} {% endif %}

Discussion:
The Rackspace integration broke the GCE deploy. With Debian Wheezy the jinja2 version (package python-jinja2) is jinja2 version 2.6. This doesn't have support for the filter used in . Even though we don't hit that case for GCE, jinja apparently verifies the entire file. The VMWare folks hit this too and worked around it with a funky loop. We probably need to use the same logic for rackspace. (The jinja2 version comes from the debian repository instead of pypi as installed by the salt bootstrap scripts. We might be able to grab a newer version for GCE but that seems more difficult.)
I can get to this by EOD but if someone else wants to pick it up feel free.
I'll see if the VMWare code is workable for us.
I'm trying that out now. Thanks for following up.
My only issue with this solution for Rackspace is the use of eth0. For us, eth0 is a public IP address and means communication between apiserver <-kubelet will be over the net. It's fine for the time being but I'll send an updated PR that re-focuses on eth2 for Rackspace.
I missed that! I should have looked more carefully. I'll get this one in and we can fix it up and try and share some code.
Sounds good. I'll have some other minor updates as well.
Change:
} if !initializing { restarts = 0 <ins> hasRunning := false </ins> for i := len(pod.Status.ContainerStatuses) - 1; i >= 0; i-- { container := pod.Status.ContainerStatuses[i]

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: When one pod is running and has two Containers. Container 1 exits with success and container 2 is running. gives correct info - the pod status is . However, , the pod status is . What you expected to happen: , the pod status is . How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.9.3 Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/sig api-machinery
i can not see your pod named nginx in your above code
, updated the typo.
/sig node /remove-sig api-machinery
Change:
"properties": { "strategy": { "default": "", <del> "description": "strategy specifies how custom resources are converted between versions. Allowed values are: - `None`: The converter only change the apiVersion and would not touch any other field in the custom resource. - `Webhook`: API Server will call to an external webhook to do the conversion. Additional informationn  is needed for this option. This requires spec.preserveUnknownFields to be false, and spec.conversion.webhook to be set.", </del> <ins> "description": "strategy specifies how custom resources are converted between versions. Allowed values are: - `"None"`: The converter only change the apiVersion and would not touch any other field in the custom resource. - `"Webhook"`: API Server will call to an external webhook to do the conversion. Additional informationn  is needed for this option. This requires spec.preserveUnknownFields to be false, and spec.conversion.webhook to be set.", </ins> "type": "string" }, "webhook": {

Discussion:
Currently we have inconsistency in most of the API where the field name should be used in description so the generated docs match the API fields people actually set. A linter could be for checking To avoid confusing users
/good-first-issue
/triage accepted
/assign
Hey can you provide some more information for this issue
are you still working on this?
Hey feel free to take it. I am unassigning myself
/triage needs-information /remove-good-first-issue
/sig api-machinery
Change:
} // ValidateEndpointsUpdate tests to make sure an endpoints update can be applied. <ins> // NodeName changes are allowed during update to accommodate the case where nodeIP or PodCIDR is reused. // An existing endpoint ip will have a different nodeName if this happens. </ins> func ValidateEndpointsUpdate(newEndpoints, oldEndpoints *core.Endpoints) field.ErrorList { allErrs := ValidateObjectMetaUpdate(&newEndpoints.ObjectMeta, &oldEndpoints.ObjectMeta, field.NewPath("metadata")) <del> allErrs = append(allErrs, validateEndpointSubsets(newEndpoints.Subsets, oldEndpoints.Subsets, field.NewPath("subsets"))...) </del> <ins> allErrs = append(allErrs, validateEndpointSubsets(newEndpoints.Subsets, field.NewPath("subsets"))...) </ins> allErrs = append(allErrs, ValidateEndpointsSpecificAnnotations(newEndpoints.Annotations, field.NewPath("annotations"))...) return allErrs }

Discussion:
/kind bug What happened: We have noticed that one of the node-exporters is down. It turned out that service has "old" endpoint still. After digging deeper i see following errors in controller manager Turns out controller manager can not update endpoints for node-exporter service, because of this error. In endpoint list is see right IPs for worker nodes, but wrong IP for master node (that's why we detected the problem). Context: two worker nodes were recreated with new hostnames (generated randomly), but they use same ip address one master node were recreated with new hostname and new ip I've tried to manually update hostname and got same error, seems nodeName is not updatable field. It also affects all other endpoints, we were forced to recreated all pods (so they will change IPs) to be able to fix endpoints reconciliation. What you expected to happen: controller manager successfully update endpoints after node recreated with same IP, but different hostname. How to reproduce it (as minimally and precisely as possible): 1 master, 1 worker, service that points to pods with host network. k8s API service (keep it shut down) worker node with same IP and different host name to recreate pod on worker and in controller manager should appear error above. Anything else we need to know?: Environment: Kubernetes version (use ): 1.10.1 Cloud provider or hardware configuration: baremetal OS (e.g. from /etc/os-release): CoreOS 1688.5.3 Kernel (e.g. ): 4.14.32-coreos Install tools: own tool () Others:
/sig node
what is the use case of changing node name?
/sig api-machinery
We have ephemeral immutable nodes in our clusters. So upgrade or any other operation will cause node recreation. Hostname generated automatically, but the IP address depends on the underlay hypervisor node, where node will be scheduled. So it's possible that node stays on the same hypervisor and uses same ip address.
/cc
/assign
/cc do you think it's reasonable to loose endpoints validation?
/sig network this API is owned by sig network
Change:
activeChains[svcChain] = true // Capture the clusterIP. <del> writeLine(rulesLines, </del> <ins> args := []string{ </ins> "-A", string(iptablesServicesChain), "-m", "comment", "--comment", fmt.Sprintf(""%s cluster IP"", name.String()), "-m", protocol, "-p", protocol, "-d", fmt.Sprintf("%s/32", info.clusterIP.String()), "--dport", fmt.Sprintf("%d", info.port), <del> "-j", string(svcChain)) </del> <ins> } if proxier.MasqueradeAll { writeLine(rulesLines, append(args, "-j", "MARK", "--set-xmark", fmt.Sprintf("%s/0xffffffff", iptablesMasqueradeMark))...) } writeLine(rulesLines, append(args, "-j", string(svcChain))...) </ins> // Capture externalIPs. for _, externalIP := range info.deprecatedPublicIPs {

Discussion:
Related to . As a safety mesure, it could be very useful to actually include a flag to proxy to MASQUERADE everything (acting very close to a userspace proxy). I think it's not very hard to do and a very good way to diagnose or even fallback in case of problem (I'm thinking about vxlan cases). Something like "--snat-clients" or "--snat-pods" could be appropriate.
/cc
Looking at the current code: It looks like we SNAT almost everything already now? Would adding a set-mark rule (behind the flag of course) at line 548 be sufficient? Deprecated Public IPs, Loadbalancer IPs, and NodePorts all appear to be marked for SNAT already (also endpoint loopback traffic).
I think that is the flag, yeah. , Benjamin Elder wrote:
Ok, I'll push out a PR for that in a moment. I should be able to take care of that and the cleanup flag (PR out but needs some more work) today. On Aug 20, 2015 2:12 PM, "Tim Hockin" wrote:
Change:
reason:  "FailedMount", pattern: make([]string, 2)} ep.pattern = append(ep.pattern, "NodeSelectorTerm") <del> ep.pattern = append(ep.pattern, "Storage node affinity check failed") </del> <ins> ep.pattern = append(ep.pattern, "MountVolume.NodeAffinity check failed") </ins> It("should not be able to mount due to different NodeName", func() { testPodWithNodeName(config, testVolType, ep, config.nodes[1].Name, makeLocalPodWithNodeName, testMode)

Discussion:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: What happened: Failing since 12/17 https://k8s- /assign
Looks like the error message changed.
I managed to get e2e test running on my multi node cluster, and it looks ok to me. All tests are passing, here is the log I see: [sig-storage] PersistentVolumes-local [Feature:LocalPersistentVolumes] [Serial] [Volume type: tmpfs] when pod's node is different from PV's NodeName should not be able to mount due to different NodeName [BeforeEach] [sig-storage] PersistentVolumes-local [Feature:LocalPersistentVolumes] [Serial] STEP: Creating a kubernetes client Dec 29 13:55:55.865: INFO: kubeConfig: STEP: Building a namespace api object STEP: Waiting for a default service account to be provisioned in namespace [BeforeEach] [sig-storage] PersistentVolumes-local [Feature:LocalPersistentVolumes] [Serial] [BeforeEach] [Volume type: tmpfs] [BeforeEach] when pod's node is different from PV's NodeName [It] should not be able to mount due to different NodeName ResourceVersion: FieldPath:} Reason:FailedMount Message:Storage node affinity check failed for volume "local-pv8v7k7" : NodeSelectorTerm [{ Operator:In Values:[cluster-02-]}] does not match node labels Source:{Component:kubelet Host:cluster-02-} Maybe the issue you see is gce specific? Could you please add this for loop after this line? for _,e := range events.Items { fmt.Printf("<<<<%+vn", e) } And send me logs I would like to compare with logs I see on my cluster.
are you working off of the latest k8s code? There was a change that went in mid-Dec that changed a bunch of volume error messages
yep on the latest master
Change:
// Watch implements storage.Interface. func (c *Cacher) Watch(ctx context.Context, key string, opts storage.ListOptions) (watch.Interface, error) { pred := opts.Predicate <ins> // If the resourceVersion is unset, ensure that the rv // from which the watch is being served, is the latest // one. "latest" is ensured by serving the watch from // the underlying storage. if opts.ResourceVersion == "" { return c.storage.Watch(ctx, key, opts) } </ins> watchRV, err := c.versioner.ParseResourceVersion(opts.ResourceVersion) if err != nil { return nil, err

Discussion:
As Jordan pointed out in: watchcache treats RV=0 and RV="" the same way, even though it's not what we document: This should be fixed. /kind bug /sig api-machinery /priority important-soon
/assign
/triage accepted
Change:
// inter-pod affinity for pods of different rollouts and anti-affinity // for pods of the same rollout, so it will need to be updated when // performing a rollout. <del> setAffinity(d) </del> <ins> setAffinities(d, false) </ins> d.Spec.Strategy.RollingUpdate = &appsv1.RollingUpdateDeployment{ MaxSurge:       intOrStrP(1), MaxUnavailable: intOrStrP(0),

Discussion:
<!-- Please only use this template for submitting reports about failing tests in Kubernetes CI jobs --Which jobs are failing: gce-master-scale-correctness Which test(s) are failing: [sig-network] Loadbalancing: L7 [Slow] Nginx should conform to Ingress spec [sig-network] Services should handle load balancer cleanup finalizer for service [sig-network] Services should only allow access from service loadbalancer source ranges Since when has it been failing: 2019-10-19 Testgrid link: https://k8s- Reason for failure: and Anything else we need to know: /sig scalability /sig network could you triage?
It seems that new test was at that point: [sig-apps] Deployment should not disrupt a cloud load-balancer's connectivity during rollout My personal guess is that we started doing too much load-balancer-related stuff at the same time.
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
I think this is my fault. should fix it. Is there some way to those tests to run against a PR? /remove-triage unresolved
At the moment the fastest way would be to merge your fix and wait for the next run tomorrow.
Reopening just to keep this tracking - will close once we have green run.
the fix helped for a two tests, but one of them is still failing: https://k8s-
I disagree - there are couple loadbalancing-related tests that are flaking with high flakiness ration - I think this PR didn't change anything. So my feeling is that is may still be something like:
Still, the conclusion is that unfortunately more work in needed to put us back in a good shape.
I looked a bit into it and the conclusions are: "Services should handle load balancer cleanup finalizer for service [Slow]" test is consistently failing in small clusters too with: IIUC, the reason is that if we downgrade load-balancer service to non-loadbalaced one, it takes some time to remove the ingress from Status, but it is failing immediately due to this: - can you please take a look? the apps test (and I think couple more) are failing due to incorrect timeouts - I will send out a fix for it soon
Actually, this one will be still failing as of now - the reason for it is described here:
Change:
<ins> apiVersion: v1 kind: Service metadata: name: a spec: selector: app: test clusterIP: None ports: - port: 80 </ins>

Discussion:
/kind bug What happened: From I expected kubectl apply to support deleting a resource and recreating it, if changes cannot be applied. kubectl replace works: What you expected to happen: How to reproduce it (as minimally and precisely as possible): ` Change clusterIP to any IP address. Anything else we need to know?: Environment: Kubernetes version (use ): client v1.11.0, cluster v1.11.1 Cloud provider or hardware configuration: QEMU/KVM OS (e.g. from /etc/os-release): Cluster CentOS Linux release 7.5.1804 (Core), client macOS Kernel (e.g. ): 3.10.0-862.6.3.el7.x86_64 Install tools: kubeadm Others:
/cc
/assign
Change:
numErrs: 0, }, { <del> name: "invalid port in use", </del> <ins> name: "external port in use", </ins> svc: api.Service{ ObjectMeta: api.ObjectMeta{Name: "abc123", Namespace: api.NamespaceDefault}, Spec: api.ServiceSpec{

Discussion:
From a user: I'm trying to expose multiple services on the same port in a GKE Kubernetes 0.8.1 cluster. My question is similar to this SO post but it is not solved by 0.5.x+ I've deployed a service (hellogo) with an external load balancer which works correctly. Deploying another service (pynote) which is extremely similar fails { "apiVersion": "v1beta1", "kind": "Service", "id": "pynote-service", "selector": { "name": "pynote" }, "containerPort": 8080, "protocol": "TCP", "port": 80, "createExternalLoadBalancer": true } gcloud preview container services --cluster athena --zone $ZONE create --config-file pynote- ERROR: F0124 19:42:27. ] service "pynote-service" is invalid: service "pynote-service" cannot be updated: port: 80 is already in use If I delete the other service and start pynote first, the service and load balancer are setup correctly, but the other service cannot be deployed with the same error. I believe the current proxying design is that service routing occurs via proxies on every node which are part of the target pool. Every service gets its own IP. Putting up two external services on port 80 on GKE should allocate two load balancers, each with a fixed IP address. This design does not preclude exposing services on the same port as each service is accessed through a separate external IP. Furthermore, Kubernetes itself runs a service (kubernetes-ro) on port 80 which coexists with my first service nicely. At the very least, the message is misleading. There is no requirement that the services deployed on a cluster use unique ports. In the source, it becomes apparent that its the external load balancer creation that causes the command to fail. Indeed, I can deploy pynote with createExternalLoadBalancer to false.

Happily coexisting: hellogo-service <nonename=hellogo 10.143.249.126 80 pynote-service <nonename=pynote 10.143.254.255 80 I've tried to define my own target pool called pynote-service, selecting all the cluster node instances and created a network load balancer with a forwarding rule on port 80 to the target pool. Despite the fact that it corresponds to the one created automatically for hellogo-service, it does not seem to resolve to the running pynote pod. This feels like I'm missing something small, but I've been blocked on this. Perhaps I'll only ever run one lonely web service...
I believe there's a bug in the service validation logic, left over from when you actually might have a conflict...
Change:
"net/http/httptest" "net/url" "reflect" <del> "strings" </del> <ins> "regexp" </ins> "testing" "k8s.io/apimachinery/pkg/util/diff"

Discussion:
unit tests since switching to go1.18 No response No response Weirdly, the test is passing in CI () and failing locally /sig api-machinery auth testing
seems related Jordan, are you using mac ?
yes, though the description in that issue seems to be not just test-only changes to the errors received from invalid certificates (which is what I saw), but actual certificates that previously validated
marking as release blocker until it is determined that go1.18 is not rejecting valid certificates
this needs an assignee and a reproducer we can file as an upstream issue for golang to ask why previously valid certificates now fail validation
marking critical until root-caused and determined whether this is prod-impacting, since (in my opinion) this should block rc0
On linux it works fine: on MacOS, it fails:
Looks like the change in golang that broke the scenario was:
if the only impact is a different failure message on an already-invalid certificate, I don't care and we can update the test to accept either message is what makes me wonder what previously-accepted certificates are now failing
reproducer test case here. this one has no issues under go 1.17 and fails with go 1.18 (stripped down version of ) : :
the new error message is minted here: i suspect it is related to: So essentially this seems to be something that may hit in our case. right?
yeah, if this is scoped to just darwin clients, and only ones using system roots, that greatly narrows the impact
Asked on gophers slack -
xref:
opened to tolerate the additional errors discussion in indicates the tightened validation is very bounded (darwin-only, so clients-only, system roots only), and certificates issued by public CAs would be expected to pass this validation dropping release-blocking label and priority to important-soon, but should still make it into 1.24 to make unit tests pass locally