jiebi/CodeConvo huggingface dataset:
Change:
e2eservice "k8s.io/kubernetes/test/e2e/framework/service" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" testutil "k8s.io/kubernetes/test/utils" <ins> imageutils "k8s.io/kubernetes/test/utils/image" </ins> utilpointer "k8s.io/utils/pointer" )

Discussion:
[x] Original approval issue: [x] Test pr: [x] Two weeks soak end date: 19 November 2020 This issue is created to allow edit by /wip /hold According to this APIsnoop query, there are still some remaining Deployment endpoints which are untested. a Deployment with a static label the Deployment with a new Label and updated data the Deployment to ensure it's patched all Deployments in all Namespaces find the Deployment(1) ensure that the Deployment is found and is patched Namespaced Deployment(1) via a Collection with a LabelSelector Discover useragents: List endpoints hit by the test: Display endpoint coverage change: If a test with these calls gets merged, test coverage will go up by 5 points* This test is also created with the goal of conformance promotion.
/sig testing /sig architecture /area conformance
BobyMcbobs commented in original Issue: Unsure if the endpoint replaceAppsV1NamespacedDeploymentStatus is able to be hit. When this endpoint is attempted to be updated the data after retrieving the update resource doesn't reflect the values in the update
/assign
When using the appv1.Deployment structure instead of maps of interfaces to build the structure in a patch of the Deployment, this error comes up. Still in progress yment-static":"true"}: does not match template , spec.selector: Invalid value: "null": field is immutable]
replaceAppsV1NamespacedDeploymentStatus to test. Increase cover by 1 Endpoint
/reopen PR reverted by due to flaky test
Reopened this issue. <detailsIn response to : /reopen PR reverted by due to flaky test Instructions 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
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
/reopen Soaking, ready for promotion 19 November 2020
Reopened this issue. <detailsIn response to : /reopen Soaking, ready for promotion 19 November 2020 Instructions 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
/remove-lifecycle stale
/triage accepted
/merged
Change:
# Use dynamic cgo linking for architectures other than amd64 for the server platforms # To install crossbuild essential for other architectures add the following repository. RUN echo "deb http://archive.ubuntu.com/ubuntu xenial main universe" > /etc/apt/sources.list.d/cgocrosscompiling.list  <del> && apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5 3B4FE6ACC0B21F32  </del> <ins> && apt-key adv --no-tty --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5 3B4FE6ACC0B21F32  </ins> && apt-get update  && apt-get install -y build-essential  && for platform in ${KUBE_DYNAMIC_CROSSPLATFORMS}; do apt-get install -y crossbuild-essential-${platform}; done 

