jiebi/CodeConvo huggingface dataset:
Change:
if err != nil { return nil, err } <ins> readOnly, err := getReadOnlyFromSpec(spec) if err != nil { return nil, err } </ins> // before it is used in any paths such as socket etc addr := fmt.Sprintf(csiAddrTemplate, pvSource.Driver)

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The field passed to is never set. In where is a object that is initialized in the method in Notice the field is never set. What you expected to happen: The field should be set to How to reproduce it (as minimally and precisely as possible): Create a CSI volume and set to true. Check the value of in the CSI call. It should be true, but is false. CC 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:
I think is only used for mounting pod volume path to container, here(for ), we can set to , just like other volume plugins. I can help to fix this.
What about the case when a user wants to mount a volume for one of containers in a POD as read only, but the actual volume has ReadOnly False? I would like to suggest an alternative solution which passes the value of ReadOnly attribute, taken from POD's spec.
Thank you and for jumping on this! I feel like the other volume plugins have the wrong behavior here. The purpose of the call is to mount the volume. Therefore, the should receive the pod volume mount readonly field. That said, as mentioned , I think the fact that " is used for mounting pod volume path to container" might be hiding a bug: that is never set correctly. I haven't had a chance to validate this but my reading of the code suggests that the is never set. But because the container mount uses , even though the plugin did not get the correct readonly value, the mount ends up getting mounted with the correctly readonly value. Thoughts?
[MILESTONENOTIFIER] Milestone Issue: Up-to-date for process Note: This issue is marked as , and must be updated every 1 day during code freeze. Example update: <details open<summaryIssue Labels</summary- : Issue will be escalated to these SIGs if needed. : Never automatically move issue out of a release milestone; continually escalate to contributor and SIG through all available channels. : Fixes a bug discovered during the current release.

</details<details<summaryHelp</summary<ul<li<a href=""Additional instructions</a</li<li<a href=""Commands for setting labels</a</li</ul</details
We discussed the proposed fixes in the Kubernetes CSI implementation meeting today (see ). We decided it would be better for CSI to be consistent with the other plugins (and still broken), and have CSI fixed, along with all the other plugins, whenever we fix the issue (likely post-1.10). Therefore, I will accept fix and we will close Then we can remove the 1.10 tag from this issue and track it independent of the 1.10 release.
Spoke with offline. Details here: Based on that conversation, I don't think there is anything else we need to do here.
Change:
} // WarningsOnUpdate returns warnings for the given update. <del> func (customResourceStrategy) WarningsOnUpdate(ctx context.Context, obj, old runtime.Object) []string { return nil </del> <ins> func (a customResourceStrategy) WarningsOnUpdate(ctx context.Context, obj, old runtime.Object) []string { return generateWarningsFromObj(obj, old) </ins> } // GetAttrs returns labels and fields of a given object for filtering purposes.

Discussion:
A client is allowed to add custom finalizers to Custom Resources with a finalizer name that's not fully qualified (e.g. or ). However they're prevented from doing the same on builtin resource types, returning the following error: Invalid value: "": name is neither a standard finalizer name nor is it fully qualified Per , custom finalizer names are expected to be in format "consist of a domain name, a forward slash and the name of the finalizer" (e.g. ). Therefore, I expected the enforcement to be the same for CRs and builtin types. a custom resource on the cluster it to add the edit does not fail the same on a builtin resource (e.g. Namespace or Pod), observe it fails No response Reproducible at least starting from 1.21 and still on latest versions. <details</details<detailsN/A kind cluster </details<detailsN/A - kind cluster accessed via macOS </details<details</details<details</details<details</details
/area api /cc /sig api-machinery
/assign /triage accepted
There is no validation of finalizer in and . Please unassign me if you guys have started to work on it. /assign
it is called from here on custom resources:
lacks validation for finalizer name. I have raised a pr for this. PTAL.
Change:
}, expectedElements: []string{"test", "State", "Waiting", "Ready", "True", "Restart Count", "7", "Image", "image"}, }, <ins> //env { container: api.Container{Name: "test", Image: "image", Env: []api.EnvVar{{Name: "envname", Value: "xyz"}}}, status: api.ContainerStatus{ Name:         "test", Ready:        true, RestartCount: 7, }, expectedElements: []string{"test", "State", "Waiting", "Ready", "True", "Restart Count", "7", "Image", "image", "envname", "xyz"}, }, </ins> // Using limits. { container: api.Container{

