jiebi/CodeConvo huggingface dataset:
Change:
echo "waiting for $1 at $2:$3" results=($(ssh-to-node "${test_node}" " set -e; <del> sudo docker pull busybox >/dev/null; sudo docker run busybox sh -c ' </del> <ins> sudo docker pull gcr.io/google_containers/busybox >/dev/null; sudo docker run gcr.io/google_containers/busybox sh -c ' </ins> for i in $(seq -s' ' 1 $(($4*3))); do if wget -q -T 3 -O - http://$2:$3; then echo

Discussion:
Testgrid; https://k8s- Sample Failure: The problem seems to be that Kube-anywhere isn't working since commit /sig cluster-lifecycle /kind failing-test /priority important-soon cc:
/milestone v1.13
sent possible fix PR:
sent new PR might get merged once github is back on track.
Reopening, because the test isn't passing yet. /reopen
Reopening this issue. <detailsIn response to : Reopening, because the test isn't passing yet. 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
true, i was almost sure that the solution in that last PR won't be sufficient... will investigate more tomorrow.
/assign
I see https://k8s- job failing as well. Will the 2 open PRs address this failure as well?
all the kubeadm-gce-x tests are broken at the moment due to the e2e refactor. we will hopefully decide on how to approach the issue today.
latest efforts:
the tests are working on the cluster up/down side, except that they fail when dumping the node logs. looking into it.
should be green by tomorrow.
Looks good, thanks! One flake in the last run - let's keep an eye on it but it should be fine. /cc /close
Closing this issue. <detailsIn response to : Looks good, thanks! One flake in the last run - let's keep an eye on it but it should be fine. 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:
config := options.NewProxyConfig() config.OOMScoreAdj = util.Int32Ptr(0) config.ResourceContainer = "" <del> config.NodeRef = &api.ObjectReference{ </del> <ins> config.NodeRef = &v1.ObjectReference{ </ins> Kind:      "Node", Name:      nodeName, UID:       types.UID(nodeName),

Discussion:
Is this a BUG REPORT or FEATURE REQUEST? (choose one): bug Kubernetes version (use ): master Environment: Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others: What happened: When testing , I found kube-proxy can not record event with following errors. What you expected to happen: No errors How to reproduce it (as minimally and precisely as possible): cc
I am still getting this with the latest build
, thanks for your feedback, I'll check it.
Change:
func (b *vsphereVolumeMounter) GetAttributes() volume.Attributes { return volume.Attributes{ SupportsSELinux: true, <ins> Managed:         true, </ins> } }

Discussion:
Vsphere volumes aren't relabelled in SELinux environment because they set in volume attributes. This flag is important for SELinux support to work - CC The fix is obviously simple and I am happy to make it but I would like to know if there was any reason vsphere volumes don't follow example of other volume types that support SELinux? cc
Made a small PR that fixes it -
Change:
webhook.WithExponentialBackoff(ctx, w.initialBackoff, func() error { result, err = w.subjectAccessReview.CreateContext(ctx, r) return err <del> }) </del> <ins> }, webhook.DefaultShouldRetry) </ins> if err != nil { // An error here indicates bad configuration or an outage. Log for debugging. klog.Errorf("Failed to make webhook authorizer request: %v", err)

Discussion:
What would you like to be : The api server should retry sending audit events to configured webhook sinks regardless of the type of HTTP error code it might receive from the webhooks. Why is this needed: While some components may live with failed data transmissions, this is a particularly sensitive topic for the audit area. The API server audit mechanisms must ensure that no other reasonable option exists before dropping an audit event that may be the only trace of malicious behavior in the cluster. It seems that the current implementation may be improved further in this direction. Currently, when the API server is configured for non-blocking sending of audit events to a webhook audit sink backend, it will retry up to 5 times with exponential backoff, should there be an error in communicating with the webhook, as implemented . However, not all errors will trigger a retry. Some are considered transient and yield retry. Others simply stop the retry cycle. For example, it retries on receiving HTTP code , but not on receiving . The list of error codes that will yield a retry is actually quite small - three HTTP errors and one network error. Any other error will not trigger a retry and the audit events will be lost. The code comments explain that the retry will consider only recoverable failures, which may make sense in other cases, but as far as sending audit events to an audit backend webhook is concerned, it is not sufficient policy. A more robust approach would be to consider any error and give the backend service a chance to recover instead of relying on the error codes semantics and the webhook implementations interpretation of it. That is more inline with having the transmission of audit events as top priority. /sig auth /sig api-machinery
Change:
return err } <ins> // If the kubelet config controller is available, and dynamic config is enabled, start the config and status sync loops if utilfeature.DefaultFeatureGate.Enabled(features.DynamicKubeletConfig) && len(s.DynamicConfigDir.Value()) > 0 && kubeDeps.KubeletConfigController != nil && !standaloneMode && !s.RunOnce { if err := kubeDeps.KubeletConfigController.StartSync(kubeDeps.KubeClient, kubeDeps.EventClient, string(nodeName)); err != nil { return err } } </ins> if s.HealthzPort > 0 { mux := http.NewServeMux() healthz.InstallHandler(mux)

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: The kubelet metrics related to , except for one, are missing from the kubelet metric endpoint. This applies to these metrics: What you expected to happen: I expect that the metrics mentioned above should be found in the endpoint on the kubelet. How to reproduce it (as minimally and precisely as possible): Run kubelet with a valid , and (defaults to true). or run the node e2e tests: Anything else we need to know?: All e2e tests related to DynamicKubeletConfig fails in master (and in v1.16): This bug/error was introduced in Environment: Kubernetes version (use ): && Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node /cc logicalhan tallclair mtaufen
/cc
/assign WIP proof of concept solution to fix (make it a bit easier to understand the problem) here:
/assign
edit: I misunderstood the issue. discussed with offline, and he has an idea to restore previous behavior
That sounds perfect! He answered in the PR, so hopefully we can get this working again. I have wrapped my head around this issue for quite a few hours now, so I understand that it is kinda hard to understand by just reading this issue. Here is some more background info that hopefully makes sense.
/priority important-soon /milestone v1.17
Looks like the CI jobs are cleaning up now! ! Finally down to single digit number test failures, and away from the 30+ :smile:
Change:
} function get_vpc_id { <del> python -c 'import json,sys; lst = [str(vpc["VpcId"]) for vpc in json.load(sys.stdin)["Vpcs"] for tag in vpc["Tags"] if tag["Value"] == "kubernetes-vpc"]; print "".join(lst)' </del> <ins> python -c 'import json,sys; lst = [str(vpc["VpcId"]) for vpc in json.load(sys.stdin)["Vpcs"] for tag in vpc.get("Tags", []) if tag["Value"] == "kubernetes-vpc"]; print "".join(lst)' </ins> } function get_subnet_id {

Discussion:
When using AWS to get a cluster turned up as described , running the kube- script doe not result in the VPC being deleted. The following error is shown: Deleting VPC Traceback (most recent call last): File "&lt;string", line 1, in &lt;moduleKeyError: 'Tags And the VPC is not deleted
This should be fixed by
this is now fixed (I think...)
Change:
<ins> /* Copyright 2016 The Kubernetes Authors All rights reserved. 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 statusupdater import ( "fmt" ) func NewFakeNodeStatusUpdater(returnError bool) NodeStatusUpdater { return &fakeNodeStatusUpdater{ returnError: returnError, } } type fakeNodeStatusUpdater struct { returnError bool } func (fnsu *fakeNodeStatusUpdater) UpdateNodeStatuses() error { if fnsu.returnError { return fmt.Errorf("fake error on update node status") } return nil } </ins>

Discussion:
introduced logic to make kubelet volume manager wait for attach detach controller to finish attach before it starts mount. The controller should also not start a detach operation until the node status has been updated removing the volume from the list of attached volumes. Otherwise if a pod is rapidly created and deleted on the same node, it could result in a mount starting immediately before a detach starts. Props to and his pet set tests for helping catch this.
Hmm, this just happened , just a lot less frequently. Haven't debugged, but it looks like the failed pod did reland on the same node: pet-0, jenkins-e2e-minion-group-4mn2 (). Reopening, will try to confirm when i have time, and close if it's not the same thing.
Just following up with an update, Saad and i are tag teaming this. He's uploading a pr that I'm going to reivew. We're tracking a couple of issues: need to update the "volumes in use" list before polling on the "volumes attached" list. Best option is to write a operation executor, so we don't hammer the apiserver. needs to get up to date node object from apiserver to determine volumes in use. The update that removes volumes from the "attached list" shoud return a fresh node object, we can just iterate the volumes its using (this must happen after popping from attached, though). leaky volumes in the node object (this is not about the physical volumes but about the size of the json blob that's the node object growing). The proposed fix is to use the desired state of the world to update the list of volumes in use. There's a last point I need to follow up on. We might leave the node object in an inconsistent state with the proposed fix, but it should be ok since nothing is checking the inconsistent fields. This will happen if we pop a volume from the attached list, but then find its in use in the updated node object. ping me when you're ready to go, of if you need help
Change:
storageframework "k8s.io/kubernetes/test/e2e/storage/framework" "k8s.io/kubernetes/test/e2e/storage/testsuites" "k8s.io/kubernetes/test/e2e/storage/utils" <ins> "k8s.io/kubernetes/test/utils/format" </ins> imageutils "k8s.io/kubernetes/test/utils/image" )

Discussion:
1 ci-kubernetes-e2e-gci-gce 1 ci-cos-containerd-e2e-cos-gce in the master blocking test grid 1 ci-kubernetes-e2e-gci-gce-network-proxy-grpc 1 ci-kubernetes-e2e-gci-gce-proto Kubernetes e2e suite.[It] [sig-storage] CSI Mock workload info CSI PodInfoOnMount Update should be passed when update from false to true 12/14 code thaw after 1.29.0 release was merged at the time and is related to PodInfoOnMount. /cc /sig storage
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
/assign
testCase: podInfoOnMount should be passed when update from false to true kubelet log: csi-mockplugin-0-mock log: the function in the test case is not working as expected. expect log at Line 2, but actual log is at Line 3.
is called twice for the same volume sometime even though the volume is already published successfully. Not only this issue, but also other issues like I wonder if it is a potential bug or a normal behavior. cc what do you think?
good catch. I think that any test that depends on exact index of NodePublish call will be flaky, sometimes Kubelet has to retry NodePublish. It would be better to check for NodePublish parameter changes. For example, test should check there were 1 or more NodePublish calls with no pod info and then 1 or more NodePublish calls with pod info afterwards.
Change:
break } } <del> dropDisabledFields(newCRD, oldCRD) </del> } // Validate validates a new CustomResourceDefinition.

Discussion:
This is the tracking issue of promoting CRD validation rules to GA: Listed the blocking issues/features below: [x] [x] [x] [x] Issues be aware of but should not be a GA blocker [ ] [ ] [ ] [ ] [ ] /sig api-machinery /triage accepted
/assign
/cc
Change:
], deps = [ "//pkg/api:go_default_library", <ins> "//pkg/api/pod:go_default_library", </ins> "//pkg/apis/settings:go_default_library", "//pkg/apis/settings/validation:go_default_library", "//vendor/k8s.io/apimachinery/pkg/apis/meta/internalversion:go_default_library",

Discussion:
says "Before persisting the object to storage, clear disabled alpha fields". There is that actually implements it but there are some discussions about it. This issues is a reminder that introduced by needs to be cleared too when the discussion in settles down. /assign
There are no sig labels on this issue. Please by: a sig: e.g., to notify the contributor experience sig, OR the label manually: e.g., to apply the label Note: Method 1 will trigger an email to the group. You can find the group list and label list . The in the method 1 has to be replaced with one of these: bugs, feature-requests, pr-reviews, test-failures, proposals
/sig api-machinery
kind/cleanup priority/important-soon
[MILESTONENOTIFIER] Milestone Labels Complete Issue label settings: sig/api-machinery: Issue will be escalated to these SIGs if needed. priority/important-soon: Escalate to the issue owners and SIG owner; move out of milestone after several unsuccessful escalation attempts. kind/bug: Fixes a bug discovered during the current release. <detailsAdditional instructions available <a href=""here</a</details
Change:
fs.DurationVar(&options.config.IPTables.SyncPeriod.Duration, "iptables-sync-period", options.config.IPTables.SyncPeriod.Duration, "The maximum interval of how often iptables rules are refreshed (e.g. '5s', '1m', '2h22m').  Must be greater than 0.") fs.DurationVar(&options.config.IPTables.MinSyncPeriod.Duration, "iptables-min-sync-period", options.config.IPTables.MinSyncPeriod.Duration, "The minimum interval of how often the iptables rules can be refreshed as endpoints and services change (e.g. '5s', '1m', '2h22m').") fs.DurationVar(&options.config.ConfigSyncPeriod.Duration, "config-sync-period", options.config.ConfigSyncPeriod.Duration, "How often configuration from the apiserver is refreshed.  Must be greater than 0.") <del> fs.BoolVar(&options.config.IPTables.MasqueradeAll, "masquerade-all", options.config.IPTables.MasqueradeAll, "If using the pure iptables proxy, SNAT everything (this not commonly needed)") fs.StringVar(&options.config.ClusterCIDR, "cluster-cidr", options.config.ClusterCIDR, "The CIDR range of pods in the cluster. It is used to bridge traffic coming from outside of the cluster. If not provided, no off-cluster bridging will be performed.") </del> <ins> fs.BoolVar(&options.config.IPTables.MasqueradeAll, "masquerade-all", options.config.IPTables.MasqueradeAll, "If using the pure iptables proxy, SNAT all traffic sent via Service cluster IPs (this not commonly needed)") fs.StringVar(&options.config.ClusterCIDR, "cluster-cidr", options.config.ClusterCIDR, "The CIDR range of pods in the cluster. When configured, traffic sent to a Service cluster IP from outside this range will be masqueraded and traffic sent from pods to an external LoadBalancer IP will be directed to the respective cluster IP instead") </ins> fs.StringVar(&options.config.ClientConnection.ContentType, "kube-api-content-type", options.config.ClientConnection.ContentType, "Content type of requests sent to apiserver.") fs.Float32Var(&options.config.ClientConnection.QPS, "kube-api-qps", options.config.ClientConnection.QPS, "QPS to use while talking with kubernetes apiserver") fs.IntVar(&options.config.ClientConnection.Burst, "kube-api-burst", options.config.ClientConnection.Burst, "Burst to use while talking with kubernetes apiserver")

Discussion:
Kubernetes version (use ): v1.6.x What happened: Users tried to understand what the and flags do, but couldn't. What you expected to happen: Expect users to be able to understand from the the description.
/sig network
Change:
"k8s.io/apimachinery/pkg/util/uuid" "k8s.io/kubernetes/test/e2e/framework" e2eskipper "k8s.io/kubernetes/test/e2e/framework/skipper" imageutils "k8s.io/kubernetes/test/utils/image" "github.com/onsi/ginkgo"

Discussion:
We pinging to the original E2Es, however in airgapped environments, these tests fail for obvious reasons: In general, we need to parameterize this if possible. Running the or tests should pass in air-gapped environments, especially those that dont explicitly declare external connectivity. For example: Run the test suites inside of a kuberentes cluster which has no internet connection. pointing finger at :) <details</details<details</details<details</details<details</details<details</details<details</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
some of these were recently removed by :) but some more to remove i think
They should have the corresponding tags so they can be filtered
and do we need to add a parameter in function as and replace from link. If not, what are we trying to achieve here ? I would like to collaborate.
independent test cases with their own feature tags as in
/assign
/sig testing windows network
/triage accepted
Change:
expect := api.PodList{ ListMeta: api.ListMeta{ResourceVersion: "10"}, Items: []api.Pod{ <del> {ObjectMeta: api.ObjectMeta{Name: "foo", ResourceVersion: "1"}}, </del> {ObjectMeta: api.ObjectMeta{Name: "bar", ResourceVersion: "2"}}, {ObjectMeta: api.ObjectMeta{Name: "baz", ResourceVersion: "3"}}, <ins> {ObjectMeta: api.ObjectMeta{Name: "foo", ResourceVersion: "1"}}, </ins> }, }

Discussion:
kubectl returns resources in a random order, which makes it hard to look for things when users have a lot resources. Returning resources in deterministic order should be a helpful and trivial change (hopefully). We have an issue about pagination , but that's a larger and separate issue.
We should be cause to not do this on the * namespace - I think thats a special case. No disagreement for other list calls
What is the default etcd response order? Last created or last modified? Sent from my iPhone
I think the order is by key if sort param is given. If not given, the order is by last created (maybe, but we shouldn't trust it). It seems we are not trying to get sorted result from etcd.
Today, I think it's random order in the child key space in etcd (because the node structure uses a map), so you get golang map iteration order without sort. I don't know if sort on server is any cheaper than sort on client today, so we may want to do this in rest / registry rather than by passing etcd.
Apart from performance, sorting in clients means we can also take control of how responses are sorted, so for * namespace, we can sort by namespace, then by resource ID. , Clayton Coleman wrote: Master of Electrical and Computer Engineering Carnegie Mellon University
We can always hint sort to the registry storage layer in the future, so sorting on the client now won't kill us.
Just took a closer look at our rest/registry code to implement the sort (in client), but implementation-wise, it seems much easier to pass sort to etcd (one line change). Also, namespace is a prefix on resource, so sort across all namespace with etcd key will essentially sort resources by namespace then by Name. If we are to implement sort on client side, we can either: sort package: have each list object, ie.e PodList, ControllerList, implement sort interface. (We won't do this). have ListMeta implement sort interface, if there is a way to find enclosing structs (so we can use items field) have api.Object implement sort interface, verify object is list before sorting. sort algorithm ourself, and do it in rest. Is there other golang or kubernetes idom that I haven't been aware of that can be applied to this use case?

----- Original Message ----- I think sorting it on etcd is fine for now - that's the simplest possible thing that works.
Is there any material perf impact in etcd to enable it? Sent from my iPhone
Probably not material. Can always switch away if necessary
Famous last words :-) Sent from my iPhone
Got my hat ready
Change:
Env: []api_v1.EnvVar{ { Name:  "LOGS_GENERATOR_LINES_TOTAL", <del> Value: strconv.Itoa(linesCount), </del> <ins> Value: strconv.Itoa(p.ExpectedLinesNumber), </ins> }, { Name:  "LOGS_GENERATOR_DURATION", <del> Value: duration.String(), </del> <ins> Value: p.RunDuration.String(), </ins> }, }, Resources: api_v1.ResourceRequirements{

Discussion:
Pods should be run in parallel with checking the logs from the backend to fit into the timeout.