jiebi/CodeConvo huggingface dataset:
Code change:
It is planned to improve accounting for resources which are shared by all containers in a pod, such as [EmptyDir volumes](volumes.md#emptydir). <del> The current system only supports container limits for CPU and Memory. </del> <ins> The current system only supports container requests and limits for CPU and Memory. </ins> It is planned to add new resource types, including a node disk space resource, and a framework for adding custom [resource types](../design/resources.md#resource-types). <del> The current system does not facilitate overcommitment of resources because resources reserved with container limits are assured.  It is planned to support multiple levels of [Quality of Service](http://issue.k8s.io/168). </del> <ins> Kubernetes supports overcommitment of resources by supporting multiple levels of [Quality of Service](http://issue.k8s.io/168). </ins> Currently, one unit of CPU means different things on different cloud providers, and on different machine types within the same cloud providers.  For example, on AWS, the capacity of a node

Related discussion:
text: did which addresses some of them, but turns up a lot more.
Alright, I will do that.
Code change:
"k8s.io/kubernetes/pkg/watch" "github.com/golang/glog" <ins> "net/http" </ins> ) const maxTriesPerEvent = 12

Related discussion:
text: I keep seeing these server rejected event errors every now and then. My guess is it is trying to update an event that was expired in etcd. However I don't expect an error, since there is specific logic in to handle that use case. Any ideas why this may happening? I am using kubernetes 1.2. Here is an example, from a host getting to a cluster:
Found the problem - the recordEvent logic in was expecting the wrong status code. I've submitted a PR for it. This could be reproduced by: 1 - Update load balancers by remove a node, then adding it back 2 - Remove all events manually from etcd for that namespace 3 - Remove node and add it back again - this results in server rejected event error
Code change:
"k8s.io/kubernetes/pkg/scheduler/apis/config/scheme" ) <del> // Default creates a default configuration of the latset versioned type. </del> <ins> // Default creates a default configuration of the latest versioned type. </ins> // This function needs to be updated whenever we bump the scheduler's component config version. func Default() (*config.KubeSchedulerConfiguration, error) { versionedCfg := v1beta2.KubeSchedulerConfiguration{}

Related discussion:
text: ci-kubernetes-e2e-gci-gce-alpha-features kubetest.Up Jul 02 2021, 01:26:42 UTC+0200 /sig release
based on testgrid probably cc <img width="1203" alt="Screen Shot 2021-07-02 at 4 24 25 PM" src="https://user-"
/cc working on it
/assign
the scheduler fails to start with this error: it seems the feature gates from the command line does not take effect in the defaulting phrase, do you know how to fix it?
ah, found there is a cycle here: The scheduler options , but the default config's default values depend on the feature gates options. I think this disables other feature gate controlled logic in the defaulting too:
I tried to fix it by updating the component config after the CLI flags (including the feature gates) are parsed: PTAL
fixed the flake. is back green now.
thanks!
Code change:
} // getNodeSecurityGroupIDForLB lists node-security-groups for specific nodes <del> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { nodeSecurityGroupIDs := sets.NewString() </del> <ins> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, network *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { secGroupNames := sets.NewString() </ins> for _, node := range nodes { nodeName := types.NodeName(node.Name) srv, err := getServerByName(compute, nodeName) if err != nil { <del> return nodeSecurityGroupIDs.List(), err </del> <ins> return []string{}, err </ins> } // use the first node-security-groups