Discussion:
A "kubectl describe" on a pod ID give a lot of informations about that pod but don't you think it should also print the pod's env var ?
Change:
} ctx.paramGVK = paramsGVK ctx.paramDeclType = paramsDeclType <ins> ctx.variables = policy.Spec.Variables </ins> return ctx } <ins> func (c *TypeChecker) compiler(ctx *TypeCheckingContext, typeOverwrite typeOverwrite) (*plugincel.CompositedCompiler, error) { envSet, err := buildEnvSet( /* hasParams */ ctx.paramDeclType != nil, /* hasAuthorizer */ true, typeOverwrite) if err != nil { return nil, err } env, err := plugincel.NewCompositionEnv(plugincel.VariablesTypeName, envSet) if err != nil { return nil, err } compiler := &plugincel.CompositedCompiler{ Compiler:       &typeCheckingCompiler{typeOverwrite: typeOverwrite, compositionEnv: env}, CompositionEnv: env, } return compiler, nil } </ins> // CheckExpression type checks a single expression, given the context func (c *TypeChecker) CheckExpression(ctx *TypeCheckingContext, expression string) TypeCheckingResults { var results TypeCheckingResults for i, gvk := range ctx.gvks { declType := ctx.declTypes[i] <del> // TODO(jiahuif) hasAuthorizer always true for now, will change after expending type checking to all fields. issues, err := c.checkExpression(expression, ctx.paramDeclType != nil, true, typeOverwrite{ </del> <ins> compiler, err := c.compiler(ctx, typeOverwrite{ </ins> object: declType, params: ctx.paramDeclType, }) <del> if issues != nil || err != nil { results = append(results, &TypeCheckingResult{Issues: issues, Err: err, GVK: gvk}) </del> <ins> if err != nil { utilruntime.HandleError(err) continue } options := plugincel.OptionalVariableDeclarations{ HasParams:     ctx.paramDeclType != nil, HasAuthorizer: true, } compiler.CompileAndStoreVariables(convertv1beta1Variables(ctx.variables), options, environment.StoredExpressions) result := compiler.CompileCELExpression(celExpression(expression), options, environment.StoredExpressions) if err := result.Error; err != nil { typeCheckingResult := &TypeCheckingResult{GVK: gvk} if err.Type == apiservercel.ErrorTypeInvalid { typeCheckingResult.Issues = err } else { typeCheckingResult.Err = err } results = append(results, typeCheckingResult) </ins> } } return results } <ins> type celExpression string func (c celExpression) GetExpression() string { return string(c) } func (c celExpression) ReturnTypes() []*cel.Type { return []*cel.Type{cel.AnyType} } </ins> func generateUniqueTypeName(kind string) string { return fmt.Sprintf("%s%d", kind, time.Now().Nanosecond()) }

Discussion:
When I load a policy definition like this The object is updated with the following status While this error is reported, the policy does seem to be fully functioning This is similar to the documented examples No error reported on a valid spec Create a a policy that uses variables Observe the status of the newly created policy No response <details</details<detailsn/a </details<details</details<detailskind </details<details</details<details</details
/sig api-machinery
/assign Oops. Good find. Thank you. /triage accepted
Change:
<ins> # SaltStack configuration This is the root of the SaltStack configuration for Kubernetes. A high level overview for the Kubernetes SaltStack configuration can be found [in the docs tree.](../../docs/salt.md) This SaltStack configuration currently applies to default configurations for Debian-on-GCE, Fedora-on-Vagrant, Ubuntu-on-AWS and Ubuntu-on-Azure. (That doesn't mean it can't be made to apply to an arbitrary configuration, but those are only the in-tree OS/IaaS combinations supported today.) As you peruse the configuration, these are shorthanded as `gce`, `vagrant`, `aws`, `azure` in `grains.cloud`; the documentation in this tree uses this same shorthand for convenience. See more: * [pillar](pillar/) * [reactor](reactor/) * [salt](salt/) </ins>

