jiebi/CodeConvo huggingface dataset:
Code change:
} // check if deployment's has finished the rollout <del> status, done, err := statusViewer.Status(cmdNamespace, info.Name, revision) </del> <ins> status, done, err := statusViewer.Status(info.Namespace, info.Name, revision) </ins> if err != nil { return err }

Related discussion:
text: <!-- Thanks for filing an issue! Before hitting the button, please answer these questions.--Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see ): No What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): rollout status namespace Is this a BUG REPORT or FEATURE REQUEST? (choose one): Bug Report <!-- If this is a BUG REPORT, please: Fill in as much of the template below as you can. If you leave out information, we can't help you as well. If this is a FEATURE REQUEST, please: Describe in detail the feature/behavior/change you'd like to see. In both cases, be ready for followup questions, and please respond in a timely manner. If we can't reproduce a bug or think a feature already exists, we might close your issue. If we're wrong, PLEASE feel free to reopen it and explain why. --Kubernetes version (use ): Environment: Cloud provider or hardware configuration: Macbook Pro 2015 OS (e.g. from /etc/os-release): Mac OSX Sierra Kernel (e.g. ): Install tools: Others: What happened: , where does the following: Describes a Deployment object Sets a non-default namespace in the metadata . An error message says the resource was not found . The response shows the status of the rollout. What you expected to happen: I expected to work as well by using the namespace that is set inside for the rollout status request. How to reproduce it (as minimally and precisely as possible): the following file as (taken from the but updated to add the namespace): Returns Returns Anything else we need to know: We've seen this issue on 1.5.1 as well, and also on Ubuntu. The recreate instructions above were performed on a fresh minikube setup.
I also noticed this today. The node is using version 1.5.2 and we are using latest gcloud SDK components (v146). At the moment I have to use
This issue also exists on kubectl built from HEAD.
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.
Code change:
} // check if deployment's has finished the rollout <del> status, done, err := statusViewer.Status(cmdNamespace, info.Name, revision) </del> <ins> status, done, err := statusViewer.Status(info.Namespace, info.Name, revision) </ins> if err != nil { return err }

Related discussion:
text: Prevent issues from auto-closing with an comment. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
Code change:
{% if grains.get('cloud', '') == 'gce' and grains.get('os_family', '') == 'Debian' and grains.get('oscodename', '') == 'wheezy' -%} <del> {% set docker_pkg_name='' %} {% set override_deb='' %} {% set override_deb_sha1='' %} {% set override_docker_ver='' %} </del> <ins> {% set docker_pkg_name='docker-engine' %} {% set override_deb='docker-engine_1.9.1-0~wheezy_amd64.deb' %} {% set override_deb_sha1='d682e2f0545e21f2d7309c2d87826aa566cc4af0' %} {% set override_docker_ver='1.9.1' %} </ins> # Ubuntu presents as os_family=Debian, osfullname=Ubuntu {% elif grains.get('cloud', '') == 'aws' and grains.get('os_family', '') == 'Debian'