Related discussion:
text: Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: kubelet fails when Kubernetes master gets started using cloud-provider openstack und kubeadm init command. says: What you expected to happen: kubelet starts and manages the loadbalancer and its security group. How to reproduce it (as minimally and precisely as possible): Setup an instance on Openstack. Place the following cloud-config in And : As well as : Run: For further information: +-----------------+
--------------------------+ +-----------------+
--------------------------+ +-----------------+
--------------------------+ Environment: Kubernetes version (use ): 1.9.1 Cloud provider or hardware configuration: Openstack OS (e.g. from /etc/os-release): Ubuntu 16.04.3 LTS Kernel (e.g. ): x86_64 Install tools: kubeadm
/sig cloud-provider
Looks like auto-probing for for (s), please see [1] and [2]. Apologies, the deprecation should have been handled better. [1] [2]
If I understand you correctly, this cloud-config would be enough: If I try this, no Loadbalancer gets created at all and the service which requests type LoadBalancer says: The service I use there is the nginx helm chart ().
Can you please comment? /assign
/sig openstack
From that, '' is your service name and '-202f-4d44-a538-' is your subnet id, can you ensure '-202f-4d44-a538-' exist? Is it "-c60c-48cb-a146-"? I suspect that failed to autoprobe subnet. Can you give me more logs from kube controller manager
Actually, -202f-4d44-a538- is a network, not a subnet. The subnet has the ID -c1d5-4cc1-8b98-
And here the relevant logs from kube-controller-manager,first: And then it keeps repeating:
Oh, I see. Oops, should get 'sub network id', not 'network id'. I will fix it soon.
I tried the fix in 1.9.2, but it does not work. I tried multiple setting combinations of providing and/or/neither , but none works. The Service does not get a LoadBalancer IP assigned.
Code change:
} // getNodeSecurityGroupIDForLB lists node-security-groups for specific nodes <del> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { nodeSecurityGroupIDs := sets.NewString() </del> <ins> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, network *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { secGroupNames := sets.NewString() </ins> for _, node := range nodes { nodeName := types.NodeName(node.Name) srv, err := getServerByName(compute, nodeName) if err != nil { <del> return nodeSecurityGroupIDs.List(), err </del> <ins> return []string{}, err </ins> } // use the first node-security-groups

Related discussion:
text: Here are the logs and settings for the config version neither providing nor , since it seemed that's the way you recommended to me: cat /etc/kubernetes/pki/cloud-config kubectl get nodes journalctl -u kubelet.service kubectl describe svc ingress-nginx-ingress-controller Can you please re-open the issue? Do you need any other information?
Is it ok when you disable manage-security-group(manage-security-group=false)?
And please review .
/reopen
Yes, when I disable "manage-security-group" it assigns a LoadBalancer correctly. It also works, as soon as I run . I tried to check , but since I don't know go, I don't really understand what you are doing there and how it relates to my issue.
I check gophercloud.ErrResourceNotFound is not a interface, so the '' will return error and excute "" which is 'error occurred finding security group: ...'.
Okay, so you "just" print a better error message, right? But my question is, why does the error occur at all? In my understanding the kubelet should create a security-group on itself, if configured manage-security-groups=true and do not provide a security-group. However I also tried to define a valid security group id on my own, but in that case I again find these logs in kubelet (same as described first):
Okay, so you "just" print a better error message, right? But my question is, why does the error occur at all? In my understanding the kubelet should create a security-group on itself, if configured manage-security-groups=true and do not provide a security-group. No, not 'just print a better error message', openstack cloud provider can ensure security group for LB. Firstly, openstack cloud provider check whether security group does not exist, if not exist, it will create security group for LB. The "gophercloud.ErrResourceNotFound" means that security group not exist.
Now OpenStack cloud provider has not "node-security-group" variable. You should not specify it.
Please check this note:
Well, to me it does not look like the removal of any resources is the problem, rather that they do not get created at all. I can offer you a direct debugging session using Google Hangout or so, maybe that way it is easier to detect the real problem?
Have you see this log?
Code change:
} // getNodeSecurityGroupIDForLB lists node-security-groups for specific nodes <del> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { nodeSecurityGroupIDs := sets.NewString() </del> <ins> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, network *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { secGroupNames := sets.NewString() </ins> for _, node := range nodes { nodeName := types.NodeName(node.Name) srv, err := getServerByName(compute, nodeName) if err != nil { <del> return nodeSecurityGroupIDs.List(), err </del> <ins> return []string{}, err </ins> } // use the first node-security-groups