Discussion:
We need to document all the configuration derived by Salt. Ideally this would be a markdown doc that we kept as live documentation within the project. The main reasons to bother: It's hard right now for anyone approaching the directory to get a big picture view of what's is going on, especially across providers. If we ever want to do something disciplined w.r.t. upgrade between (non-dev) versions, we're probably going to need a place to look for the state of the world. Decreasing the velocity with which people can add to Salt configuration will encourage people to delete more Salt configuration. cc
Change:
"strings" "k8s.io/apimachinery/pkg/util/json" <del> forkedjson "k8s.io/apimachinery/third_party/forked/golang/json" </del> "k8s.io/apimachinery/pkg/util/mergepatch" <ins> forkedjson "k8s.io/apimachinery/third_party/forked/golang/json" </ins> ) // An alternate implementation of JSON Merge Patch

Discussion:
Extracted from The RawExtension type allows an API object to inline arbitrary JSON. strategicpatch.CreateTwoWayMergePatch returns an error trying to map that inlined JSON to struct fields. It should be able to compute a patch for an object containing a field of that type.
cc
We need to decide what strategic merge patch should do in the following scenarios: unknown fields (can be encountered when the API or a user-defined object has a new field the compiled-in struct doesn't have yet) unmergeable fields (like RawExtension) cc
The current behavior is: unknown fields: trying to merge a unknown field will fail when lookup the metadata in the struct tags unmergeable fields: will be replaced as raw byte array Maybe we can use generic json merge for unmergeable fields?
Did that change since 1.5? In 1.5, we were getting an error during patch computation for objects with a RawExtension field
Sorry. This behavior is in 1.4.7. e.g . It will error in 1.5.
Yeah, the field gets replaced. Even in 1.4.7, an unknown field (like initcontainers in pods) or an object including a RawExtension (anything with a field of type or ) would error
My personal favor would be to instruct the patch to ignore such field, seems the cleanest approach to me. Similarly to how we allow annotating deletion and merging.
wouldn't it be confusing to submit a patch with stuff in that field, have the patch accepted, and have none of your submitted changes take effect? seems like the least surprising thing would be to treat struct fields like or as
How about both, iow. having as a default and as an opt-in. This would allow the resource author to decide how his resource should be treated. Eventually on we could return the ignored fields. Having said that we could start with right away. I think I could work on a patch implementing that if majority agrees (
I think is a good place to start when computing/applying patches for known struct fields like RawExtension. I'll open a separate issue for client-side handling of computing patches for unknown fields
Ignore the field sounds like a really good solution. WDYT of printing a warning to stdeer?
what does ignoring instead of replacing get us?
Sorry I was reading the comment on my phone between other things. Ignore my comment.
Change:
status := v1.PodStatus{ Phase:   v1.PodFailed, <del> Message: nodeShutdownMessage, </del> Reason:  nodeShutdownReason, <ins> Message: nodeShutdownMessage, </ins> } err := m.killPod(pod, status, &gracePeriodOverride)

Discussion:
When using Graceful Node Shutdown feature, status and reason of "shutdown" pod are confusing for users. See where I attempt to address this confusion by documenting the behavior. However, it would be great to improve messages. Perhaps the following renaming: Reason "Shutdown" is confusing because it may appear as a process of shutting down. Better message will also be useful. Reason and Message changed for pods terminated in response to Node shutdown. Shutdown the node and observer the pod status. KEP: kubernetes/enhancements /cc /sig node /help /good-first-issue Kubernetes version (use ): 1.19+ (with feature enabled)
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : #### What happened: /cc /sig node /help /good-first-issue Kubernetes version (use ): 1.19+ (with feature enabled) </details
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/cc
/assign
/assign
Change:
err := framework.RunRC(config) framework.ExpectNoError(err, "Replica must be created") } <ins> // CreateTCPUDPServicePods creates a replication controller with the label same as service. Service listens to TCP and UDP. func (j *TestJig) CreateTCPUDPServicePods(c clientset.Interface, ns string, replica int) { config := testutils.RCConfig{ Client:       c, Name:         j.Name, Image:        framework.ServeHostnameImage, Command:      []string{"/agnhost", "serve-hostname", "--http=false", "--tcp", "--udp"}, Namespace:    ns, Labels:       j.Labels, PollInterval: 3 * time.Second, Timeout:      framework.PodReadyBeforeTimeout, Replicas:     replica, } err := framework.RunRC(config) framework.ExpectNoError(err, "Replica must be created") } </ins>

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : Following are two e2e testing service functioning over same port but different protocol, but do not test service reachability. be able to update NodePorts with two same port numbers but different protocols use same NodePort with same port but different protocols Note: Both the e2e are verifying the same behavior of "service using same port but different protocols" differs in and . Primary goal: Test service reachability for these E2Es. Secondary goal: As both the above e2e are verifying same E2E behavior, it's good to have single e2e in spite of 2 differing in "updating" and "create only" nodePort service. For "create only", suite has another specific e2e . Why is this needed: E2E Improvement and make e2e eligible for Conformance. Service related e2e are getting promoted in /area conformance /sig testing /assign
Change:
stickyMaxAgeSeconds = int(*service.Spec.SessionAffinityConfig.ClientIP.TimeoutSeconds) } info := &serviceInfo{ <del> clusterIP:  net.ParseIP(service.Spec.ClusterIP), port:       int(port.Port), protocol:   port.Protocol, nodePort:   int(port.NodePort), </del> <ins> clusterIP: net.ParseIP(service.Spec.ClusterIP), port:      int(port.Port), protocol:  port.Protocol, nodePort:  int(port.NodePort), // targetPort is zero if it is specified as a name in port.TargetPort. // Its real value would be got later from endpoints. </ins> targetPort: port.TargetPort.IntValue(), // Deep-copy in case the service instance changes loadBalancerStatus:       *service.Status.LoadBalancer.DeepCopy(),

Discussion:
<!-- 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: Tried to create a service using targetPort as a string referencing the name of the pod port. Traffic was not routed to pod. What you expected to happen: Service to route traffic to pod How to reproduce it (as minimally and precisely as possible): See line targetPort Anything else we need to know?: Link that describes how this feature is supposed to work Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-04-27T09:22:21Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"windows/amd64"} Server Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.0", GitCommit:"", GitTreeState:"clean", BuildDate:"2018-09-27T16:55:41Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): WindowsBuildLabEx : .1000.amd64fre.rs_prerelease.-1413 Kernel (e.g. ): Install tools: Others:
/sig windows
/assign
Change:
// Creates a new StorageOS volume and makes it available as a device within // /var/lib/storageos/volumes. func (u *storageosUtil) CreateVolume(p *storageosProvisioner) (*storageosVolume, error) { <ins> klog.V(4).Infof("creating StorageOS volume %q with namespace %q", p.volName, p.volNamespace) </ins> if err := u.NewAPI(p.apiCfg); err != nil { return nil, err }