Related discussion:
text: .
is this your turn?
Sure :) I will work on this! , Dawn Chen wrote:
Update: I'm testing v1.9.0~rc4. I'm running the following suite of tests (based on ) - , , .
Update: No tests failed in suite. This release has been looking good so far.
Update: No tests failed in suite. :smiley:
Update: tests passed.
Note, I'm think we want to set the flag from in
What dns options have to be set?
I would ask but I assume he the flag for a reason ;)
we can use dns-opt when we know we don't have to fall-back on older docker versions. We current have a (very clever) hack that works. We set the ndots option. , Brendan Burns wrote:
Docker has just released v1.9, so I think v1.9 should be validated on high priority.
yep, validation is underway by See above.
I have tested against most of the test suites. As of now there are no known issues. I'm planning on running soak tests next.
I haven't been able to find any issues. I will update HEAD to use docker v1.9 soon.
FYI: (Docker 1.9 serious performance issues)
Are the new /etc/hosts changes going to be an issue?
AFAIK, we want docker to not touch once the container is created.
re:/etc/hosts - we have our workaround which should dodge it entirely. , Vish Kannan wrote:
+1, why is K8S still on docker 1.7.1?
Docker v1.9.1 was released a few weeks ago.
it might be useful to run your mircobenchmark for docker v1.9 before we try to upgrade.
There are still some performance issues with v1.9.1. As of now I'm updating HEAD to run docker v1.9.1 for now to help identify other potential issues. , Yu-Ju Hong wrote:
Can we make sure v1.9.1 can pass e2e tests reliably before upgrading? I am dreading the endless test failures that we'll have to triage at the end of the day. The performance benchmark, e.g., at least can give us some idea about how this is going to affect kubelet.
Yes.
Code change:
{% if grains.get('cloud', '') == 'gce' and grains.get('os_family', '') == 'Debian' and grains.get('oscodename', '') == 'wheezy' -%} <del> {% set docker_pkg_name='' %} {% set override_deb='' %} {% set override_deb_sha1='' %} {% set override_docker_ver='' %} </del> <ins> {% set docker_pkg_name='docker-engine' %} {% set override_deb='docker-engine_1.9.1-0~wheezy_amd64.deb' %} {% set override_deb_sha1='d682e2f0545e21f2d7309c2d87826aa566cc4af0' %} {% set override_docker_ver='1.9.1' %} </ins> # Ubuntu presents as os_family=Debian, osfullname=Ubuntu {% elif grains.get('cloud', '') == 'aws' and grains.get('os_family', '') == 'Debian'

Related discussion:
text: Of course! , Yu-Ju Hong wrote:
I got the result I post before with docker 1.9: Go Version: 1.5.1 Docker Version: Client Version: 1.9.0, API version: 1.21 Server Version: 1.9.0, API version: 1.21
We are now running docker 1.9.1 on the Mesosphere K8s CI. However, this is a little ambiguous, because the containers that run the kubelets still use docker 1.8.2. This upgrade did, however, fix a regular problem we were having in our CI scripts on docker 1.7.1 where layer pulls would block and/or stall (without any other concurrent docker use).
Besides the performance issue I brought up at , there are a network related issue in docker 1.9.1 should affect k8s: cc/ & We should wait for 1.9.2 for whatever reason.
xref: , Dawn Chen wrote:
Introduction I benchmarked and with the following 3 experiments: periodically and , gradually increase the dead container number and alive container number. periodically and , gradually increase the operation interval. periodically and , gradually increase the number of goroutines which doing and . The metrics we measured: CPU usage. latency. latency. Benchmark Environment Cloud Provider: GCE VM Instance: n1-standard-2 (2 vCPUs, 7.5 GB memory) OS: Debian GNU/Linux 8.3 (jessie) Docker version: Experiment 1 Workflow: start -create containers -periodically -periodically -periodically -create containers -... -finish Environment Variable Operation interval: 200ms Container Number ! Latency Docker 1.8.3 ! Docker 1.9.1 ! CPU Usage Docker 1.8.3 ! Docker 1.9.1 ! Experiment 2 Workflow: start -periodically with increasing interval -periodically with increasing interval -periodically with increasing interval -finish Environment Variable Dead container number: 600 Alive container number: 200 Interval ! [all=true] Latency Docker 1.8.3 ! Docker 1.9.1 ! [all=false] Latency Docker 1.8.3 ! Docker 1.9.1 !
Code change:
{% if grains.get('cloud', '') == 'gce' and grains.get('os_family', '') == 'Debian' and grains.get('oscodename', '') == 'wheezy' -%} <del> {% set docker_pkg_name='' %} {% set override_deb='' %} {% set override_deb_sha1='' %} {% set override_docker_ver='' %} </del> <ins> {% set docker_pkg_name='docker-engine' %} {% set override_deb='docker-engine_1.9.1-0~wheezy_amd64.deb' %} {% set override_deb_sha1='d682e2f0545e21f2d7309c2d87826aa566cc4af0' %} {% set override_docker_ver='1.9.1' %} </ins> # Ubuntu presents as os_family=Debian, osfullname=Ubuntu {% elif grains.get('cloud', '') == 'aws' and grains.get('os_family', '') == 'Debian'

