jiebi/CodeConvo huggingface dataset:
Code change:
cc:
It was broken by . I'll send a fix in a sec.
Sorry & thanks for fixing.

Related discussion:
text: create-node-instance-template $template_name } <del> function create-nodes() { local template_name="${NODE_INSTANCE_PREFIX}-template" </del> <ins> # Assumes: # - MAX_INSTANCES_PER_MIG # - NUM_NODES # exports: # - NUM_MIGS function set_num_migs() { </ins> local defaulted_max_instances_per_mig=${MAX_INSTANCES_PER_MIG:-500} if [[ ${defaulted_max_instances_per_mig} -le "0" ]]; then echo "MAX_INSTANCES_PER_MIG cannot be negative. Assuming default 500" defaulted_max_instances_per_mig=500 fi <del> local num_migs=$(((${NUM_NODES} + ${defaulted_max_instances_per_mig} - 1) / ${defaulted_max_instances_per_mig})) local instances_per_mig=$(((${NUM_NODES} + ${num_migs} - 1) / ${num_migs})) local last_mig_size=$((${NUM_NODES} - (${num_migs} - 1) * ${instances_per_mig})) </del> <ins> export NUM_MIGS=$(((${NUM_NODES} + ${defaulted_max_instances_per_mig} - 1) / ${defaulted_max_instances_per_mig})) } # Assumes: # - NUM_MIGS # - NODE_INSTANCE_PREFIX # - NUM_NODES # - PROJECT # - ZONE function create-nodes() { local template_name="${NODE_INSTANCE_PREFIX}-template" local instances_per_mig=$(((${NUM_NODES} + ${NUM_MIGS} - 1) / ${NUM_MIGS})) local last_mig_size=$((${NUM_NODES} - (${NUM_MIGS} - 1) * ${instances_per_mig})) </ins> #TODO: parallelize this loop to speed up the process <del> for i in $(seq $((${num_migs} - 1))); do </del> <ins> for i in $(seq $((${NUM_MIGS} - 1))); do </ins> gcloud compute instance-groups managed  create "${NODE_INSTANCE_PREFIX}-group-$i"  --project "${PROJECT}"
Code change:
My reading is that the first attempt to create e2e-gce-minion-template looks like it failed with "Backend error", but it seems that the template was actually created, so subsequent attempts failed because it already existed.
From kubernetes-e2e-gce/ claims to have deleted: But it apparently wasn't. Looks like we need to improve handling of this: cc There were previous attempts to make instance template more robust, such as in .
And, after this failed, the subsequent test run failed the leaked-resource check.
Ha, an old TODO strikes again. :)
It's actually pretty disturbing that claimed when it wasn't. There may be an internal bug here, since the name should be available for use if delete occurred, in theory.
Do you think someone from your team could take a look at this one?
It sounds like the hypothesis is that the delete failed in , but gcloud reported 'deleted'. But the failure message from the first create operation in is one I haven't seen before: reads to me as "something went wrong, I don't know the state of the world". It looks like the template was created OK (ish), but we try recreating with the same name which then fails (as expected). Is there evidence that the delete actually failed in ? My inclination would be that we should have a retry loop that looks more like: (That is go-bash; neither go nor bash. Just be grateful there's no salt in there!)
- can you take a look at this one this morning?
I was out this morning but I'll see if I can look into it later this afternoon.
ping
This just happened again: I'm going too apply P0 label to the PR that is supposed to fix it.
Ah, this is the same as . We created an internal bug for this too, ref .

Related discussion:
text: echo -e "${color_yellow}Attempt ${attempt} failed to create instance template $template_name. Retrying.${color_norm}" >&2 attempt=$(($attempt+1)) sleep $(($attempt * 5)) <ins> # In case the previous attempt failed with something like a # Backend Error and left the entry laying around, delete it # before we try again. gcloud compute instance-templates delete "$template_name" --project "${PROJECT}" &>/dev/null || true </ins> else break fi
Code change:
See example log below. I'm pretty sure the SG in question was from an ELB, but we should just auto-retry anyway.

Related discussion:
text: fi } <ins> # Deletes a security group # usage: delete_security_group <sgid> function delete_security_group { local -r sg_id=${1} echo "Deleting security group: ${sg_id}" # We retry in case there's a dependent resource - typically an ELB n=0 until [ $n -ge 20 ]; do $AWS_CMD delete-security-group --group-id ${sg_id} > $LOG && return n=$[$n+1] sleep 3 done echo "Unable to delete security group: ${sg_id}" exit 1 } </ins> function ssh-key-setup { if [[ ! -f "$AWS_SSH_KEY" ]]; then ssh-keygen -f "$AWS_SSH_KEY" -N ''
Code change:
See example log below. I'm pretty sure the SG in question was from an ELB, but we should just auto-retry anyway.