Related discussion:
text: It means the security group we need to create does not exist, we should create it, not raise error, right? And I get 'non-interface type ErrResourceNotFound on left' error, 'err.(*gophercloud.ErrResourceNotFound)' is incorrect.
Yes, exactly. I also tried to fix the error manually, so first I created the sg-group . After that kubelet complained about empty pool-targets. After fixing that, it complained about invalid endpoint which pointed to the nginx server, don't know how to fix that one yet. I just want to point out: All that errors only occur if I activate manageSecurityGroups, otherwise the kubelet is able to assign a LoadBalancer to the IngressController.
Hi, how is going? I've deployed k8s 1.9.5 on OpenStack with kubespray and I'm struggling with this issue. If I do not set the LBAAS is created but it's not assigned to any Security Group. So, the service is not reachable from the outside world. I can fix it by hand creating the Security Group and assign it to the VIP. If I do set kubelet fails to start. According to it's a valid parameter... (?) And finally, if I do as in his last comment, the LBAAS remains in a PENDING state forever... Well, I wonder if there is any workaround to deal with this... I presume you're working on the fix, aren't you? Any information will be appreciate. Thanks
I'm hitting the same issue as yours with openstack loadbalancer with 1.9.4. Anyone know if fixes this issue? If so, when will it be part of a release?
Any updates on this?
I just tried to use this feature in kubernetes 1.10.2 and it still seems to be broken. The security groups do not get created and the service creation is stuck at pending without an ip address. I used this configuration and i also tried all the alternatives listed here. Either nothing gets created or the controller-manager crashes if i add node-security-group.
It's an issue with as well. The behaviour is as described by
Bump
fixes this for us.
So, If I do not enable manage-security-groups, This should work?
Code change:
} // getNodeSecurityGroupIDForLB lists node-security-groups for specific nodes <del> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { nodeSecurityGroupIDs := sets.NewString() </del> <ins> func getNodeSecurityGroupIDForLB(compute *gophercloud.ServiceClient, network *gophercloud.ServiceClient, nodes []*v1.Node) ([]string, error) { secGroupNames := sets.NewString() </ins> for _, node := range nodes { nodeName := types.NodeName(node.Name) srv, err := getServerByName(compute, nodeName) if err != nil { <del> return nodeSecurityGroupIDs.List(), err </del> <ins> return []string{}, err </ins> } // use the first node-security-groups

Related discussion:
text: I am getting the following error: Error creating load balancer (will retry): failed to ensure load balancer for service default/lbs-test: error creating LB floatingip {FloatingNetworkID:YYYY FloatingIP: PortID:XXXX FixedIP: TenantID:}: Resource not found
Yes. Don't specify and at all in config. The LoadBalancer(s) will by default apply the security rules in the security-group .
You need to specify to automatically add / alter security groups. I get the following error after I've upgraded to 1.9.10:
I ran into the same issue. It seems to be related to how k8's openstack driver deals with adding floating ips to the LB. For now I set the lb to internal in the service metadata then manually associate a floating ip . This could also be a queens magnum issue not providing all required cloud config info. I am not sure yet.
Code change:
expectedError: false, }, { <ins> desc: "valid: 1 search path with trailing period", dnsConfig: &core.PodDNSConfig{ Searches: []string{"custom."}, }, expectedError: false, }, { </ins> desc: "valid: 3 nameservers and 6 search paths", dnsConfig: &core.PodDNSConfig{ Nameservers: []string{"127.0.0.1", "10.0.0.10", "8.8.8.8"}, <del> Searches:    []string{"custom", "mydomain.com", "local", "cluster.local", "svc.cluster.local", "default.svc.cluster.local"}, </del> <ins> Searches:    []string{"custom", "mydomain.com", "local", "cluster.local", "svc.cluster.local", "default.svc.cluster.local."}, </ins> }, expectedError: false, },

