jiebi/CodeConvo huggingface dataset:
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --/kind feature The field essentially has the type , but currently there is no validation for set and map semantics, i.e. unique elements / keys. Having this validation at API level removes logic to validate at the volume plugin level. edit: this check will not be in cases where this makes it difficult to add other fields and make this field optional. /sig api-machinery /sig storage
/assign
Thanks for catching this. Would you be able to implement this for this release? We want to try to go beta if we can, and we won't be able to strengthen validation once that happens.
Yes will do!

Related discussion:
text: importpath = "k8s.io/kubernetes/pkg/apis/storage/validation", deps = [ "//pkg/apis/core:go_default_library", <ins> "//pkg/apis/core/helper:go_default_library", </ins> "//pkg/apis/core/validation:go_default_library", "//pkg/apis/storage:go_default_library", "//pkg/features:go_default_library",
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --/kind feature The field essentially has the type , but currently there is no validation for set and map semantics, i.e. unique elements / keys. Having this validation at API level removes logic to validate at the volume plugin level. edit: this check will not be in cases where this makes it difficult to add other fields and make this field optional. /sig api-machinery /sig storage
/assign
Thanks for catching this. Would you be able to implement this for this release? We want to try to go beta if we can, and we won't be able to strengthen validation once that happens.
Yes will do!

Related discussion:
text: "k8s.io/apimachinery/pkg/util/validation/field" utilfeature "k8s.io/apiserver/pkg/util/feature" api "k8s.io/kubernetes/pkg/apis/core" <ins> "k8s.io/kubernetes/pkg/apis/core/helper" </ins> apivalidation "k8s.io/kubernetes/pkg/apis/core/validation" "k8s.io/kubernetes/pkg/apis/storage" "k8s.io/kubernetes/pkg/features"
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --/kind feature The field essentially has the type , but currently there is no validation for set and map semantics, i.e. unique elements / keys. Having this validation at API level removes logic to validate at the volume plugin level. edit: this check will not be in cases where this makes it difficult to add other fields and make this field optional. /sig api-machinery /sig storage
/assign
Thanks for catching this. Would you be able to implement this for this release? We want to try to go beta if we can, and we won't be able to strengthen validation once that happens.
Yes will do!

Related discussion:
text: allErrs = append(allErrs, field.Forbidden(fldPath, "field is disabled by feature-gate DynamicProvisioningScheduling")) } <ins> rawTopologies := make([]map[string]sets.String, len(topologies)) </ins> for i, term := range topologies { <del> allErrs = append(allErrs, apivalidation.ValidateTopologySelectorTerm(term, fldPath.Index(i))...) </del> <ins> idxPath := fldPath.Index(i) exprMap, termErrs := apivalidation.ValidateTopologySelectorTerm(term, fldPath.Index(i)) allErrs = append(allErrs, termErrs...) // TODO (verult) consider improving runtime for _, t := range rawTopologies { if helper.Semantic.DeepEqual(exprMap, t) { allErrs = append(allErrs, field.Duplicate(idxPath.Child("matchLabelExpressions"), "")) } } rawTopologies = append(rawTopologies, exprMap) </ins> } return allErrs
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --/kind feature The field essentially has the type , but currently there is no validation for set and map semantics, i.e. unique elements / keys. Having this validation at API level removes logic to validate at the volume plugin level. edit: this check will not be in cases where this makes it difficult to add other fields and make this field optional. /sig api-machinery /sig storage
/assign
Thanks for catching this. Would you be able to implement this for this release? We want to try to go beta if we can, and we won't be able to strengthen validation once that happens.
Yes will do!

Related discussion:
text: class:         makeClass(nil, topologyLackOfValues), shouldSucceed: false, }, <ins> "duplicate TopologySelectorRequirement values": { class:         makeClass(nil, topologyDupValues), shouldSucceed: false, }, "multiple TopologySelectorRequirement values": { class:         makeClass(nil, topologyMultiValues), shouldSucceed: true, }, "empty MatchLabelExpressions": { class:         makeClass(nil, topologyEmptyMatchLabelExpressions), shouldSucceed: false, }, "duplicate MatchLabelExpression keys": { class:         makeClass(nil, topologyDupKeys), shouldSucceed: false, }, "duplicate MatchLabelExpression keys but across separate terms": { class:         makeClass(nil, topologyMultiTerm), shouldSucceed: true, }, "duplicate AllowedTopologies terms - identical": { class:         makeClass(nil, topologyDupTermsIdentical), shouldSucceed: false, }, "two AllowedTopologies terms, with a pair of the same MatchLabelExpressions and a pair of different ones": { class:         makeClass(nil, topologyExprsOneSameOneDiff), shouldSucceed: true, }, "two AllowedTopologies terms, with a pair of the same Values and a pair of different ones": { class:         makeClass(nil, topologyValuesOneSameOneDiff), shouldSucceed: true, }, "duplicate AllowedTopologies terms - different MatchLabelExpressions order": { class:         makeClass(nil, topologyDupTermsDiffExprOrder), shouldSucceed: false, }, "duplicate AllowedTopologies terms - different TopologySelectorRequirement values order": { class:         makeClass(nil, topologyDupTermsDiffValueOrder), shouldSucceed: false, }, } // Disable VolumeScheduling so nil VolumeBindingMode doesn't fail to validate. err := utilfeature.DefaultFeatureGate.Set("VolumeScheduling=false") if err != nil { t.Fatalf("Failed to disable feature gate for VolumeScheduling: %v", err) </ins> } // TODO: remove when feature gate not required <del> err := utilfeature.DefaultFeatureGate.Set("DynamicProvisioningScheduling=true") </del> <ins> err = utilfeature.DefaultFeatureGate.Set("DynamicProvisioningScheduling=true") </ins> if err != nil { t.Fatalf("Failed to enable feature gate for DynamicProvisioningScheduling: %v", err) }
Code change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . If the matter is security related, please disclose it privately via --Is this a BUG REPORT or FEATURE REQUEST?: What happened: unit tests failed when run under What you expected to happen: unit tests pass How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: I've seen this on both docker for mac and linux, with varying uids (501 and 1000). This patch makes the package's tests pass: If this is acceptable, I will open a PR. Please let me know!
LGTM
PR:
/sig cluster-lifecycle
/assign
/assign