Related discussion:
text: Interval ! Latency Docker 1.8.3 ! Docker 1.9.1 ! CPU Usage Docker 1.8.3 ! Docker 1.9.1 ! Experiment 3 Result Workflow: start-periodically with increasing groutines number -periodically with increasing groutines number -finish Environment Variable Dead container number: 600 Alive container number: 200 interval: 1s interval: 0.5s Routine Number ! The change rule of routine number is the same for and . [all=true] Latency Docker 1.8.3 ! Docker 1.9.1 ! Latency Docker 1.8.3 ! Docker 1.9.1 ! CPU Usage Docker 1.8.3 ! Docker 1.9.1 ! Conclusion There is no significant performance difference for and between docker 1.8.3 and docker 1.9.1. Benchmark Tool /cc
Code change:
- [SecurityContextDeny](#securitycontextdeny) - [ResourceQuota](#resourcequota) - [LimitRanger](#limitranger) <del> - [NamespaceExists](#namespaceexists) </del> <ins> - [NamespaceExists (deprecated)](#namespaceexists-deprecated) </ins> - [NamespaceAutoProvision (deprecated)](#namespaceautoprovision-deprecated) - [NamespaceLifecycle](#namespacelifecycle) - [Is there a recommended set of plug-ins to use?](#is-there-a-recommended-set-of-plug-ins-to-use)

Related discussion:
text: We should have a single NamespaceLifecycle plugin that enforces the Namespace rules now that all providers are off NamespaceAutoProvision. We may also want to make this no longer a user choice to configure and hard-wire the server to always run this check first to simplify configuration errors. For an example
Code change:
group_versions+=("${leaf2}/${leaf}") fi done < <( <del> ( kube::codegen::internal::git_grep -l  </del> <ins> ( kube::codegen::internal::git_grep -l --null  </ins> -e '+genclient'  <del> ":(glob)${in_root}"/'**/types.go'  </del> <ins> ":(glob)${in_root}${one_input_api}"/'**/*.go'  </ins> || true  <del> ) | LC_ALL=C sort -u </del> <ins> ) | xargs -0 -n1 dirname  | LC_ALL=C sort -u </ins> ) if [ "${#group_versions[@]}" == 0 ]; then

Related discussion:
text: function in script has following issues: function only supports file but we have multiple types file with name as in . Hence this function is not working in our case. For the mitigation there is already an open . I have asked for including our changes as well. We have multiple files under a for example and . Because of this for appears twice and it generates duplicate informers We only need unique elements before passing it to . I followed this approach for unique elements: We have packages under . Earlier we were generating client only for and . But with the new I am not able to do that. I am using the following call to function: It results in following flags to As there is no directory as , it doesnot generate anything. Is it still possible to call on specific folder as it was done with earlier scripts? One mitigation I can think of is to call function on whole and then remove the marker from the types for which genclient is not needed. But the issue is we won't be able to pass the flag for each pkg. function in script is not working as expected.
/sig api-machinery
/cc
/triage accepted
Hi . I knew that there were all sorts of clients out there doing all sorts of things with these scripts, so I am not surprised to find you. :) Do you have a PR which attempts to use kube_codegen, so I can repro your issues directly?
I think you have one too many in there Aside from that, the real problem here is that these old codegen tools make some deeeeeeep assumptions about the ability to string-join various arguments and get the right results. It's awful. I was trying to make it simpler in this script, which I did for all of the in-tree consumers, but out of tree people apparently don't always follow the same conventions. For example, we generate clients for every directory that requests it. For a reason I do not know, you have files like which say but you don't actually want a client? If you specify then it t
So this code expects that you generate an omnibus client. What if I add a flag, like which you can use to call it for each API to make distinct clients? In truth the codegen tools need to be fixed, but that has SO MUCH ripple I just can't right now.
Code change:
group_versions+=("${leaf2}/${leaf}") fi done < <( <del> ( kube::codegen::internal::git_grep -l  </del> <ins> ( kube::codegen::internal::git_grep -l --null  </ins> -e '+genclient'  <del> ":(glob)${in_root}"/'**/types.go'  </del> <ins> ":(glob)${in_root}${one_input_api}"/'**/*.go'  </ins> || true  <del> ) | LC_ALL=C sort -u </del> <ins> ) | xargs -0 -n1 dirname  | LC_ALL=C sort -u </ins> ) if [ "${#group_versions[@]}" == 0 ]; then

