jiebi/CodeConvo huggingface dataset:
Code change:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.

Related discussion:
text: // addTokenSecretReference adds a reference to the ServiceAccountToken that will be created func addTokenSecretReference(refs []v1.ObjectReference) []v1.ObjectReference { <del> return addNamedTokenSecretReference(refs, "default-token-p7w9c") </del> <ins> return addNamedTokenSecretReference(refs, "default-token-stdpg") </ins> } // addNamedTokenSecretReference adds a reference to the named ServiceAccountToken
Code change:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.

Related discussion:
text: } // createdTokenSecret returns the ServiceAccountToken secret posted when creating a new token secret. <del> // Named "default-token-p7w9c", since that is the first generated name after rand.Seed(1) </del> <ins> // Named "default-token-stdpg", since that is the first generated name after rand.Seed(1) </ins> func createdTokenSecret(overrideName ...string) *v1.Secret { <del> return namedCreatedTokenSecret("default-token-p7w9c") </del> <ins> return namedCreatedTokenSecret("default-token-stdpg") </ins> } // namedTokenSecret returns the ServiceAccountToken secret posted when creating a new token secret with the given name.
Code change:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.

Related discussion:
text: // Attempt 2 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-x50vb")), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-jk9rt")), </ins> // Attempt 3 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-scq98")), core.NewUpdateAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, serviceAccount(addNamedTokenSecretReference(emptySecretReferences(), "default-token-scq98"))), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-684pg")), core.NewUpdateAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, serviceAccount(addNamedTokenSecretReference(emptySecretReferences(), "default-token-684pg"))), </ins> }, }, "new serviceaccount with no secrets encountering unending create error": {
Code change:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.

Related discussion:
text: core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, createdTokenSecret()), // Retry 1 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-x50vb")), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-jk9rt")), </ins> // Retry 2 core.NewGetAction(schema.GroupVersionResource{Version: "v1", Resource: "serviceaccounts"}, metav1.NamespaceDefault, "default"), <del> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-scq98")), </del> <ins> core.NewCreateAction(schema.GroupVersionResource{Version: "v1", Resource: "secrets"}, metav1.NamespaceDefault, namedCreatedTokenSecret("default-token-684pg")), </ins> }, }, "new serviceaccount with missing secrets": {
Code change:
/kind feature What happened: In playing with the nginx ingress controller deployment, I noticed the following pod name: nginx-ingress-controller--c0ck5 I figure we should possibly put something in place to prevent accidental l33t profanity ;-). What you expected to happen: The following pod name: nginx-ingress-controller--r0ck5
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
My first github (k8s) issue. I've no idea which SIG would cover this topic. /sig product-management
/sig api-machinery
Previously we removed vowels in . We can 3xt3nd the idea with 0, 1 (can stand for ) and 3. would you like to send a PR? If not, I can work on this.
/assign jamesawebb1
Reassign to me if you do not want to contribute a PR.

Related discussion:
text: // We omit vowels from the set of available characters to reduce the chances // of "bad words" being formed. <del> var alphanums = []rune("bcdfghjklmnpqrstvwxz0123456789") </del> <ins> var alphanums = []rune("bcdfghjklmnpqrstvwxz2456789") </ins> // String generates a random alphanumeric string, without vowels, which is n // characters long.  This will panic if n is less than zero.
Code change:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.

Related discussion:
text: responses: 200: body: <del> application/json: example: !include examples/pod-list.json </del> <ins> example: !include examples/pod-list.json </ins> post: description: Create a new pod. currentState is ignored if present. body: <del> json/application: schema: !include doc/pod-schema.json example: !include examples/pod.json </del> <ins> schema: !include doc/pod-schema.json example: !include examples/pod.json </ins> /{podId}: get:
Code change:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.

Related discussion:
text: responses: 200: body: <del> application/json: example: !include examples/pod.json </del> <ins> example: !include examples/pod.json </ins> put: description: Update a pod body: <del> json/application: schema: !include doc/pod-schema.json example: !include examples/pod.json </del> <ins> schema: !include doc/pod-schema.json example: !include examples/pod.json </ins> delete: description: Delete a specific pod responses: 200: body: <del> application/json: example: | { "success": true } </del> <ins> example: | { "success": true } </ins> /replicationControllers: get:
Code change:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.

Related discussion:
text: responses: 200: body: <del> application/json: example: !include examples/controller-list.json </del> <ins> example: !include examples/controller-list.json </ins> post: description: Create a new controller. currentState is ignored if present. body: <del> json/application: schema: !include doc/controller-schema.json example: !include examples/controller.json </del> <ins> schema: !include doc/controller-schema.json example: !include examples/controller.json </ins> /{controllerId}: get:
Code change:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.

Related discussion:
text: responses: 200: body: <del> application/json: example: !include examples/controller.json </del> <ins> example: !include examples/controller.json </ins> put: description: Update a controller body: <del> json/application: schema: !include doc/controller-schema.json example: !include examples/controller.json </del> <ins> schema: !include doc/controller-schema.json example: !include examples/controller.json </ins> delete: description: Delete a specific controller responses: 200: body: <del> application/json: example: | { "success": true } </del> <ins> example: | { "success": true } </ins> /services: get:
Code change:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.