Related discussion:
text: readonly ENABLE_LEGACY_ABAC=false readonly ETC_MANIFESTS=${KUBE_HOME}/etc/kubernetes/manifests readonly KUBE_API_SERVER_DOCKER_TAG=v1.11.0-alpha.0.1808_3c7452dc11645d-dirty <del> readonly LOG_OWNER_USER=$(whoami) </del> <ins> readonly LOG_OWNER_USER=$(id -un) </ins> readonly LOG_OWNER_GROUP=$(id -gn) ENCRYPTION_PROVIDER_CONFIG={{.EncryptionProviderConfig}} ENCRYPTION_PROVIDER_CONFIG_PATH={{.EncryptionProviderConfigPath}}
Code change:
/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

Related discussion:
text: <ins> apiVersion: v1 kind: Service metadata: name: a spec: selector: app: test clusterIP: None ports: - port: 80 </ins>
Code change:
/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

Related discussion:
text: <ins> apiVersion: v1 kind: Service metadata: name: a spec: selector: app: test clusterIP: 10.0.0.12 ports: - port: 80 </ins>
Code change:
/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

Related discussion:
text: } patchBytes, patchObject, err = p.patchSimple(current, modified, source, namespace, name, errOut) } <del> if err != nil && errors.IsConflict(err) && p.force { </del> <ins> if err != nil && (errors.IsConflict(err) || errors.IsInvalid(err)) && p.force { </ins> patchBytes, patchObject, err = p.deleteAndCreate(current, modified, namespace, name) } return patchBytes, patchObject, err
Code change:
/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

Related discussion:
text: # cleanup kubectl delete svc prune-svc 2>&1 "${kube_flags[@]}" <ins> ## kubectl apply -f some.yml --force # Pre-condition: no service exists kube::test::get_object_assert services "{{range.items}}{{$id_field}}:{{end}}" '' # apply service a kubectl apply -f hack/testdata/service-revision1.yaml "${kube_flags[@]}" # check right service exists kube::test::get_object_assert 'services a' "{{${id_field}}}" 'a' # change immutable field and apply service a output_message=$(! kubectl apply -f hack/testdata/service-revision2.yaml 2>&1 "${kube_flags[@]}") kube::test::if_has_string "${output_message}" 'field is immutable' # apply --force to recreate resources for immutable fields kubectl apply -f hack/testdata/service-revision2.yaml --force "${kube_flags[@]}" # check immutable field exists kube::test::get_object_assert 'services a' "{{.spec.clusterIP}}" '10.0.0.12' # cleanup kubectl delete -f hack/testdata/service-revision2.yaml "${kube_flags[@]}" </ins> set +o nounset set +o errexit }
Code change:
is a library yet is is instead of release tag. Please consider vendoring by tag whenever possible. Thanks.
We vendored it that way because the commit that fixed a bug (which we needed to be fixed and vendored back in) was This was merged on June 13. The release 1.1.4 () was released on July 1. If we want to update it to 1.1.4, I believe it should be fine. Between the commit we have vendored right now and the latest release, there are only three commits: adds tests merges (?) the case-sensitive fix - I'm not really sure what this commit is doing. fixes renaming when naming strategy is set (looks fine). Also, there are also no licensing changes. opinions?
/sig api-machinery
+1 to what said, it was a fire drill and 1.11.0 release was in trouble. Though in hind sight, we should have opened a issue to track that. something better to do next time. cc
I'm indifferent to updating this. I'm okay with moving up if it doesn't break anything, or I'm fine with leaving things as is. We don't require deps to match semver. We can version out any commit in a deps tree, as we rely on our vendored copy.
It is always a good idea to match semver and it should be a default policy. Even if it doesn't matter to you, it should, because it is a best practice. Moreover downstream it matters much more as dependencies may be un-vendored in favour of tested re-usable packages.
/cc
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
Someone please take care of this or bot will eventually close this valid issue without action...
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/lifecycle rotten
/remove-lifecycle rotten PR open (thanks,
oops! sorry, I meant to remove it. thanks!
Thanks.
please do feel free to open issues/prs of this sort early in the release cycle, so we can work through things needed well before the milestones/freeze etc. we are getting some heat about updating dependencies and we kind of settled on some guidelines here: if you think that needs updating, we could definitely debate that as well :) (on a PR against that doc)
it have nothing to do with release cycle or justification for upgrade if/when dependency has been vendored incorrectly. It is basically a vendoring bug. No debate is necessary although that kind of issues usually meet some resistance and even hostility here... Bugs are filed when they are discovered, regardless of release cycle. It would be wrong to sit on the bug without reporting it in order to synchronise with release cycle.

Related discussion:
text: }, { "ImportPath": "github.com/json-iterator/go", <del> "Rev": "f2b4162afba35581b6d4a50d3b8f34e33c144682" </del> <ins> "Rev": "ab8a2e0c74be9d3be70b3184d9acc634935ded82" </ins> }, { "ImportPath": "github.com/mailru/easyjson/buffer",
Code change:
is a library yet is is instead of release tag. Please consider vendoring by tag whenever possible. Thanks.
We vendored it that way because the commit that fixed a bug (which we needed to be fixed and vendored back in) was This was merged on June 13. The release 1.1.4 () was released on July 1. If we want to update it to 1.1.4, I believe it should be fine. Between the commit we have vendored right now and the latest release, there are only three commits: adds tests merges (?) the case-sensitive fix - I'm not really sure what this commit is doing. fixes renaming when naming strategy is set (looks fine). Also, there are also no licensing changes. opinions?
/sig api-machinery
+1 to what said, it was a fire drill and 1.11.0 release was in trouble. Though in hind sight, we should have opened a issue to track that. something better to do next time. cc
I'm indifferent to updating this. I'm okay with moving up if it doesn't break anything, or I'm fine with leaving things as is. We don't require deps to match semver. We can version out any commit in a deps tree, as we rely on our vendored copy.
It is always a good idea to match semver and it should be a default policy. Even if it doesn't matter to you, it should, because it is a best practice. Moreover downstream it matters much more as dependencies may be un-vendored in favour of tested re-usable packages.
/cc
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
Someone please take care of this or bot will eventually close this valid issue without action...
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/lifecycle rotten
/remove-lifecycle rotten PR open (thanks,
oops! sorry, I meant to remove it. thanks!
Thanks.
please do feel free to open issues/prs of this sort early in the release cycle, so we can work through things needed well before the milestones/freeze etc. we are getting some heat about updating dependencies and we kind of settled on some guidelines here: if you think that needs updating, we could definitely debate that as well :) (on a PR against that doc)
it have nothing to do with release cycle or justification for upgrade if/when dependency has been vendored incorrectly. It is basically a vendoring bug. No debate is necessary although that kind of issues usually meet some resistance and even hostility here... Bugs are filed when they are discovered, regardless of release cycle. It would be wrong to sit on the bug without reporting it in order to synchronise with release cycle.

Related discussion:
text: }, { "ImportPath": "github.com/json-iterator/go", <del> "Rev": "f2b4162afba35581b6d4a50d3b8f34e33c144682" </del> <ins> "Rev": "ab8a2e0c74be9d3be70b3184d9acc634935ded82" </ins> }, { "ImportPath": "github.com/modern-go/concurrent",
Code change:
is a library yet is is instead of release tag. Please consider vendoring by tag whenever possible. Thanks.
We vendored it that way because the commit that fixed a bug (which we needed to be fixed and vendored back in) was This was merged on June 13. The release 1.1.4 () was released on July 1. If we want to update it to 1.1.4, I believe it should be fine. Between the commit we have vendored right now and the latest release, there are only three commits: adds tests merges (?) the case-sensitive fix - I'm not really sure what this commit is doing. fixes renaming when naming strategy is set (looks fine). Also, there are also no licensing changes. opinions?
/sig api-machinery
+1 to what said, it was a fire drill and 1.11.0 release was in trouble. Though in hind sight, we should have opened a issue to track that. something better to do next time. cc
I'm indifferent to updating this. I'm okay with moving up if it doesn't break anything, or I'm fine with leaving things as is. We don't require deps to match semver. We can version out any commit in a deps tree, as we rely on our vendored copy.
It is always a good idea to match semver and it should be a default policy. Even if it doesn't matter to you, it should, because it is a best practice. Moreover downstream it matters much more as dependencies may be un-vendored in favour of tested re-usable packages.
/cc
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
Someone please take care of this or bot will eventually close this valid issue without action...
Stale issues rot after 30d of inactivity. Mark the issue as fresh with . Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle rotten
/lifecycle rotten
/remove-lifecycle rotten PR open (thanks,
oops! sorry, I meant to remove it. thanks!
Thanks.
please do feel free to open issues/prs of this sort early in the release cycle, so we can work through things needed well before the milestones/freeze etc. we are getting some heat about updating dependencies and we kind of settled on some guidelines here: if you think that needs updating, we could definitely debate that as well :) (on a PR against that doc)
it have nothing to do with release cycle or justification for upgrade if/when dependency has been vendored incorrectly. It is basically a vendoring bug. No debate is necessary although that kind of issues usually meet some resistance and even hostility here... Bugs are filed when they are discovered, regardless of release cycle. It would be wrong to sit on the bug without reporting it in order to synchronise with release cycle.

Related discussion:
text: [[constraint]] name = "github.com/modern-go/reflect2" <del> version = "1.0.0" </del> <ins> version = "1.0.1" </ins>
Code change:
/kind bug What happened: Kubelet uses "iptables" instead of "ip6tables" in an ipv6-only cluster. This causes failed traffic for services (and probably a lot of other problems). For instance the chain is created in but is missing in ; When a is assigned the fails; What you expected to happen: All components should use in a ipv6-only cluster. should work in an ipv6-only cluster. How to reproduce it (as minimally and precisely as possible): Start a ipv6-only cluster Check iptables Optional; try a service type: LoadBalancer Anything else we need to know?: is hard-coded in finc in "" Environment: Kubernetes version (use ):Cloud provider or hardware configuration: kvm VMs on Ubuntu 16.04 OS (e.g. from /etc/os-release): Own BusyBox system Kernel (e.g. ):Install tools: None Others:
/sig network
/area ipv6
Thanks for reporting this problem. I'll take a look.
is a link to the code with the hard-coded ipv4 protocol.
Thanks, I will send a pr to fix this issue.
/assign
I see this issue too. Also there is some related discussion with issue .
I just pulled the latest from master, and gave a try with IPv6 cluster, but I still see the error, when using kube-proxy + IPVS: E0829 16:51:56. 1 ] Failed to execute iptables-restore: exit status 2 (ip6tables-restore v1.4.21: The protocol family of set KUBE-LOOP-BACK is IPv4, which is not applicable. Were you able to try this with kube-proxy+IPVS?
Sorry, I didn't try ipv6 cluster with ipvs proxier. Those two issue are related, but not exactly the same issue. Seems we already have conclusion in , nobody working on that?

Related discussion:
text: } httpClient := &http.Client{} parsedNodeIP := net.ParseIP(nodeIP) <ins> protocol := utilipt.ProtocolIpv4 if parsedNodeIP != nil && parsedNodeIP.To4() == nil { glog.V(0).Infof("IPv6 node IP (%s), assume IPv6 operation", nodeIP) protocol = utilipt.ProtocolIpv6 } </ins> klet := &Kubelet{ hostname:                       hostname,