Related discussion:
text: As the codegen was breaking us at several step, hence didn't prepared the PR.
Thanks for the PR. I have one more concern, is it possible to call and client-gen on the same pkg? With the current script, that is not possible because of the line It removes all the generated files first and then calls the . Hence the later clientset gen will remove the earlier generated clients.
Why are you generating a client for an internal version that isn't served?
My mistake. We need to stop using clients for internal versions.
Code change:
fw := compute.Firewall{} fw.Name = gceController.GetFirewallRuleName() <del> fw.SourceRanges = []string{GCEL7SrcRange} </del> <ins> fw.SourceRanges = gcecloud.LoadBalancerSrcRanges() </ins> fw.TargetTags = nodeTags.Items fw.Allowed = []*compute.FirewallAllowed{ {

Related discussion:
text: From GCE email today: Current behavior: You are not required to add firewall rules for Network LB health checks today Action required: We are introducing three new ranges for health checking: 209.85.152.0/22, 209.85.204.0/22, and 35.191.0.0/16. You need to ensure that your firewall allows traffic from 209.85.152.0/22, 209.85.204.0/22, and 35.191.0.0/16. The health check probes to your backend instances will come from one of these ranges. We have until Jan 31, 2018 - 1 year.
/assign this issue explains the confusion I had several weeks ago when speaking with and you about L4 health checks. I didn't realize a firewall rule isn't currently required.
/assign
Is this done now?
Not yet, there is a WIP on .
/close
Code change:
"net", "--runner", "nat-closewait-server", "--options", <del> fmt.Sprintf(`{"LocalAddr":"0.0.0.0:%v", "PostFindTimeoutSeconds":%v}`, </del> <ins> fmt.Sprintf(`{"LocalAddr":":%v", "PostFinTimeoutSeconds":%v}`, </ins> testDaemonTCPPort, postFinTimeoutSeconds), },

Related discussion:
text: Which jobs are failing: kops-aws and many other jobs Which test(s) are failing: This isn't the actual test, but the text we're consistently seeing is Since when has it been failing: Testgrid links: (ref: ) Reason for failure: TBD Anything else we need to know: Very rarely tests pass when one of the tests passes: Seems related to , that was merged about the same time:
/sig cluster-lifecycle /sig aws
The label(s) cannot be applied, because the repository doesn't have them <detailsIn response to : /sig cluster-lifecycle /sig aws 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
/priority critical-urgent this is merge blocking
/assign /cc /cc /cc
The PR we think we want to revert
is also failing, I don't think this is aws-specific
/cc
/assign
it failed with kind too :/ with the same message
Opened to revert
/unassign /sig network /sig testing /remove-sig cluster-lifecycle
/triage unresolved Comment when the issue is assessed and confirmed. I am a bot run by vllry. ‍
This may be the actual cause PR to address But we're going with revert first to be sure we've identified the offending PR
I think I've identified the root cause
Revert brought us back to green: Awaiting root cause fix
/remove-triage unresolved
/reopen merged but we're now seeing multiple tests fail since it merged Looking at it went red between these commits:
Reopened this issue. <detailsIn response to : /reopen merged but we're now seeing multiple tests fail since it merged 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
is an attempt to fix
reverting in
is the failure cluster I suspect will go down once the revert goes in
/close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"
Closing this issue.
Code change:
"net", "--runner", "nat-closewait-server", "--options", <del> fmt.Sprintf(`{"LocalAddr":"0.0.0.0:%v", "PostFindTimeoutSeconds":%v}`, </del> <ins> fmt.Sprintf(`{"LocalAddr":":%v", "PostFinTimeoutSeconds":%v}`, </ins> testDaemonTCPPort, postFinTimeoutSeconds), },

Related discussion:
text: <detailsIn response to : /close Failure cluster has gone down, calling this done <img width="998" alt="Screen Shot 2020-01-10 at 9 56 17 AM" src="https://user-"</details
Code change:
// +groupName=wardle.k8s.io // Package api is the internal version of the API. <del> package wardle </del> <ins> package wardle // import "k8s.io/sample-apiserver/pkg/apis/wardle" </ins>

Related discussion:
text: Look at one of the directories under (Please don't pick more than one directory for one PR as it will cause issues for reviewers) Find all the files named (example find -name ) See the following link it has a this tells tools how this package needs to be imported. So we should ensure that each has an import Add a description appropriate to the package (similar to the one below) Look through sub directories and see if there are any other important directories that are likely to be used by outside users and add a Why are we doing this? We perfer to use vanity urls instead of directly using to refer to code, so this helps ensure that tools honor our wish. See It would be good to have some package level documentation since these directories under staging/ are meant to be for use by folks outside of kubernetes github org. /good-first-issue
/kind documentation /sig architecture
currently working my through Not going to use / assign since there could be a number of PRs for this issue.
/lifecycle active /good-first-issue edit: hmm..
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 : /lifecycle active /good-first-issue 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
May I try on
IIUC this means that there needs to be a even at the root of the repo? Then how does work? :thinking:
Hi , can I make a PR for this directory ?
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
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 .
Code change:
// +groupName=wardle.k8s.io // Package api is the internal version of the API. <del> package wardle </del> <ins> package wardle // import "k8s.io/sample-apiserver/pkg/apis/wardle" </ins>

Related discussion:
text: /lifecycle rotten
I guess this is still not done, was supposed to partially fix this issue. /reopen
Reopened this issue. <detailsIn response to : I guess this is still not done, was supposed to partially fix this issue. 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 rotten /area code-organization
Code change:
} }) <del> ginkgo.It("A set of valid responses are returned for both pod and service ProxyWithPath", func() { </del> <ins> /* Release: v1.21 Testname: Proxy, validate ProxyWithPath responses Description: Attempt to create a pod and a service. A set of pod and service endpoints MUST be accessed via ProxyWithPath using a list of http methods. A valid response MUST be returned for each endpoint. */ framework.ConformanceIt("A set of valid responses are returned for both pod and service ProxyWithPath", func() { </ins> ns := f.Namespace.Name msg := "foo"

Related discussion:
text: [x] two weeks soak start date : testgrid-link [x] two weeks soak end date : [ ] test promotion pr : kubernetes/kubernetes#? According to this APIsnoop query, there are still some remaining ProxyWithPath endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a pod with a static label using the agnhost image Confirm that the pod is in the running phase Iterate through a list of http methods and check the response from the porter app Confirm that each response code is 200 OK If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion. /sig testing /sig architecture /area conformance Where/How does PATCH/HEAD/OPTIONS requests for the following endpoints line up with the API reference? connectCoreV1PatchNamespacedPodProxyWithPath connectCoreV1HeadNamespacedPodProxyWithPath connectCoreV1OptionsNamespacedPodProxyWithPath Pod v1 core: Proxy Operations the following endpoints are listed as valid endpoints; connectCoreV1HeadNamespacedPodProxyWithPath connectCoreV1OptionsNamespacedPodProxyWithPath These requests are getting logged as a verb. Line : api/openapi-spec Line : api/openapi-spec Looking at there doesn't look to be a mapping for the above methods. According to this APIsnoop query, there are still some remaining ProxyWithPath endpoints which are untested. with this query you can filter untested endpoints by their category and eligiblity for conformance. e.g below shows a query to find all conformance eligible untested,stable,core endpoints Create a pod with a static label using the agnhost image Confirm that the pod is in the running phase Create a service and link it to the pod Iterate through a list of http methods and check the response from the porter app Confirm that each response code is 200 OK If a test with these calls gets merged, test coverage will go up by 4 points This test is also created with the goal of conformance promotion.
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.