Related discussion:
text: What happened: When I create a pod with specified dnsConfig, the validation says my spec is invalid. And the error is like below: What you expected to happen: The spec should be accepted as it is totally fine to have trailing period. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): v1.12.3
Despite it's possible to have domains with trailing periods in the field of the , I agree with about this topic: FQDN and domains are different things. Maybe enforcing this in kubernetes is not a bad idea since the resolver seems to ignore the trailing dots.
let’s say you have name server A, and the serach domain at client has , when you try to resolve name abc, the client will send to name server A. Now what happened if nameserver A can not resolve , it is going to try to append its own searches, for example, name server has its searches as , then it tries to resolve (Depends on the ndots options, this may be allowed). Instead, if you have the trailing period in searches, the second try won’t happen.
what I'm trying to point out is that my understanding is that the and doesn't matter if you add a trailing dot or not to the domain used in the field, thus server A in your example is always going to receive a query to an FQDN and not going to do a recursive search. If you do a test in your system you can capture the traffic and check that the query is always the same with or without a traling dot. Anyway, adding domains with dots is allowed so you are right, only wanted to go deeper into this topic and shared my thoughts :)
Code change:
# Defaults # local input_pkgs=() <del> while read -r file; do dir="$(dirname "${file}")" </del> <ins> while read -r dir; do </ins> pkg="$(cd "${dir}" && GO111MODULE=on go list -find .)" input_pkgs+=("${pkg}") done < <( <del> ( kube::codegen::internal::git_grep -l  </del> <ins> ( kube::codegen::internal::git_grep -l --null  </ins> -e '+k8s:defaulter-gen='  ":(glob)${root}"/'**/*.go'  || true  <del> ) | LC_ALL=C sort -u </del> <ins> ) | xargs -0 -n1 dirname  | LC_ALL=C sort -u </ins> ) if [ "${#input_pkgs[@]}" != 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:
# Defaults # local input_pkgs=() <del> while read -r file; do dir="$(dirname "${file}")" </del> <ins> while read -r dir; do </ins> pkg="$(cd "${dir}" && GO111MODULE=on go list -find .)" input_pkgs+=("${pkg}") done < <( <del> ( kube::codegen::internal::git_grep -l  </del> <ins> ( kube::codegen::internal::git_grep -l --null  </ins> -e '+k8s:defaulter-gen='  ":(glob)${root}"/'**/*.go'  || true  <del> ) | LC_ALL=C sort -u </del> <ins> ) | xargs -0 -n1 dirname  | LC_ALL=C sort -u </ins> ) if [ "${#input_pkgs[@]}" != 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:
"sort" "strconv" "strings" <ins> "sync" "sync/atomic" </ins> "testing" "time"

Related discussion:
text: pull-kubernetes-unit sometimes fails with data race. TestDirty I think the test was 3 months ago with the flaking state. There are two issues. First, updating and reading a bool-type variable is not thread-safe. and there is also another problem checking the state before completely syncing it. No response /sig api-machinery
/assign
/triage accepted
Code change:
return fmt.Errorf("failed to generate self-signed certificate for loopback connection: %v", err) } <ins> // Write to the front of SNICerts so that this overrides any other certs with the same name (*secureServingInfo).SNICerts = append([]dynamiccertificates.SNICertKeyContentProvider{certProvider}, (*secureServingInfo).SNICerts...) </ins> secureLoopbackClientConfig, err := (*secureServingInfo).NewLoopbackClientConfig(uuid.New().String(), certPem) switch { // if we failed and there's no fallback loopback client config, we need to fail case err != nil && *loopbackClientConfig == nil: <ins> (*secureServingInfo).SNICerts = (*secureServingInfo).SNICerts[1:] </ins> return err // if we failed, but we already have a fallback loopback client config (usually insecure), allow it

Related discussion:
text: The code block does these actions: the self-signed cert for loopback connection the loopbackClientConfig the self-signed cert to the If the main cert () is empty, the loopbackClientConfig will not be created due to this check, loopbackClientConfig shouldn't be left empty, because we have created the SNICert, it's just that we haven't executed action 3 to add the SNICert to the list. Switching the order of action 2 and action 3 will make the loopbackClientConfig successfully created. /kind bug /sig auth api-machinery
Code change:
"pod_workers_test.go", "reason_cache_test.go", "runonce_test.go", <ins> "time_cache_test.go", </ins> ], embed = [":go_default_library"], deps = [

Related discussion:
text: These tests have flaked consistently since merged: in many cases, they are the only failure in a test run: Either the functionality introduced by that PR is not reliable, or the test is faulty. /sig node /priority critical-urgent /assign
/milestone v1.19
/assign
Looks like this is failing ~5% of pull-kubernetes-node-e2e runs
FYI
Looks like there might still be a race somewhere looking at the kubelet logs Success case: Fail case:
Looking at it more, it seems like is unexpectedly empty here Success: Fail:
Stacks of interest I think we might be dealing with a stale If there is a call before the container is to the Pod in the runtime and the is called within the 2 second default cache period, it seems possible that the in the could have no containers.
what do you think of this analysis? If so, any obvious solutions occur to you?
If I'm correct, didn't introduce this; just the e2e test exposed an existing bug in the kubelet.
That all looks correct. I'm taking a look at the proposed solutions