Related discussion:
text: continue fi <del> echo "Deleting security group: ${sg_id}" $AWS_CMD delete-security-group --group-id ${sg_id} > $LOG </del> <ins> delete_security_group ${sg_id} </ins> done subnet_ids=$($AWS_CMD describe-subnets
Code change:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.

Related discussion:
text: }, "targetPort": { "type": "string", <del> "description": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of Port is used (an identity map). Defaults to the service port. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service" </del> <ins> "description": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of the 'port' field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the 'port' field. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service" </ins> }, "nodePort": { "type": "integer",
Code change:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.

Related discussion:
text: </tr> <tr> <td class="tableblock halign-left valign-top"><p class="tableblock">targetPort</p></td> <del> <td class="tableblock halign-left valign-top"><p class="tableblock">Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod&#8217;s container ports. If this is not specified, the value of Port is used (an identity map). Defaults to the service port. More info: <a href="http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service">http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service</a></p></td> </del> <ins> <td class="tableblock halign-left valign-top"><p class="tableblock">Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod&#8217;s container ports. If this is not specified, the value of the <em>port</em> field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the <em>port</em> field. More info: <a href="http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service">http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service</a></p></td> </ins> <td class="tableblock halign-left valign-top"><p class="tableblock">false</p></td> <td class="tableblock halign-left valign-top"><p class="tableblock">string</p></td> <td class="tableblock halign-left valign-top"></td>
Code change:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.

Related discussion:
text: // Optional: The target port on pods selected by this service.  If this // is a string, it will be looked up as a named port in the target <del> // Pod's container ports.  If this is not specified, the default value // is the sames as the Port field (an identity map). </del> <ins> // Pod's container ports.  If this is not specified, the value // of the 'port' field is used (an identity map). // This field is ignored for services with clusterIP=None, and should be // omitted or set equal to the 'port' field. </ins> TargetPort intstr.IntOrString `json:"targetPort"` // The port on each node on which this service is exposed.
Code change:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.

Related discussion:
text: // Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. // If this is a string, it will be looked up as a named port in the // target Pod's container ports. If this is not specified, the value <del> // of Port is used (an identity map). // Defaults to the service port. </del> <ins> // of the 'port' field is used (an identity map). // This field is ignored for services with clusterIP=None, and should be // omitted or set equal to the 'port' field. </ins> // More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service TargetPort intstr.IntOrString `json:"targetPort,omitempty"`
Code change:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.

Related discussion:
text: "name":       "The name of this port within the service. This must be a DNS_LABEL. All ports within a ServiceSpec must have unique names. This maps to the 'Name' field in EndpointPort objects. Optional if only one ServicePort is defined on this service.", "protocol":   "The IP protocol for this port. Supports "TCP" and "UDP". Default is TCP.", "port":       "The port that will be exposed by this service.", <del> "targetPort": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of Port is used (an identity map). Defaults to the service port. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service", </del> <ins> "targetPort": "Number or name of the port to access on the pods targeted by the service. Number must be in the range 1 to 65535. Name must be an IANA_SVC_NAME. If this is a string, it will be looked up as a named port in the target Pod's container ports. If this is not specified, the value of the 'port' field is used (an identity map). This field is ignored for services with clusterIP=None, and should be omitted or set equal to the 'port' field. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#defining-a-service", </ins> "nodePort":   "The port on each node on which this service is exposed when type=NodePort or LoadBalancer. Usually assigned by the system. If specified, it will be allocated to the service if unused or else creation of the service will fail. Default is to auto-allocate a port if the ServiceType of this Service requires one. More info: http://releases.k8s.io/HEAD/docs/user-guide/services.md#type--nodeport", }
Code change:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.

Related discussion:
text: allErrs = append(allErrs, field.Invalid(fldPath.Child("targetPort"), sp.TargetPort, PortNameErrorMsg)) } <del> if isHeadlessService { if sp.TargetPort.Type == intstr.String || (sp.TargetPort.Type == intstr.Int && sp.Port != sp.TargetPort.IntValue()) { allErrs = append(allErrs, field.Invalid(fldPath.Child("port"), sp.Port, "must be equal to targetPort when clusterIP = None")) } } </del> <ins> // in the v1 API, targetPorts on headless services were tolerated. // once we have version-specific validation, we can reject this on newer API versions, but until then, we have to tolerate it for compatibility. // // if isHeadlessService { // 	if sp.TargetPort.Type == intstr.String || (sp.TargetPort.Type == intstr.Int && sp.Port != sp.TargetPort.IntValue()) { // 		allErrs = append(allErrs, field.Invalid(fldPath.Child("targetPort"), sp.TargetPort, "must be equal to the value of 'port' when clusterIP = None")) // 	} // } </ins> return allErrs }
Code change:
In 1.0 and 1.1, headless services that specified a mismatched port/targetPort were tolerated (the targetPort was ignored). tightened validation to reject these services. That causes problems when upgrading from currently-working clusters.
2 candidate to avoid breaking backwards compatibility
oh hell. Yeah. I don't think this is worth a breaking change. We should either roll that back ASAP or change it to nuke any user-provided value and replace it with the value. I think the latter is potentially dangerous and also not worth the risk, so I think we should rollback and just update the docs for targetPort. objections?
Who has time to do this? It doesn't look like an auto-rollback is doable.
Already opened a PR in
Yes, I agree this isn't worth a breaking change, But could we give an warning log that targetPort isn't equal to port and would be ignored?
There's no facility in validation for warning. I don't think spamming the server log in response to API requests is that helpful here
Yes, that sounds reasonable. I just think that targetPort was ignored is a little unfriendly to user.