Discussion:
The go team has released 1.11.3 with three security fixes. From their e-mail announcement: We should kick off upgrades of both the kubernetes build system, and our CI, as soon as possible. Do you have an ETA for the rules_go bump that will contain 1.11.3 toolchain support? cc:
I'm preparing releases that use Go 1.11.3 by default. Those will be on the rules_go 0.14, 0.15, and 0.16 branches. I expect to tag them tonight as soon as they get through CI.
Fantastic! Thank you
rules_go 0.14.7, 0.15.9, and 0.16.4 are now tagged and ready to go.
related commits and issue:
Reopening to track other branches, as well as the CI bump
go1.11.3 and go1.10.6 introduced a regression, and so go1.11.4 and go1.10.7 were released Friday afternoon with a fix. We'll need to bump everything again on master, and should hold off on cherry-picks for now.
This looks fixed by Is there anything else that needs to be done as well?
Still need to merge for k8s 1.13.
Closing as all branches are now up to date.
Change:
return err } <del> return clientcmd.ModifyConfig(o.configAccess, *config, false) </del> <ins> if err := clientcmd.ModifyConfig(o.configAccess, *config, false); err != nil { return err } if _, err := fmt.Fprintf(out, "Property %q unset.n", o.propertyName); err != nil { return err } return nil </ins> } <del> func (o *unsetOptions) complete(cmd *cobra.Command) error { endingArgs := cmd.Flags().Args() if len(endingArgs) != 1 { return helpErrorf(cmd, "Unexpected args: %v", endingArgs) </del> <ins> func (o *unsetOptions) complete(cmd *cobra.Command, args []string) error { if len(args) != 1 { return helpErrorf(cmd, "Unexpected args: %v", args) </ins> } <del> o.propertyName = endingArgs[0] </del> <ins> o.propertyName = args[0] </ins> return nil }

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT Kubernetes version (use ): 1.5.3 Environment: Cloud provider or hardware configuration: minikube 0.17.1 How to reproduce it (as minimally and precisely as possible): config Note that there's only one context. the property of a non-existent context config Note that a context named foo was created just because I tried to unset a property. What you expected to happen: should give an informative message saying that context doesn't exist. Anything else we need to know: This is probably low-hanging fruit.
/sig cli
/assign i will take a look for this
GitHub didn't allow me to assign the following users: a, look, for, this, i, will, take. Note that only can be assigned. <detailsIn response to : /assign i will take a look for this Instructions 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
i can reproduce this, this is a bug, have open PR fix this. thanks
/kind bug
Change:
// if nothing is found, just print usage cmd.Root().Usage() } <del> } else if len(a) == 0 { // help message for help command :) cmd.Root().Usage() </del> } else { <ins> if len(args) == 0 { // help message for help command :) foundCmd = cmd } </ins> helpFunc := foundCmd.HelpFunc() helpFunc(foundCmd, args) }

Discussion:
PR broke command due to wrong check . Currently, it displays for every command if you do not specify additional arguments(for example will not work, but will).
please looks at this small fix
Change:
} var map_IPBlock = map[string]string{ <del> "":       "DEPRECATED 1.9 - This group version of IPBlock is deprecated by networking/v1/IPBlock. IPBlock describes a particular CIDR (Ex. "192.168.1.1/24") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.", "cidr":   "CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24"", "except": "Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" Except values will be rejected if they are outside the CIDR range", </del> <ins> "":       "DEPRECATED 1.9 - This group version of IPBlock is deprecated by networking/v1/IPBlock. IPBlock describes a particular CIDR (Ex. "192.168.1.1/24","2001:db9::/64") that is allowed to the pods matched by a NetworkPolicySpec's podSelector. The except entry describes CIDRs that should not be included within this rule.", "cidr":   "CIDR is a string representing the IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64"", "except": "Except is a slice of CIDRs that should not be included within an IP Block Valid examples are "192.168.1.1/24" or "2001:db9::/64" Except values will be rejected if they are outside the CIDR range", </ins> } func (IPBlock) SwaggerDoc() map[string]string {

Discussion:
<!-- Please only use this template for submitting enhancement requests --What would you like to be : mentions an IPBlock with only IPv4 examples. Add a comment or example to clarify that IPv6 network blocks are (or possibly aren't) valid here. Why is this needed: Cluster operators who use IPv6 networking want to understand how to isolate different workloads inside their cluster network (and without reading source code). Logged against kubernetes/kubernetes rather than the website repo because this is generated documentation. Kubernetes already has single-stack support for IPv6 clusters KEP for dual-stack support is /sig docs /sig network /priority backlog
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
/assign /remove-triage unresolved can you guide me on what steps are needed to publish the examples?
I via the pull request. (Although I want these examples , it's not a task I'm familiar with).
Change:
fmt.Println("Skipping pre-flight checks") } <del> // TODO(phase1+) this we are missing args from the help text, there should be a way to tell cobra about it if len(args) == 0 && len(cfg.MasterAddresses) == 0 { return nil, fmt.Errorf("must specify master IP address (see --help)") } cfg.MasterAddresses = append(cfg.MasterAddresses, args...) </del> ok, err := kubeadmutil.UseGivenTokenIfValid(&cfg.Secrets) if !ok { if err != nil {

Discussion:
Environment: VMware CentOS Linux release 7.2.1511 (Core) kernel: 3.10.0-327.36.1.el7.x8664 Installed packages: kubeadm.x8664 1.5.0-0.alpha.0.1534.gcf7301f kubectl.x8664 1.4.0-0 kubelet.x8664 1.4.0-0 kubernetes-cni.x8664 0.3.0.1-0. docker-engine.x8664 1.11.2- docker-engine- 1.12.1- What happened: kubeadm init hangs indefintely after: kubeadm init <master/tokensgenerated token: "." <master/pkicreated keys and certificates in "/etc/kubernetes/pki" <util/kubeconfigcreated "" <util/kubeconfigcreated "" <master/apiclientcreated API client configuration <master/apiclientcreated API client, waiting for the control plane to become readykubeadm init What you expected to happen: Master node initialize Anything else do we need to know: Only the kubeadm and kublet processes are running. When I do docker ps no containers are running. If i type docker images the only image that has been downloaded are: I've also tried: kubeadm init --api-advertise-addresses but with the same outcome (followed the clean-up at ) Im behind a firewall so I'm using proxy settings for docker. I have confirmed I can reach images on docker hub and google cloud registry
will download the required binaries viz etcd. When you are behind firewall kubeadm will hang/wait forever to download the binaries. I dont know whether it is addressed correctly in kubeadm implementation. I am also facing the same issue and waiting for the resolution.
Thx, I suspected it to be some firewall issue. Do you know if there's a way to add httpsproxy & httpproxy settings to kubeadm?
Kubeadm doesn't seem to pick proxy environment variables. I am looking at recompiling with proxy support may work. But I dont know how to do that. Waiting for updates about proxy
This issue same as Lets join there. The solution mentioned there may work.

You can try kubeadm with patch applied from PR : It works at least in my environment behind restrictive proxy.
thanks, I will look into it
Change:
resources: ["namespaces"] verbs: ["get", "watch", "list"] - apiGroups: ["admissionregistration.k8s.io"] <del> resources: ["mutatingwebhookconfigurations", "validatingwebhookconfigurations"] </del> <ins> resources: ["mutatingwebhookconfigurations", "validatingwebhookconfigurations", "validatingadmissionpolicies", "validatingadmissionpolicybindings"] </ins> verbs: ["get", "watch", "list"] - apiGroups: ["flowcontrol.apiserver.k8s.io"] resources: ['prioritylevelconfigurations', 'flowschemas']

Discussion:
Deployed sample-apiserver into a kind cluster following the instructions in Checked wardle-server pod logs, found the following error: No such errors. Deployed sample-apiserver into a kind cluster following the instructions in <details</detailsKIND
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
/sig api-machinery
/assign Will submit a fix shortly.
Change:
cacher.ready.wait() // Ensure there is some budget for slowing down processing. <del> cacher.dispatchTimeoutBudget.returnUnused(50 * time.Millisecond) </del> <ins> // When using the official `timeBudgetImpl` we were observing flakiness // due under the following conditions: // 1) the watch w1 is blocked, so we were consuming the whole budget once //    its buffer was filled in (10 items) // 2) the budget is refreshed once per second, so it basically wasn't //    happening in the test at all // 3) if the test was cpu-starved and we weren't able to consume events //    from w2 ResultCh it could have happened that its buffer was also //    filling in and given we no longer had timeBudget (consumed in (1)) //    trying to put next item was simply breaking the watch // Using fakeTimeBudget gives us always a budget to wait and have a test // pick up something from ResultCh in the meantime. cacher.dispatchTimeoutBudget = &fakeTimeBudget{} </ins> makePod := func(i int) *examplev1.Pod { return &examplev1.Pod{

Discussion:
<!-- Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI --Which jobs are flaking: bazel-test-master (periodic-kubernetes-bazel-test-master ) Which test(s) are flaking: gotest: Testgrid link: Reason for failure: Anything else we need to know: links to appreciated links to specific failures in spyglass appreciated <!-- Please see the deflaking doc () for more guidance! --cc
/sig api-machinery
This is continuing to be flaky with more recent failure:
/assign Would you mind taking a look here? thanks! /triage accepted
- can we somehow uncover when this started happening? This test is very old and it seems it started happening very recently, so it would be helpful to see when this started happening...
Triage shows flakes starting ~Sept 30: Before Sept 30 it seems the job was flaking much less frequently.
Might be related to I will take a look.
It seems it's not related to that PR (neither to the previous: ) As there were already failures like that on Sep 24th (before this one was merged). I will take a deeper look.
OK - it's not related to any changes mentioned before. I can reproduce this particular failure by simply adding somewhere in this block: So it's probably connected to cpu-starvation at the test level and the solution is to switch to less aggressive timeouts. Will send out a PR.
Actually - it appeared to be slightly more subtle then that. But I already fully understand the problem. It's purely test issue, but require a bit more changes (and I won't get to it today/tomorrow). I will send a fix for that early next week.
- if that changes anything from your tracking perspective ^^
No board changes yet - the next stage is "Observing" once this issue gets closed :) If you have time - I'd love to pick your brain/understand the error more thoroughly though! Hoping you drop a good explanation in your PR next week
Thanks for sharing those insights, on your discovery of the solution to this bug.
It seems the PR didn't address that fully. Looking.
out for review
Change:
return result, err } for _, service := range services.Items { <del> name := strings.ToUpper(service.ID) + "_SERVICE_PORT" </del> <ins> name := makeEnvVariableName(service.ID) + "_SERVICE_PORT" </ins> value := strconv.Itoa(service.Port) result = append(result, api.EnvVar{Name: name, Value: value}) result = append(result, makeLinkVariables(service, machine)...)

Discussion:
In issue it appeared that consensus was reached that a service id could contain a hyphen, but that it would be translated to an underscore in the environment variables (this issues was the root problem, back in ). However, the replacement does not appear to have been done: hyphens are still not replaced with underscores in env-var names. (Although now underscores are blocked in service names!)
Hm, that's weird. I thought that this code was doing replacement. Did that get removed?
Thanks for looking into this lavalamp. Was your question directed at me? I don't see any string replacement code in the code you linked to, at least not for the (I do see escaping for the port in line 198)
Ah, no, I was just thinking out loud there. Maybe knows what happened?
Ah, that's an oversight. We do it for the Docker link style variables, but not the old school ones. I'll send a PR.
PR sent.
Change:
<del> // +build windows /* Copyright 2018 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package dockershim import ( dockertypes "github.com/docker/docker/api/types" dockercontainer "github.com/docker/docker/api/types/container" runtimeapi "k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2" ) // applySandboxPlatformOptions applies platform specific options to dockercontainer.HostConfig and dockercontainer.ContainerCreateConfig. func (ds *dockerService) applySandboxPlatformOptions(hc *dockercontainer.HostConfig, config *runtimeapi.PodSandboxConfig, createConfig *dockertypes.ContainerCreateConfig, image string, separator rune) error { dnsConfig := config.GetDnsConfig() if dnsConfig == nil { return nil } // Setup DNS. hc.DNS = dnsConfig.GetServers() hc.DNSSearch = dnsConfig.GetSearches() hc.DNSOptions = dnsConfig.GetOptions() return nil } </del>

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: is trying to setup DNS for Windows containers, so that Pods on Windows could confirm to dns policies. However, as posted Docker is not managing the networking here for windows. So it doens't really care about any network settings. So passing it to docker shim's hostconfig also doens;t make sense here. DNS for Windows containers will be set by CNI plugins. So PR reverts . This issue tracks the process of pushing DNS configure into CNI and passed that from Kubelet to container runtime. What you expected to happen: Pods on Windows confirm to dns policies. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: /sig windows
Need a linked issue & PR in CNI repo too so that capability arguments can be validated from kubelet
Fixed in by dns capabilities, Azure CNI has already supported this. /close
Closing this issue. <detailsIn response to : Fixed in by dns capabilities, Azure CNI has already supported this. Instructions 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
Change:
// JSON, or if either patch or update calls fail; it will also return a second error // whenever creating a patch has failed func (c *CordonHelper) PatchOrReplace(clientset kubernetes.Interface, serverDryRun bool) (error, error) { <ins> return c.PatchOrReplaceWithContext(context.TODO(), clientset, serverDryRun) } // PatchOrReplaceWithContext provides the option to pass a custom context while updating // the node status func (c *CordonHelper) PatchOrReplaceWithContext(clientCtx context.Context, clientset kubernetes.Interface, serverDryRun bool) (error, error) { </ins> client := clientset.CoreV1().Nodes() oldData, err := json.Marshal(c.node)

Discussion:
What would you like to be : For , the method of the object should accept a user supplied context which is then used by the client to update the status of the node before cordon/uncordoning the node. Why is this needed: Currently uses a local copy of the drain/cordon code from the codebase. Instead of maintaining a local copy, we would like to incorporate the functionality using upstream imports from . In the CAPI codebase, we pass a object to all the controller Reconcile routines and sub-routines. We would like to keep this same behavior even when we move to importing the drain code from I noticed that the code at does not use a passed context but instead uses a placeholder context for the patch/update calls. Instead, we can modify the method to accept a custom context passed over from the drain helper.
/sig cli
/triage accepted /priority backlog
Change:
<ins> /* Copyright 2023 The Kubernetes Authors. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. */ package metrics import ( "sync" "k8s.io/component-base/metrics" "k8s.io/component-base/metrics/legacyregistry" ) const ( namespace = "apiserver" subsystem = "encryption_config_controller" ) var ( encryptionConfigAutomaticReloadFailureTotal = metrics.NewCounter( &metrics.CounterOpts{ Namespace:      namespace, Subsystem:      subsystem, Name:           "automatic_reload_failures_total", Help:           "Total number of failed automatic reloads of encryption configuration.", StabilityLevel: metrics.ALPHA, }, ) encryptionConfigAutomaticReloadSuccessTotal = metrics.NewCounter( &metrics.CounterOpts{ Namespace:      namespace, Subsystem:      subsystem, Name:           "automatic_reload_success_total", Help:           "Total number of successful automatic reloads of encryption configuration.", StabilityLevel: metrics.ALPHA, }, ) encryptionConfigAutomaticReloadLastTimestampSeconds = metrics.NewGaugeVec( &metrics.GaugeOpts{ Namespace:      namespace, Subsystem:      subsystem, Name:           "automatic_reload_last_timestamp_seconds", Help:           "Timestamp of the last successful or failed automatic reload of encryption configuration.", StabilityLevel: metrics.ALPHA, }, []string{"status"}, ) ) var registerMetrics sync.Once func RegisterMetrics() { registerMetrics.Do(func() { legacyregistry.MustRegister(encryptionConfigAutomaticReloadFailureTotal) legacyregistry.MustRegister(encryptionConfigAutomaticReloadSuccessTotal) legacyregistry.MustRegister(encryptionConfigAutomaticReloadLastTimestampSeconds) }) } func RecordEncryptionConfigAutomaticReloadFailure() { encryptionConfigAutomaticReloadFailureTotal.Inc() recordEncryptionConfigAutomaticReloadTimestamp("failure") } func RecordEncryptionConfigAutomaticReloadSuccess() { encryptionConfigAutomaticReloadSuccessTotal.Inc() recordEncryptionConfigAutomaticReloadTimestamp("success") } func recordEncryptionConfigAutomaticReloadTimestamp(result string) { encryptionConfigAutomaticReloadLastTimestampSeconds.WithLabelValues(result).SetToCurrentTime() } </ins>

Discussion:
ref - /sig auth
/triage accepted
/retitle encryption-at-rest: add success or failure metric when encryption configuration attempts to dynamically update
/assign