Discussion:
<!-- 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! If the matter is security related, please disclose it privately via --What happened: When a PVC is created and the PV mounted into a Pod using the StorageOS in-tree volume driver, the StorageOS CLI & UI do not report that the volume is mounted. The PV is created and mounted into the Pod successfully, and all k8s functionality works as expected. However, since the correct mount status is not visible to administrators using the StorageOS UI or CLI, they may make changes to or delete a mounted volume without realising, and the safeguards (must use to delete a mounted volume) do not trigger. This is a regression caused by , released in 1.14.0. What you expected to happen: The StorageOS CLI should report volume mount information (node name, mount timestamp). How to reproduce it (as minimally and precisely as possible): StorageOS node containers with CSI disabled: application Pod with a PVC using the StorageOS StorageClass: StorageOS to list volumes: Anything else we need to know?: Environment: Kubernetes version (use ): 1.14.0 and later Cloud provider or hardware configuration: any OS (e.g: ): any linux (incl. Ubuntu 18.04) Kernel (e.g. ): any linux (incl. 4.15.0-33-generic) Install tools: any (incl. minikube) Network plugin and version (if this is a network-related bug): N/A Others: Requires StorageOS deployment /sig storage /assign
Change:
// test sources _ "k8s.io/kubernetes/test/e2e/apimachinery" _ "k8s.io/kubernetes/test/e2e/apps" <ins> _ "k8s.io/kubernetes/test/e2e/architecture" </ins> _ "k8s.io/kubernetes/test/e2e/auth" _ "k8s.io/kubernetes/test/e2e/autoscaling" _ "k8s.io/kubernetes/test/e2e/cloud"