Related discussion:
text: numErrs: 0, }, { <del> name: "invalid port headless", </del> <ins> name: "invalid port headless 1", </ins> tweakSvc: func(s *api.Service) { s.Spec.Ports[0].Port = 11722 s.Spec.Ports[0].TargetPort = intstr.FromInt(11721) s.Spec.ClusterIP = api.ClusterIPNone }, <del> numErrs: 1, </del> <ins> // in the v1 API, targetPorts on headless services were tolerated. // once we have version-specific validation, we can reject this on newer API versions, but until then, we have to tolerate it for compatibility. // numErrs: 1, numErrs: 0, </ins> }, { <del> name: "invalid port headless", </del> <ins> name: "invalid port headless 2", </ins> tweakSvc: func(s *api.Service) { s.Spec.Ports[0].Port = 11722 s.Spec.Ports[0].TargetPort = intstr.FromString("target") s.Spec.ClusterIP = api.ClusterIPNone }, <del> numErrs: 1, </del> <ins> // in the v1 API, targetPorts on headless services were tolerated. // once we have version-specific validation, we can reject this on newer API versions, but until then, we have to tolerate it for compatibility. // numErrs: 1, numErrs: 0, </ins> }, { name: "invalid publicIPs localhost",
Code change:
This might be fixed, haven't reproduced on latest upstream source. But in any case, I thought I'd create the issue. bug = i assume any failure in e2es shouldnt be b/c of a panic. ... I noticed a failure on Openshift today, which I think alludes to a possible issue in replica sets.
cc
cc
Yup, looks like a bug, and it looks like it's still there. The isn't checked, so can be nil, which will cause the panic on L102. cc
i think the iterators should be declarative here i.e. ? thats a better fix .... (update : nvm, i think its fine as is, just add a nil check: Because, the declarative won't work for the entire test, since the function for checking pod name responses requires a full )
Cc
Thanks, Jay. Even with this change, the test would have failed, so we should still debug the cause.
It seems we don't check err here: if return an error, will be nil.
Yup.... that is fixed in the PR, right?

Related discussion:
text: label := labels.SelectorFromSet(labels.Set(map[string]string{"name": name})) pods, err := podsCreated(f.Client, f.Namespace.Name, name, replicas) <ins> Expect(err).NotTo(HaveOccurred()) </ins> By("Ensuring each pod is running")
Code change:
Getting this error... looks like we are quoting : Working on a hotfix...
Linking to
Fix is

Related discussion:
text: # use JENKINS_PUBLISHED_VERSION, default to 'ci/latest', since that's # usually what we're testing. check_dirty_workspace <del> fetch_published_version_tars "${JENKINS_PUBLISHED_VERSION:-'ci/latest'}" </del> <ins> fetch_published_version_tars "${JENKINS_PUBLISHED_VERSION:-ci/latest}" </ins> fi # Copy GCE keys so we don't keep cycling them.
Code change:
From Slack, we got a report that "my service controller is trying to delete a ELB ( im running k8s in ews ) thats is not there, and for that reason its failing over and over again with the message " It turns out the user had deleted the ELB manually. We should tolerate this better.
I think this was actually caused by a failure to tag the cluster, which triggered another bug where we can't pass an empty filters list to the AWS API

Related discussion:
text: // Return all the security groups that are tagged as being part of our cluster func (s *AWSCloud) getTaggedSecurityGroups() (map[string]*ec2.SecurityGroup, error) { request := &ec2.DescribeSecurityGroupsInput{} <del> filters := []*ec2.Filter{} request.Filters = s.addFilters(filters) </del> <ins> request.Filters = s.addFilters(nil) </ins> groups, err := s.ec2.DescribeSecurityGroups(request) if err != nil { return nil, fmt.Errorf("error querying security groups: %v", err)
Code change:
From Slack, we got a report that "my service controller is trying to delete a ELB ( im running k8s in ews ) thats is not there, and for that reason its failing over and over again with the message " It turns out the user had deleted the ELB manually. We should tolerate this better.
I think this was actually caused by a failure to tag the cluster, which triggered another bug where we can't pass an empty filters list to the AWS API

Related discussion:
text: describeRequest.Filters = s.addFilters(filters) actualGroups, err := s.ec2.DescribeSecurityGroups(describeRequest) if err != nil { <del> return fmt.Errorf("error querying security groups: %v", err) </del> <ins> return fmt.Errorf("error querying security groups for ELB: %v", err) </ins> } taggedSecurityGroups, err := s.getTaggedSecurityGroups()