Related discussion:
text: responses: 200: body: <del> application/json: example: !include examples/service-list.json </del> <ins> example: !include examples/service-list.json </ins> post: description: Create a new service body: <del> json/application: schema: !include doc/service-schema.json example: !include examples/service.json </del> <ins> schema: !include doc/service-schema.json example: !include examples/service.json </ins> /{serviceId}: get:
Code change:
Starting a large data set (32gb allocated, 4gb resident) in the api server causes about 7.5gb allocations of . The tree for that shows: This appears to be due to openapi aggregation. If there is an easy fix in 1.7 it might be worth it. Otherwise this should be addressed for 1.8.
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
This is all API server startup - for small clusters it's about 20-60% of startup time
Most of those are that is the library we used to convert our spec to proto. The key is this line: Do you have any idea how we can get a better space time/complexity here?
I have a PR for that now.
Fixed in
Even without aggregation, starting and serving OpenAPI docs was a huge chunk of startup time. The linked change makes it disappear.
This should not be related to aggregation at all (as far as I can tell from that tree). Thanks for the fix
Thanks, it's in gnostic master now.

Related discussion:
text: responses: 200: body: <del> application/json: example: !include examples/service.json </del> <ins> example: !include examples/service.json </ins> put: description: Update a service body: <del> json/application: schema: !include doc/service-schema.json example: !include examples/service.json </del> <ins> schema: !include doc/service-schema.json example: !include examples/service.json </ins> delete: description: Delete a specific service responses: 200: body: <del> application/json: example: | { "success": true } </del> <ins> example: | { "success": true } </ins>
Code change:
Both https://k8s- and https://k8s- started failing recently. Their 1.7 counterparts are passing. The difference between the last passing and the first failing tests is: Probably something in broke the tests. /sig scheduling /cc /kind bug
It looks like there isn't enough cpu on the master to run the cos-nvidia-installer daemonset. Did we add any addons recently?
My previous comment is a red herring. It is an issue with . Ill post a fix soon. From the scheduler logs on the master:
that's a benign error. The daemonset is not expected to run on the master. But there is no easy way to express that request in our APIs.
Yes, the pod not scheduling on the master is benign. The actual error is that we do not report node condition , so it is left as . The fix is to report that is false.
The tests are still failing. /reopen
/assign
I will be updating to track progress.
tests are green again! /close

Related discussion:
text: } } <ins> // Set OODCondition for the node. func (kl *Kubelet) setNodeOODCondition(node *v1.Node) { currentTime := metav1.NewTime(kl.clock.Now()) var nodeOODCondition *v1.NodeCondition // Check if NodeOutOfDisk condition already exists and if it does, just pick it up for update. for i := range node.Status.Conditions { if node.Status.Conditions[i].Type == v1.NodeOutOfDisk { nodeOODCondition = &node.Status.Conditions[i] } } newOODCondition := nodeOODCondition == nil if newOODCondition || nodeOODCondition.Status == v1.ConditionUnknown { nodeOODCondition = &v1.NodeCondition{ Type:               v1.NodeOutOfDisk, Status:             v1.ConditionFalse, Reason:             "KubeletHasSufficientDisk", Message:            "kubelet has sufficient disk space available", LastTransitionTime: currentTime, } } // Update the heartbeat time irrespective of all the conditions. nodeOODCondition.LastHeartbeatTime = currentTime if newOODCondition { node.Status.Conditions = append(node.Status.Conditions, *nodeOODCondition) } } </ins> // Maintains Node.Spec.Unschedulable value from previous run of tryUpdateNodeStatus() // TODO: why is this a package var? var oldNodeUnschedulable bool
Code change:
Both https://k8s- and https://k8s- started failing recently. Their 1.7 counterparts are passing. The difference between the last passing and the first failing tests is: Probably something in broke the tests. /sig scheduling /cc /kind bug
It looks like there isn't enough cpu on the master to run the cos-nvidia-installer daemonset. Did we add any addons recently?
My previous comment is a red herring. It is an issue with . Ill post a fix soon. From the scheduler logs on the master:
that's a benign error. The daemonset is not expected to run on the master. But there is no easy way to express that request in our APIs.
Yes, the pod not scheduling on the master is benign. The actual error is that we do not report node condition , so it is left as . The fix is to report that is false.
The tests are still failing. /reopen
/assign
I will be updating to track progress.
tests are green again! /close

Related discussion:
text: return []func(*v1.Node) error{ kl.setNodeAddress, withoutError(kl.setNodeStatusInfo), <ins> withoutError(kl.setNodeOODCondition), </ins> withoutError(kl.setNodeMemoryPressureCondition), withoutError(kl.setNodeDiskPressureCondition), withoutError(kl.setNodeReadyCondition),