Discussion:
I can create a cluster with one node and pass conformance, ~there are some tests that require at least 2 nodes to run~ ~~ ~This is because the tests Skip if they are not able to run~ ~~ ~As consequence, the list of tests for conformance depends on the number of nodes, a single cluster node (that is not a cluster by definition of cluster :)) will run less tests than a multi cluster node and still be Conformant~ EDIT I have to correct myself, it seems that the conformance tests doesn't skip, the problem is: there are no conformance tests that exercise anything that requires more than one node, hence, single node cluster can pass conformance. I expect a cluster (a group of similar things or people positioned or occurring closely together) and a "distributed system" to not be able to be single-node. In addition, lots of most important Kubernetes features can not be exercised on one node, lowering the quality bar. local- pass conformance Related discussion <details</details<details</details<details</details<details</details<details</details<details</details
/assign Maybe this has changed, but last time I've checked the minimum for conformance was 1 control-plane and 2 workers, if that didn't change I will submit a PR to enforce it in the suite Regarding sig-network, with one node you can not verify the networking model, where pod to pod in different nodes should be able to communicate without NAT, that is a strong requirement ... I have to review closely what tests do we have in Conformance
/area conformance /sig network
that seems pretty intentional... changing the definition of conformance to require multiple nodes probably deserves more feedback than an issue/PR
I'm not changing the definition, just asserting it
if we are testing features like replicaset, daemonset, services, ..., in one node only we are missing a lot of testing on those features ... a podman/docker single node can be a kubernetes conformance cluster ... do I need a scheduler or network for anything, I'm just deploying always in the same node?
No I don't think so. Where are your results and configuration? You need two schedulable nodes to pass the conformance suite. That's not correct, we test rolling pod behavior with replicasets. This test requires multiple nodes. There is at least one.

That job is not passing conformance, from the configuration: (see: ) Conformance requires not setting --, you must run all tests without skipping. We don't, at the very least replicaset is being tested multi-node, just not in this job that is not running the full conformance suite. When conformance results are submitted they are now validated to ensure that all tests were run.
Change:
var _ = Describe("Probing container", func() { framework := Framework{BaseName: "container-probe"} var podClient client.PodInterface <del> probe := nginxProbeBuilder{} </del> <ins> probe := webserverProbeBuilder{} </ins> BeforeEach(func() { framework.beforeEach()

Discussion:
If the container_probe test runs on a node without the nginx image, it sometimes takes 90s to get the pod in running. Most of this time goes in pulling the image, so I'm assuming it's registry related hiccup. Using might make it more reliable. Example failure: Note the following event in the logs:
a) we should not be pulling from docker in our tests - too hit-or-miss b) we should replace nginx (132 MB) with (4.5 MB) whenever possible. , Prashanth B wrote:
Change:
#   make verify #   make verify BRANCH=branch_x .PHONY: verify <del> verify: </del> <ins> verify: verify_generated_files </ins> KUBE_VERIFY_GIT_BRANCH=$(BRANCH) hack/make-rules/verify.sh -v hack/make-rules/vet.sh

Discussion:
Right now on head () if you run it will end up having a modified file. This happened because some type has been changed and this file should have been generated before commit, and verification should have failed but they didn't.
This is not only a problem with openapi-gen. deepcopy-gen also has the same problem. I've a field to a type (autoscaling/v1) and verify-all passed for the commit (without adding generated code to it). those files will be generated on verify-codegen and it will not fail and the commit can be merged without generated code.
Yeah. So when the Makefile stuff originally went in those files were not checked in. Then we un-did that part, but I didn't re-add them to verify...