Question: key := strings.TrimSuffix(path.Base(url), ".txt") res, found := cases[key] if found { <del> if v.ErrorExpected { </del> <ins> if v.FetcherErrorExpected { </ins> return "error", errors.New("expected error") } return res.Content, nil

<!-- 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: I was using kubeadm to generate cluster ca: The CA generation failed because of 502 bad gateway returned and the response body isn't empty when it's trying to fetch stable version from internet. In this case, the function returns error instead of falling back to local client version: is how kubeadm fetches stable version and is how the error is handled for . Should kubeadm always fall back to client version when there is any internet issue? Otherwise, this sounds defeat the purpose of fallback. /sig cluster-lifecycle What you expected to happen: kubeadm falls back to local client version when there is any internet issue. How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): 1.13.7 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:
I'd like to take this issue. It would be better if you could give some directions. /assign
recreate the issue in kubernetes/kubeadm: /close
Closing this issue. <detailsIn response to : recreate the issue in kubernetes/kubeadm: 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
the fix will be removing the when failed to and add some unit test if I don't missing anything
Got it. Thanks.


Question: # plugin by default. NETWORK_PLUGIN=${NETWORK_PLUGIN:-""} <del> # NETWORK_PLUGIN_PATH is the path to network plugin binary. NETWORK_PLUGIN_PATH=${NETWORK_PLUGIN_PATH:-""} </del> <ins> # CNI_CONF_DIR is the path to network plugin binaries. CNI_CONF_DIR=${CNI_CONF_DIR:-""} # CNI_BIN_DIR is the path to network plugin config files. CNI_BIN_DIR=${CNI_BIN_DIR:-""} </ins> # start_kubelet starts kubelet and redirect kubelet log to $LOG_DIR/kubelet.log. kubelet_log=kubelet.log

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: bare-metal OS (e.g. from /etc/os-release): Ubuntu 14.04 Kernel (e.g. ): Linux dev-k8s-controller-p1 4.4.0-53-generic ~14.04.1-Ubuntu SMP Fri Dec 2 03:43:31 UTC 2016 x8664 x8664 x86_64 GNU/Linux Install tools: chef cookbook Others: Docker 1.12.6, calico 2.1 CNI binaries: kubelet config: What happened: When trying to run pod error message is generated: So it seems that kubelet is trying to find CNI binaries in paths: /opt/loopback/bin /etc/cni/net.d /opt/calico/bin But it should look at since this is the default valur for parameter. What you expected to happen: Pod starts. How to reproduce it (as minimally and precisely as possible): Run pod: with kubelet 1.6 and CNI binaries in those path (default for calico): Anything else we need to know: After copy to and pod starts fine.
Good, very helpful to me
When set and not set , default path of CNI binaries will not take effect, the path specified by will be used instead. We should use and instead of if use CNI plugin.
I will push a PR to deprecate the flag. It is confusing. Closing this issue.
Was that ? It was closed without merging. I agree should be deprecated.
I think is needed before is removed. The flag is still not deprecated, I will send a PR to deprecate it.


Question: return nil, nil } <del> // PodToleratesNodeTaints checks if a pod tolerations can tolerate the node taints func PodToleratesNodeTaints(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) { </del> <ins> // CheckNodeUnschedulablePredicate checks if a pod can be scheduled on a node with Unschedulable spec. func CheckNodeUnschedulablePredicate(pod *v1.Pod, meta algorithm.PredicateMetadata, nodeInfo *schedulercache.NodeInfo) (bool, []algorithm.PredicateFailureReason, error) { </ins> if nodeInfo == nil || nodeInfo.Node() == nil { return false, []algorithm.PredicateFailureReason{ErrNodeUnknownCondition}, nil }

DaemonSet should not respect node's field. It's because cluster operators often want system components to be running and ready before workloads run on a given node. OTOH, DaemonSet does respect NoSchedule taints. This behavior is broken by , because DaemonSet share some predicates code with default scheduler.
/assign
Added this to 1.10 milestone, because it's a regression introduced in 1.10.
can you (or a SIG lead) add status/approved-for-milestone please? I'll add the priority. /priority important-soon
how is this use case satisfied by the daemonset controller creating pods and depending on the scheduler to assign them to nodes? having the scheduler ignore the unschedulable field seems nonsensical
I'd like get this as limitation for alpha feature; when upgrade to beta, I'd like to use taint to replace un-scheduable, so DaemonSet pod can tolerate it on-demand.
Escalating to critical-urgent, since we are now in Code Freeze. Please update daily with status, thanks! /priority critical-urgent /remove-priority important-soon
In short term, scheduler can check of pods and ignore bit of nodes for DS pods. Long term, when TaintNodesByCondition is stable, we should replace bit by taint and have DS controller add toleration for the taint when creating pods.
That doesn't seem proper. Making pods behave differently depending on the type of their creating object is very counterintuitive. That seems more reasonable. I'm less certain about auto- tolerations
- indeed there's some work currently to move from to a taint based behaviour, tracked by


Question: # $3 is the value to set the --pull flag for docker build; true by default # $4 is the set of --build-args for docker. function kube::build::docker_build() { <ins> kube::util::ensure-docker-buildx </ins> local -r image=$1 local -r context_dir=$2 local -r pull="${3:-true}"

<!-- 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 --When I ran , it failed with the following error: I expected the build to successfully complete, or to be warned that I am missing a required build dependency. If you don't have docker buildx installed, you will hit this error. However, that error is masked when you pass the full command line: Appears to have been introduced in Kubernetes version (use ): HEAD (1.22.x) Cloud provider or hardware configuration: N/A, local build OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
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 release
That's not the same as in the script, which should be setting which ungates this command. (we depended on this env for much longer in the project to use ) Stable docker versions should have buildx, at least behind this env. unfortunately the project has never validated a minimum docker version for building.
buildx as a build requirement was actually introduced at least as back as 1.21 as well, for some of the core images. we've just standardized on it more since then (including the linked commit), so if we do add some validation we should probably backport it. I think docker buildx has been available since 19.03?, but it appears your install is too old to have the flag in buildx. we could also try switching to , I'm not sure which version introduced .
No difference with the flag. But I am not running upstream Docker, I'm running Docker out of the Debian repos.
discussed on slack: seems debian packages don't have the buildx plugin , while docker-ce / docker desktop do.

we should at least be checking for the command and throwing a clear error like we do with e.g. tar.
Filed to discuss the expectation users might have re: the docker PPAs vs the Debian repos and buildx availability.
/
also
Note: reverting fixes the issue, so I have been building locally with that as a carry patch as a workaround.
cc apparently there are docker packages that don't ship this, which maybe changes the equations a bit, see above.
/assign
tl;dr from isn't actually part of moby, but Docker Inc. ships it as part of their Docker packages in their PPA. It's a separate tool with a separate code repo.
would it be eligible for another package? otherwise we probably need to provide support for installing it at least to some extent, e.g. if you are on mac with ancient bash we point to installing with homebrew in the failure message that detects this (and we should also be detecting that the command is missing).
You can build it from source and install it as a docker plugin by following the instructions at I doubt it'll be part of any of the FOSS distro repos soon (although I'm happy to be proven wrong on that).
we don't have the yard stick that something we use should be part of FOSS distro repos. Just that it needs to be easily installable.
Seems like you can also use the release artifacts from github as well, you don't need their ppa and you won't need to build it either.
Here is an image I created to solve not having buildx in the official image
/assign
has been updated to use the official binary buildx image
AL2 also does not come with buildx built in and I landed in with the same issue.


Question:
maxUnavailable

The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding up. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.

The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). Absolute number is calculated from percentage by rounding down. This can not be 0 if MaxSurge is 0. By default, a fixed value of 1 is used. Example: when this is set to 30%, the old RC can be scaled down to 70% of desired pods immediately when the rolling update starts. Once new pods are ready, old RC can be scaled down further, followed by scaling up the new RC, ensuring that the total number of pods available at all times during the update is at least 70% of desired pods.

false

string

API documentation says is rounded up, but it is actually rounded down: The code shows it is rounded down, not up: and
Yes, the documentation is obsolete. We changed maxUnavailable to round down so that we wouldn't accidentally infer 100% unavailability for non-100 percentages. For example, maxSurge=25% and maxUanavailable=25% with a Deployment of 1 replica meant that we could scale down 1 before thus leading in 100% maxUnavailable (implicit).


Question: return stdout, stderr, err } <del> // WaitForStableCluster waits until all existing pods are scheduled and returns their amount. func WaitForStableCluster(c clientset.Interface, masterNodes sets.String) int { timeout := 10 * time.Minute startTime := time.Now() allPods, err := c.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{}) ExpectNoError(err) // API server returns also Pods that succeeded. We need to filter them out. currentPods := make([]v1.Pod, 0, len(allPods.Items)) for _, pod := range allPods.Items { if pod.Status.Phase != v1.PodSucceeded && pod.Status.Phase != v1.PodFailed { currentPods = append(currentPods, pod) } } allPods.Items = currentPods scheduledPods, currentlyNotScheduledPods := e2epod.GetPodsScheduled(masterNodes, allPods) for len(currentlyNotScheduledPods) != 0 { time.Sleep(2 * time.Second) allPods, err := c.CoreV1().Pods(metav1.NamespaceAll).List(metav1.ListOptions{}) ExpectNoError(err) scheduledPods, currentlyNotScheduledPods = e2epod.GetPodsScheduled(masterNodes, allPods) if startTime.Add(timeout).Before(time.Now()) { Failf("Timed out after %v waiting for stable cluster.", timeout) break } } return len(scheduledPods) } </del> // E2ETestNodePreparer implements testutils.TestNodePreparer interface, which is used // to create/modify Nodes before running a test. type E2ETestNodePreparer struct {

What would you like to be : is used at the beginning of some e2e scheduler tests to wait until the cluster is in a stable state. It currently waits until all existing pods are scheduled, but it should also wait until pods from previous tests are actually deleted. We can do this by assuming that pods should exist only in the kube-system namespace, and so WaitForStableCluster should wait until there are no pods in any other namespace. Why is this needed: /help /sig testing /sig scheduling
/milestone v1.17 /priority critical-urgent
/cc
I'll take this one, can't figure out how to get ci bot to assign to me...
/assign
/remove-help


Question: cd ${TEMP_DIR} && sed -i.back "s|BASEIMAGE|${BASEIMAGE}|g" Dockerfile <del> docker buildx build  </del> <ins> DOCKER_CLI_EXPERIMENTAL=enabled docker buildx build  </ins> --platform linux/${ARCH}  --load  --pull

<!-- Please only use this template for submitting reports about continuously failing tests or jobs in Kubernetes CI --Which jobs are failing: Which test(s) are failing: The overall job Since when has it been failing: Sometime between Jan 29 07:00 PST (commit ) and 16:13 PST (commit ) There are some runs that could not be scheduled on a node between these two runs, so it's not clear exactly when it started failing Testgrid link: https://k8s- Reason for failure: And then it spits out all the possible Docker options and commands. Anything else we need to know: Feels like it may be related to ? -- That was merged Jan 28 though, and there were successful runs between that and this run Spyglass example for failure: Contrast with Spyglass example for last success: /sig release
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
I confirm that I hit the same issue in a CI that builds kubernetes using
is removed in docker 20.10?
Looking into this /assign xref
xref /cc
Yeah docker buildx is not initialized within this job. Like mentioned, we probably broke other CI's too. I'm wondering if a init script would help us here, but I'm just trying to find out what the technical differences between the and are.
/assign


Question: // Account for externalTrafficPolicy = "Local" if mapping.HealthCheckPort != mapping.TrafficPort { input.HealthCheckPort = aws.String(strconv.Itoa(int(mapping.HealthCheckPort))) <ins> // Local traffic should have more aggressive health checking by default. // Min allowed by NLB is 10 seconds, and 2 threshold count input.HealthCheckIntervalSeconds = aws.Int64(10) input.HealthyThresholdCount = aws.Int64(2) input.UnhealthyThresholdCount = aws.Int64(2) </ins> } result, err := c.elbv2.CreateTargetGroup(input)

What happened: A Service with and AWS NLB load balancer is very slow to recognize that a node fails health checks. I created a DaemonSet and a Service with When one of the pods is restarted, the NLB still allows traffic to it (which is dropped causing connect timeout) for a minimum of 3 * 30s with the default health check settings. What you expected to happen: Preferably, the load balancer could recognize the failed node or pod sooner. The minimum settings for NLB are documented here: Environment: Kubernetes version (use ): 1.11.7 Cloud provider or hardware configuration: AWS OS (e.g. from /etc/os-release): Debian GNU/Linux 9 (stretch) Kernel (e.g. ): 4.9.0-7-amd64 Install tools: kops 1.11.0 Others:
Reiterating the mentions to trigger a notification: <detailsIn response to : </details
I'm also curious if anyone has good recommendations for how to schedule pods with such that traffic isn't dropped. I'm thinking there could be a way using a Deployment with pod anti-affinity and rolling update params such that a new pod is brought up on each node before shutting down the old pod. If that's too complex, then I suppose a custom controller could be made for this purpose.
/assign
One solution I figured out to avoid dropping new connections during deployment updates was to setup two deployments tha can be updated in an A/B fashion. This works because the local traffic still goes through the kube-proxy so it can load balance across two pods on the same node. For a small cluster, I use a DaemonSet, but for a larger cluster, scheduling policy would need to be set such that the deployed pods end up on the same physical nodes. Then the Service's selector selects all pods from A and B, and the deploy or daemonsets have a selector for only their pods. When you need to rollout an update, you would create set B, let those pods start up fully, then you can stop set A. example of the DaemonSet's: (replace the '-a' with '-b' for the B deployment. and the Service selector is like this:
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
/remove-lifecycle stale
/sig cloud-provider
I am trying to solve the same problem using a solution along those lines. One can use pod affinity rules to ensure the new pods are scheduled on the same nodes as the old pods, and one can set the deployment strategy to surge to ensure a rolling update creates new pods before deleting old pods. The remaining piece then is to ensure the old pods are selected for deletion in the desired order (i.e., we want the scale-down of the old pods at each step to delete a pod that is on the same node as a new pod), to which end I made , which changes the ReplicaSet controller to prefer pods that are colocated with pods from a related ReplicaSet when choosing pods for deletion during scale-down. I'd appreciate any feedback on that PR.
Your solution sounds similar to the A-B strategy above except automated instead of manual. I'm wondering if it would be good to formalize the requirements a bit more, e.g. adding some specific metadata or option to Deployments to provide this kind of A/B strategy when replacing existing pods. Or maybe it can be done within affinity, or pdb's and the scheduler such that if a node already has a healthy pod, it must maintain at least one healthy pod on that node unless a full drain is started. Another thought I had about this is what if the kube-proxy's health check for that service would start returning failed before the last pod on a node is completely drained such that leftover traffic can still get handled for some amount of time before killing the pod? Edit: one issue I can think of with the solution you have (actually, would be problem for any A/B on the same node) is it makes re-balancing a cluster harder. E.g. if you want a rolling update to schedule to lightly loaded nodes first.
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
/remove-lifecycle stale


Question: func (f mutateObjectUpdateFunc) Admit(a admission.Attributes, o admission.ObjectInterfaces) (err error) { return f(a.GetObject(), a.GetOldObject()) } <ins> func TestTransformDecodeErrorEnsuresBadRequestError(t *testing.T) { testCases := []struct { name             string typer            runtime.ObjectTyper decodedGVK       *schema.GroupVersionKind decodeIntoObject runtime.Object baseErr          error expectedErr      error }{ { name:  "decoding normal objects fails and returns a bad-request error", typer: clientgoscheme.Scheme, decodedGVK: &schema.GroupVersionKind{ Group:   testapigroupv1.GroupName, Version: "v1", Kind:    "Carp", }, decodeIntoObject: &testapigroupv1.Carp{}, // which client-go's scheme doesn't recognize baseErr:          fmt.Errorf("plain error"), }, { name:             "decoding objects with unknown GVK fails and returns a bad-request error", typer:            alwaysErrorTyper{}, decodedGVK:       nil, decodeIntoObject: &testapigroupv1.Carp{}, // which client-go's scheme doesn't recognize baseErr:          nil, }, } for _, testCase := range testCases { err := transformDecodeError(testCase.typer, testCase.baseErr, testCase.decodeIntoObject, testCase.decodedGVK, []byte(``)) if apiStatus, ok := err.(apierrors.APIStatus); !ok || apiStatus.Status().Code != http.StatusBadRequest { t.Errorf("expected bad request error but got: %v", err) } } } var _ runtime.ObjectTyper = alwaysErrorTyper{} type alwaysErrorTyper struct{} func (alwaysErrorTyper) ObjectKinds(runtime.Object) ([]schema.GroupVersionKind, bool, error) { return nil, false, fmt.Errorf("always error") } func (alwaysErrorTyper) Recognizes(gvk schema.GroupVersionKind) bool { return false } </ins>

What happened: POST or PUT to a custom resource with a JSON body missing "kind" results in a 500 error: A missing "apiVersion" also results in a 500 error: Then with both "kind" and "apiVersion" defined we get the normal 4XX return codes. What you expected to happen: All bad inputs for create and update requests should be 4XX return codes. E.g. Creating a with body of results in the 422 error: How to reproduce it: Create a CRD or use a cluster that already has a one prepared (GKE 1.11.0+ clusters have the CRD installed which you could test against). HTTP to that custom resource with a JSON body of . E.g. Environment: Kubernetes version (use ): 1.11.2 Cloud provider or hardware configuration: GKE OS (e.g. from /etc/os-release): Kernel (e.g. ): /sig api-machinery <!-- DO NOT EDIT BELOW THIS LINE --/kind bug
This is fixed on master, but I can reproduce it on 1.11. Posting a custom resource with a JSON body of : on master: on 1.11:
we are transforming all non-status error into 500 status error. in this case, it's the decoder returning a which is non-status. a quick fix by . (i like this number)
instead of fixed, it's rather been shadowed by i suppose. now when that empty unstructured obj going thru the decoder, the gvk is explicitly coerced, so this case is not reproducable on master for now.
/cc
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 .

/lifecycle rotten
I get the same response when trying to update the custom resource's 'status' sub-resource. On k8s v1.11.4
/assign
submitting the specified object on master returns a 400 badrequest, as desired /close
Closing this issue. <detailsIn response to : submitting the specified object on master returns a 400 badrequest, as desired 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


Question: var _ http.Handler = hcHandler{} func (h hcHandler) ServeHTTP(resp http.ResponseWriter, req *http.Request) { <del> h.hcs.lock.Lock() </del> <ins> h.hcs.lock.RLock() </ins> svc, ok := h.hcs.services[h.name] if !ok || svc == nil { <del> h.hcs.lock.Unlock() </del> <ins> h.hcs.lock.RUnlock() </ins> klog.Errorf("Received request for closed healthcheck %q", h.name.String()) return } count := svc.endpoints <del> h.hcs.lock.Unlock() </del> <ins> h.hcs.lock.RUnlock() </ins> resp.Header().Set("Content-Type", "application/json") if count == 0 {

What would you like to be : Use read lock in ServeHTTP Why is this needed: Currently ServeHTTP (in ) takes the write lock: Since it only reads from h.hcs.services, holding read lock should suffice.
cc
/sig network
ping
looks good to me. Thanks!
Can you give /lgtm ?
ping


Question: "k8s.io/kubernetes/pkg/client/restclient" "k8s.io/kubernetes/pkg/client/unversioned/remotecommand" cmdutil "k8s.io/kubernetes/pkg/kubectl/cmd/util" <ins> "k8s.io/kubernetes/pkg/kubectl/resource" </ins> remotecommandserver "k8s.io/kubernetes/pkg/kubelet/server/remotecommand" "k8s.io/kubernetes/pkg/util/interrupt" "k8s.io/kubernetes/pkg/util/term"

I feel like I should be able to do: but I get
or we have to do something like this: sounds reasonable to me. needs more comments.
All commands that accept resources should accept resource/NAME syntax. In this case for back compat we must only accept a single argument, is familiar with this.
Exactly. ResourceNames in the resource builder is what is needed here to handle the default resource (pod in this case) and provide the ability to specify more.
Related
If nobody is working on it, I'd like to pick the issue, pls.
I don't think anyone is. , Illia Khudoshyn wrote:
So could you please assign me?
I can't assign to just anyone, unfortunately, but by responding here, anyone else who might work on it will see that you are already in progress. , Illia Khudoshyn wrote:
please go ahead, you did own this now. :)
Has this been reverted again? I cannot use “pod/podname” for v1.11:
^ Seconding the above. I'm getting the same 'may not contain /' error. Naturally it's trivial to use unix commands to filter this, but this is such a basic feature and matches the way the rest of kubectl works, so it's quite a shocking omission.
as a unix novice who's also experiencing this problem, I'd love to know your workaround
If you use selectors, you can do something like this: Otherwise you'll need to manually grep, something like this: is the syntax in bash to run the command and use its output as part of another command. You can also use backticks to achieve the same effect but that's considered bad form by many (myself included). For example: If going the grep route, take care to make sure your regex will only return one result, otherwise you'll have to pipe it to xargs or something similar.
Just ran into this on a brand new default installation. Local Mac Docker for Desktop Enabled k8 in preferences error: invalid resource name "svc/broken-gorilla-postgresql": [may not contain '/']
FWIW you can use combined with the flag, e.g.
Had the same problem. Updating kubectl resolved the issue for me.


Question: } allErrs = append(allErrs, validateIngress(ingress, opts)...) annotationVal, annotationIsSet := ingress.Annotations[annotationIngressClass] <del> if annotationIsSet && ingress.Spec.IngressClassName != nil { </del> <ins> if annotationIsSet && ingress.Spec.IngressClassName != nil && annotationVal != *ingress.Spec.IngressClassName { </ins> annotationPath := field.NewPath("annotations").Child(annotationIngressClass) <del> allErrs = append(allErrs, field.Invalid(annotationPath, annotationVal, "can not be set when the class field is also set")) </del> <ins> allErrs = append(allErrs, field.Invalid(annotationPath, annotationVal, "must match `ingressClassName` when both are specified")) </ins> } return allErrs }

An ingress resource with both annotation and set cannot be created. Ingress resources can be updated to include both the annotation and the without issue. Kubernetes response: The ingress should be deployed with both annotation and set, as it is supported by updating an existing ingress. Apply this resource: The code causing this issue is here: <details</details<details</details<detailsLinux, Mac, mulitple OSs with the same issue. It's caused by code as linked above </details<details</details<details</details<details</details
/sig network
that code referenced is only used on Create update has a different path is this based on an observation of the code or are you hitting this problem?
, correct. This only happens on create. Our work around now is to create an ingress resource with the annotation, and then update the resource, adding the . This involves 2 MRs and approval processes We are hitting this problem regularly as we scale out the number of kubernetes clusters we operate, and create new ingress resources. It's quite painful as we're starting to use , but cannot drop the ingressClass annotation yet as some third party services have not ported over to use the .
but why do you create it with the annotaiton?
Sorry, I don't understand your question. I need to be able to create an ingress resource with both the ingressClass annotation () and both set
yeah, that is my question, if you are creating the ingress with v1 you don't need the annotation, it was deprecated by the field, the annotation has to be there for the people that upgrades from v1beta1 to v1
As far as I know, External DNS still requires the annotation. We use external DNS, and thus cannot drop the annotation yet
I think what you're doing as a workaround is a valid approach . A better fix would be for the ingress controller you're using to migrate to properly use the v1 API for Ingress and IngressClass. Please consider filing a bug against that ingress controller or other component. We could also return a header when someone sets the annotation on an Ingress that already has set, to make it clear that this is not recommended.
It seems that PR got stuck , but is not a kubernets bug
IMO we should probably not hard-fail if these are both set, but a warning would be appropriate.

, i'd completely agree. Kubernetes is happy to have both set side by side, but the logic linked in the first comment blocks it. Seemingly needlessly.
Discussed at sig-net. We don't object to loosening this rule - an API warning seems sufficient. PRs welcome /triage accepted
Hi , I'm willing to help with this issue. I'm not familiar with , I read the relevant code and I think it seems that to add an API warning, I just need to implement for in . Am I right? And in the same time, don't check these two fields in validation?
Pretty much! See how Service works (though you probably don't need to put it into a different package, not sure why we did that..) kidddddddddddddddddddddd <
/assign


Question: <ins> /* 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 vsphere_volume import ( "fmt" "path" "path/filepath" "strings" "github.com/golang/glog" "k8s.io/api/core/v1" "k8s.io/apimachinery/pkg/types" "k8s.io/kubernetes/pkg/util/mount" kstrings "k8s.io/kubernetes/pkg/util/strings" "k8s.io/kubernetes/pkg/volume" "k8s.io/kubernetes/pkg/volume/util" "k8s.io/kubernetes/pkg/volume/util/volumepathhandler" ) var _ volume.BlockVolumePlugin = &vsphereVolumePlugin{} func (plugin *vsphereVolumePlugin) ConstructBlockVolumeSpec(podUID types.UID, volumeName, mapPath string) (*volume.Spec, error) { pluginDir := plugin.host.GetPluginDir(plugin.GetPluginName()) blkUtil := volumepathhandler.NewBlockVolumePathHandler() globalMapPathUUID, err := blkUtil.FindGlobalMapPathUUIDFromPod(pluginDir, mapPath, podUID) if err != nil { glog.Errorf("Failed to find GlobalMapPathUUID from Pod: %s with error: %+v", podUID, err) return nil, err } glog.V(5).Infof("globalMapPathUUID: %v", globalMapPathUUID) globalMapPath := filepath.Dir(globalMapPathUUID) if len(globalMapPath) <= 1 { return nil, fmt.Errorf("failed to get volume plugin information from globalMapPathUUID: %v", globalMapPathUUID) } return getVolumeSpecFromGlobalMapPath(globalMapPath) } func getVolumeSpecFromGlobalMapPath(globalMapPath string) (*volume.Spec, error) { // Construct volume spec from globalMapPath // globalMapPath example: //   plugins/kubernetes.io/{PluginName}/{DefaultKubeletVolumeDevicesDirName}/{volumeID} //   plugins/kubernetes.io/vsphere-volume/volumeDevices/[datastore1]040volumes/myDisk volPath := filepath.Base(globalMapPath) volPath = strings.Replace(volPath, "040", "", -1) if len(volPath) <= 1 { return nil, fmt.Errorf("failed to get volume path from global path=%s", globalMapPath) } block := v1.PersistentVolumeBlock vsphereVolume := &v1.PersistentVolume{ Spec: v1.PersistentVolumeSpec{ PersistentVolumeSource: v1.PersistentVolumeSource{ VsphereVolume: &v1.VsphereVirtualDiskVolumeSource{ VolumePath: volPath, }, }, VolumeMode: &block, }, } return volume.NewSpecFromPersistentVolume(vsphereVolume, true), nil } func (plugin *vsphereVolumePlugin) NewBlockVolumeMapper(spec *volume.Spec, pod *v1.Pod, _ volume.VolumeOptions) (volume.BlockVolumeMapper, error) { // If this called via GenerateUnmapDeviceFunc(), pod is nil. // Pass empty string as dummy uid since uid isn't used in the case. var uid types.UID if pod != nil { uid = pod.UID } return plugin.newBlockVolumeMapperInternal(spec, uid, &VsphereDiskUtil{}, plugin.host.GetMounter(plugin.GetPluginName())) } func (plugin *vsphereVolumePlugin) newBlockVolumeMapperInternal(spec *volume.Spec, podUID types.UID, manager vdManager, mounter mount.Interface) (volume.BlockVolumeMapper, error) { volumeSource, _, err := getVolumeSource(spec) if err != nil { glog.Errorf("Failed to get Volume source from volume Spec: %+v with error: %+v", *spec, err) return nil, err } volPath := volumeSource.VolumePath return &vsphereBlockVolumeMapper{ vsphereVolume: &vsphereVolume{ volName:         spec.Name(), podUID:          podUID, volPath:         volPath, manager:         manager, mounter:         mounter, plugin:          plugin, MetricsProvider: volume.NewMetricsStatFS(getPath(podUID, spec.Name(), plugin.host)), }, }, nil } func (plugin *vsphereVolumePlugin) NewBlockVolumeUnmapper(volName string, podUID types.UID) (volume.BlockVolumeUnmapper, error) { return plugin.newUnmapperInternal(volName, podUID, &VsphereDiskUtil{}) } func (plugin *vsphereVolumePlugin) newUnmapperInternal(volName string, podUID types.UID, manager vdManager) (volume.BlockVolumeUnmapper, error) { return &vsphereBlockVolumeUnmapper{ vsphereVolume: &vsphereVolume{ volName: volName, podUID:  podUID, volPath: volName, manager: manager, plugin:  plugin, }, }, nil } var _ volume.BlockVolumeMapper = &vsphereBlockVolumeMapper{} type vsphereBlockVolumeMapper struct { *vsphereVolume } func (v vsphereBlockVolumeMapper) SetUpDevice() (string, error) { return "", nil } func (v vsphereBlockVolumeMapper) MapDevice(devicePath, globalMapPath, volumeMapPath, volumeMapName string, podUID types.UID) error { return util.MapBlockVolume(devicePath, globalMapPath, volumeMapPath, volumeMapName, podUID) } var _ volume.BlockVolumeUnmapper = &vsphereBlockVolumeUnmapper{} type vsphereBlockVolumeUnmapper struct { *vsphereVolume } func (v *vsphereBlockVolumeUnmapper) TearDownDevice(mapPath, devicePath string) error { return nil } // GetGlobalMapPath returns global map path and error // path: plugins/kubernetes.io/{PluginName}/volumeDevices/volumePath func (v *vsphereVolume) GetGlobalMapPath(spec *volume.Spec) (string, error) { volumeSource, _, err := getVolumeSource(spec) if err != nil { return "", err } return path.Join(v.plugin.host.GetVolumeDevicePluginDir(vsphereVolumePluginName), string(volumeSource.VolumePath)), nil } func (v *vsphereVolume) GetPodDeviceMapPath() (string, string) { return v.plugin.host.GetPodVolumeDeviceDir(v.podUID, kstrings.EscapeQualifiedNameForDisk(vsphereVolumePluginName)), v.volName } </ins>

FEATURE REQUEST: vSphere volume plugin does not support volume device yet. Need to add volumeMode in PV spec as other plugin did. release 1.12
/sig storage


Question: #    shasum <tar> # 6. Update this file with new tar version and new hash <del> {% set etcd_version="v0.4.6" %} </del> <ins> {% set etcd_version="v2.0.0" %} </ins> {% set etcd_tar_url="https://storage.googleapis.com/kubernetes-release/etcd/etcd-%s-linux-amd64.tar.gz" | format(etcd_version)  %} <del> {% set etcd_tar_hash="sha1=5db514e30b9f340eda00671230d5136855ae14d7" %} </del> <ins> {% set etcd_tar_hash="sha1=b3cd41d1748bf882a58a98c9585fd5849b943811" %} </ins> etcd-tar: archive:

writes: As we start looking into etcd and event memory pressure [], we should look into switching over to etcd 2.0 which was released today.
cc/
+1 On Jan 28, 2015 5:29 PM, "Dawn Chen" wrote:
My long-running cluster tests resulted in a hard-crash on etcd: We should move to 2.0 ASAP in the hopes of (a) fixing the issue and if not (b) prioritizing the fix since we'll be complaining about head. Abhi, is this something you can pick up and drive to land in O(days) please?
Calling this P0 as it blocks further long-running cluster stability testing.
I will do this today. , Alex Mohr wrote:


Question: // The number of old ReplicaSets to retain to allow rollback. // This is a pointer to distinguish between explicit zero and not specified. <del> // Defaults to 2. </del> <ins> // Defaults to 10. </ins> // +optional optional int32 revisionHistoryLimit = 6;

All controllers that use the field have a default value of 10 for the field, except for , which has a default of 2. We should increase it to 10 for consistency on its default value across controllers. /sig apps


Question: // Add the volumes to ASW rc.updateStates(reconstructedVolumes) <del> // The reconstructed volumes are mounted, hence a previous kubelet must have already put it into node.status.volumesInUse. // Remember to update DSW with this information. rc.volumesNeedReportedInUse = reconstructedVolumeNames </del> // Remember to update devicePath from node.status.volumesAttached rc.volumesNeedUpdateFromNodeStatus = reconstructedVolumeNames }

remove and was introduced in to fix This is to overcome the situation that volume is to DSW at first and then deleted before it is to ASW, which causes mounted volume neither in DSW nor ASW and won't execute unmount/detach: The reason the volume cannot be to ASW in time is , which is . However, there is another PR also solved the issue. What it did is to check whether ASW already has the volume before deleting it from DSW, this makes sure that volume can be detached/unmounted after it is deleted from DSW. I suggest that we can keep the second solution and remove related code to make the reconstruction process and reconcile loop cleaner?
/sig storage
cc
Should I proceed with this issue? Your guidance is appreciated.
I think we'd better wait for the feedback from
cc
Sorry for a late reply. This is how behind we are with reviews :-(. Reading Now that is on by default, it reconstructs volumes first and always puts them to ASW, it should never happen that a reconstructed volume is in DSW and not in ASW, right? So we can remove easily. I would not be so sure without , because the code is 5 years old and who knows all the implications. You could be right though, it may not be necessary there too.
/triage accepted
/assign


Question: return nil } <ins> // nolint:errcheck   // Ignore the error returned by Register as before </ins> var registry = func() Registry { r := make(Registry) r.Register(scoreWithNormalizePlugin1, newScoreWithNormalizePlugin1) r.Register(scoreWithNormalizePlugin2, newScoreWithNormalizePlugin2) r.Register(scorePlugin1, newScorePlugin1) <ins> r.Register(scorePlugin2, newScorePlugin2) </ins> r.Register(pluginNotImplementingScore, newPluginNotImplementingScore) r.Register(duplicatePluginName, newDuplicatePlugin) r.Register(testPlugin, newTestPlugin)

Scheduler's default plugin returns an invalid score that is not in the range of [0, 100], resulting in no Pods being scheduled: After investigation, I found that there was a bug in the code that built the framework when the scheduler started. When using the plugins declared in the regular extension point to override the plugins declared in the MultiPoint, the traversed variable will be modified in the following loop: This may cause a same scoring plugin (e.g. ) to be loaded multiple times: Further, this results in a node being processed multiple times by a plugin's (e.g. 's) method, resulting in an invalid score that is not in the range of [0, 100]: If the scheduler's MultiPoint feature is used (either through the default plugins or through manual configuration), and the configuration (e.g. the scoring weight) of a certain plugin is overridden in a regular extension point, the plugin will only be loaded once in this extension point, and no illegal scores will be returned. An example KubeSchedulerConfiguration: No response K8s v1.24.15 or higher None <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
/sig scheduling
Can I work on this?
this is being worked on. see
I see, Is there any other task that you are aware of and I can work on? Thanks.


Question: <del> /* Copyright 2014 Google Inc. 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 e2e import ( "github.com/GoogleCloudPlatform/kubernetes/pkg/client" "github.com/golang/glog" . "github.com/onsi/ginkgo" . "github.com/onsi/gomega" ) // TestImportantURLs validates that URLs that people depend on haven't moved. // ***IMPORTANT*** Do *not* fix this test just by changing the path.  If you moved a URL // you can break upstream dependencies. func TestImportantURLs(c *client.Client) bool { tests := []struct { path string }{ {path: "/validate"}, {path: "/healthz"}, // TODO: test proxy links here } ok := true for _, test := range tests { glog.Infof("testing: %s", test.path) data, err := c.RESTClient.Get(). AbsPath(test.path). Do(). Raw() if err != nil { glog.Errorf("Failed: %vnBody: %s", err, string(data)) ok = false } } return ok } var _ = Describe("TestImportantURLs", func() { It("should pass", func() { // TODO: Instead of OrDie, client should Fail the test if there's a problem. // In general tests should Fail() instead of glog.Fatalf(). Expect(TestImportantURLs(loadClientOrDie())).To(BeTrue()) }) }) </del>

Create a ginkgo networking test suite and add the following tests to it: TestNetwork TestImportantURLs
Part of the ginkgo-ization of the e2e tests


Question: runcmd: - modprobe configs <del> - docker run -v /dev:/dev -v /home/kubernetes/bin/nvidia:/rootfs/nvidia -v /etc/os-release:/rootfs/etc/os-release -v /proc/sysrq-trigger:/sysrq -e LAKITU_KERNEL_SHA1=26481563cb3788ad254c2bf2126b843c161c7e48 -e BASE_DIR=/rootfs/nvidia --privileged gcr.io/google_containers/cos-nvidia-driver-install@sha256:ad83ede6e0c6d768bf7cf69a7dec972aa5e8f88778142ca46afd3286ad58cfc8 </del> <ins> - docker run -v /dev:/dev -v /home/kubernetes/bin/nvidia:/rootfs/nvidia -v /etc/os-release:/rootfs/etc/os-release -v /proc/sysrq-trigger:/sysrq -e BASE_DIR=/rootfs/nvidia --privileged gcr.io/google_containers/cos-nvidia-driver-install@sha256:cb55c7971c337fece62f2bfe858662522a01e43ac9984a2dd1dd5c71487d225c </ins> - mount /tmp /tmp -o remount,exec,suid - usermod -a -G docker jenkins - mkdir -p /var/lib/kubelet

xref: /sig node /area test
I am working on this.
Can you update this with the types of tests that you are adding? Is this similar to ?
No, this is for running the existing GPU e2e tests on GKE which are currently running on only GCE.
The referenced PRs appear to have merged, closing.


Question: framework.ExpectNoError(err, "while getting node status") ginkgo.By("Verifying that the node now supports huge pages with size 3Mi") <del> gomega.Expect(node.Status.Capacity).To(gomega.HaveKeyWithValue("hugepages-3Mi", resource.MustParse("9Mi")), "capacity should contain resource hugepages-3Mi and huge pages with size 3Mi should be supported") </del> <ins> value, ok := node.Status.Capacity["hugepages-3Mi"] if !ok { framework.Failf("capacity should contain resource hugepages-3Mi: %v", node.Status.Capacity) } gomega.Expect(value.String()).To(gomega.Equal("9Mi"), "huge pages with size 3Mi should be supported") </ins> ginkgo.By("restarting the node and verifying that huge pages with size 3Mi are not supported") restartKubelet(true)

The Huge pages test in both containerd/cri is consistently failing. Not sure. No response There was a deprecation for ExpectEqual merged about a week ago on this same line. maybe you could take a look and see why this check is failing? modified this line /sig node
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


Question: } dialOptions = append(dialOptions, grpc.WithContextDialer(dialer)) } cfg := clientv3.Config{ DialTimeout:          dialTimeout, DialKeepAliveTime:    keepaliveTime,

The project uses a lot of CRDs - in some cases almost 2,000. I do mean here, not custom resources. We've noticed that API server memory consumption balloons when many CRDs are installed - for example with ~1,900 CRDs we see the API server using up to ~8Gi RSS. A little profiling shows that around 1.5Gi of that memory is being used by the etcd3 client's logger. With Kubernetes built from with the CRDs at loaded I'm seeing the API server using up to ~7.5GiB RSS. I see it dip to ~5.5GiB, presumably when garbage collection runs. You can see taking up a ton of memory below. Zap is the logger used by the etcd client. Note that this is a sample, so it's actually using more than the indicated ~800MiB. ! I'm seeing the API server using up to ~6GiB RSS. I see it dip to ~4.5GiB, presumably due to GC runs. You can see no longer appears below. ! I would not expect a logger to be responsible for such a significant amount of the API server's memory consumption. You can get the above profile by: out . to build a kind node. to start a control plane for the above build. to allow anonymous pprof access the CRDs from I used to see the RSS but I imagine would show it too. See for details on how I disabled the logger to get the "without logger" numbers. No response <details</details<detailsN/A </details<details</details<details</details<details</details<details</details
/sig api-machinery
Since you looked at the code, and I'd rather not spend time doing that. Any chance you can tell if it's because it's being mis-used?
This is a scale dimension where the apiserver has historically . With the OpenAPI discovery performance being improved it looks like this might be a hint at what the next bottleneck might be? Any idea how many etcd clients were instantiated? I suspect it's quite a lot.
Sadly I didn't yet look deeply past turning it off. I was slightly optimistic that we might just be able to disable it without any meaningful impact.

What I do know is that the offending code seems to be on the etcd3 client end - i.e. it defaults to creating its own logger when one isn't supplied. You can see that code at
I don't - will try to find out.
The zap logs might tell you if you have the data. If my memory of the code is right, you should get 1 etcd client per CRD right now (plus some for builtin types).
/triage accepted
Based on my read of the code, you're right. I see roughly: All of /apis is handled by a crdHandler When a request comes in it gets an instance of the crd (from an informer) Gets serving info from a map of CRDs - if there is none it... Calls customresource.NewStorage which creates a genericregistry.Store Calls its CompleteWithOptions method That calls its “Decorator”, which is a genericregistry.StorageWithCacher That calls generic.NewRawStorage which just wraps factory.Create factory.Create calls newETCD3Storage which calls newETCD3Client I'm experiencing technical difficulties getting lsof running in my kind container but /proc/pid/net confirms we have a connection to etcd per CRD: Note that 1,937 - 60 = 1,877 - the number of CRDs we have loaded (the 1,878 above includes the header line).


Question: kubeletconfig "k8s.io/kubernetes/pkg/kubelet/apis/config" ) <del> const defaultHost = "http://127.0.0.1:8080" </del> <ins> const ( defaultHost = "http://127.0.0.1:8080" // DefaultNumNodes is the number of nodes. If not specified, then number of nodes is auto-detected DefaultNumNodes = -1 ) </ins> // TestContextType contains test settings and global state. Due to // historic reasons, it is a mixture of items managed by the test

A) seems to be required by some tests. we need to decide if jobs need to pass explicitly or let the e2e framework detect how many worker nodes a cluster has. the conformance image has no notion of yet. B) the conformance image runs tests even in parallel mode: if "y" is set in the YAML for if we assume that tests should not run in parallel mode, this means we need to pass from the runner. C) should we switch the conformance image to ? currently it's . we need to check if this breaks anything. discussion: /area test /kind design /kind bug /assign
/sig testing
PRs - disable Parallel mode for conformance image (and test):
RE: the introduction of ` in this test broke not only the kubeadm tests but also the conformance image and sonobuoy. previously they did not require and we are now forced to detect the number of nodes outside of the e2e testing framework. possibly this test was the first conformance test that uses as a aggressive failure condition. there are two options here: A) adapt all prow jobs, conformance image and sonobuoy, etc to explicitly pass . this ensures that future test will rely on the number the user provides and expects. we already started going this route by providing mechanics for detecting schedulable nodes, per-solution. B) auto-detect "ready", schedulable nodes in the e2e framework as a start number before, say a daemon set test runs and compare outcomes. this way a test will run on whatever number of nodes are currently available. cc
/area conformance /milestone v1.14
Line should be a explicit failure, not a
i like option B!
related to
Note that this test was NOT new, the other bug is ignoring skipped conformance tests. Ideally that shouldn't be possible.
/assign
GitHub didn't allow me to assign the following users: johnSchnake, stevesloka. Note that only and repo collaborators can be assigned and that issues/PRs can only have 10 assignees at the same time. For more information please see <detailsIn response to : /assign 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'm reluctant to make a sweeping change for 1.14 other then a band aide inside of test-infra. Ideally I'd like to assign this issue to the test-commons group to solve in 1.15. Thoughts?
Agree that (A) (passing num-nodes explicitly) isnt a good option since it breaks other users who dont know about it in the first place and that this is well within the capabilities of the framework. So for option (B) during startup of the framework we need to grab the nodes and count the number that are schedulable and not tainted as master nodes, correct? Save that into a TestContext variable and then reference it elsewhere as needed? Is the plan to reuse the existing value? I'm not at this time familiar with that value and whether it is needed in some other capacity and shouldn't be auto-set. w.r.t. 1.14 vs 1.15; I don't have too strong a preference. I do generally prefer to let things bake a little longer inside of a release but it seems like if just the node count solves the problem its a small, scoped change that could make it in.
From slack: If num-nodes is not specified query on startup and over-ride the test context variable.
a control plane node can be tainted as "master", but still allow workloads. search for on all nodes, and exclude those that have it from the count. this is fed the flag, which is -1 by default. if the user didn't add a value my suggestion is to just update with the detected count. also possibly add notes about that in the flag description. future tests might decide to use this again (we already have some) and it will break if the user doesn't pass a valid number from the CLI flag. the "auto-detect if -1" logic seems reasonable and backwards compatible. how well our detection will work in complicated taint / toleration scenarios is another question. "Code Thaw" starts on the 19th of march. if we merge a change in master before that the change will also be picked by 1.14. if we patch this later the change has to be cherry picked for 1.14.


Question: kubernetes.io/os: linux containers: - name: metrics-server <del> image: k8s.gcr.io/metrics-server/metrics-server:v0.5.0 </del> <ins> image: k8s.gcr.io/metrics-server/metrics-server:v0.5.1 </ins> command: - /metrics-server - --metric-resolution=30s

<!-- 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 --As described in issue , we found kubernetes have been running normally, but the control-plane nodes's metrics value of startTime is similar to the timestamp. Get the correct metrics of node As described in issue anything else we need to provide? As described in issue 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:
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 node
/remove-sig node /sig instrumentation /assign
I think the issue is about Summary API having start time for node metric, but this timestamp is incorrect. This is node issue, not instrumentation. /sig node /remove-sig instrumentation /unassign
When discussing adding node start time metric to /metrics/resource endpoint I remember that SIG Node response to this was that there is no good way to define node start time. I don't think we will be able to provide correct value here. As summary API is technically deprecated, it makes no sense to fix it. We should warn users against using it and wait for removal of Summary API.
Okay, let's wait for the release of metrics-server v0.6.0
Do you know if this is fixed in metrics server?
/triage needs-information Can you please add info on name of timeserias and other steps to repro ti understand exactly what is needed here. Thank you!

in metrics server v0.6.0, we will use /metrics/resource Kubelet endpoint instead summary API
as issue described , the result is: for example : the startup time of the node test-us-west-1-control-plane-577lp is "startTime": "2021-08-03T19:33:50Z",, and timestamp reported by metrics is "2021-08-03T19:34:36Z", but as described, output from control plane node


Question: apps "k8s.io/api/apps/v1" metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" "k8s.io/apimachinery/pkg/util/intstr" <ins> "k8s.io/apimachinery/pkg/util/sets" </ins> "k8s.io/client-go/informers" "k8s.io/client-go/kubernetes/fake" testclient "k8s.io/client-go/testing"

<!-- 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: when deployment controller cleans up old ReplicaSet, it sorts all old ReplicaSets by createTimeStamp and delete the oldest one, which may cause Deployment roll back to a wrong version. How to reproduce it (as minimally and precisely as possible): Suppose we set the revisionHistoryLimit of a Deployment to 3, and currently we have 3 Replicas: r1, r2, r3 (the createTimeStamp and Revision both are r3 r2 r1); if we upgrade and roll back 3 times continuously, there will be an expected case: upgrade:   ReplicaSet will be: r4, r3, r2   createTimeStamp: r4 r3 r2   reversion: r4 r3 r2 rollback: should rollback to v3   ReplicaSet will be: r4, r3, r2   createTimeStamp: r4 r3 r2   reversion: r3 r4 r2 upgrade:   ReplicaSet will be: r5, r4, r3   createTimeStamp: r5 r4 r3   reversion: r5 r3 r4 rollback: should rollback to v3   ReplicaSet will be: r4, r3, r2   createTimeStamp: r5 r4 r3   reversion: r3 r5 r4 upgrade:   ReplicaSet will be: r6, r5, r4   createTimeStamp: r6 r5 r4   reversion: r6 r5 r4 rollback: should rollback to r3, but instead, we rollbacked to r5, and this may cause error. What you expected to happen: when deployment controller cleans up old ReplicaSet, it should sort old ReplicaSets by Revision
/sig api-machinery /sig apps
does this make sense to you? /assign /cc
?
/remove-sig api-machinery
This requirement makes sense. Unassign API machinery - SIG Apps should own this.
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 . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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
/reopen
Reopened this issue. <detailsIn response to : /reopen 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
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
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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


Question: s := &http.Server{ Addr:           net.JoinHostPort(address.String(), strconv.FormatUint(uint64(port), 10)), Handler:        &handler, <del> ReadTimeout:    5 * time.Minute, WriteTimeout:   5 * time.Minute, </del> MaxHeaderBytes: 1 << 20, } if tlsOptions != nil {

I noticed that if I'm following a pod log that is being actively written to it will timeout after 5 minutes. However if the pod is not writing logs the request will not timeout. In that case the request will remain open seemingly indefinitely. I can change the behavior by modifying this line of code: To make it happen faster you can set the value lower. I've been testing with 1 minute. Steps to reproduce: cluster the nginx pod in another terminal generate log output by hitting the pod: (you'll need to change the ip). the logs: In this case whenever the WriteTimeout is reached curl will receive the zero sized chunk and the connection will be closed. If you leave out step 3 curl will continue seemingly indefinitely. This behavior definitely seems odd. Is the usage of WriteTimeout correct here? A quick search shows that others have been confused by the intention of WriteTimeout which is why I ask.
is this same as ?
From discussions on the OpenShift side it sounds somewhat related however what we're talking about is a reasonable (but arbitrary) timeout set. Users of are subjected to this timeout with no good way to pick up where they left off to avoid redownloading potentially large quantities of logs.
To me, it would make sense if the api endpoint had argument which would fetch logs from line (it's easy to track on client on which line we're at), exactly what does: I'm assuming that kubelet gets logs using docker api, unfortunately there is no such thing in docker's api:
I think users that want to do this should get the logs from elastic search instead of from kubectl.
I can't say I disagree about needing something like elastic search in a real world deployment. I guess part of the weirdness is that clients of the logging API rarely know how much is going to be pulled down before they make the request. I guess the answer now if you're following the logs is "5 minutes worth". I know this isn't how it's implemented today but in my mind following the logs should behave more like or . Meaning, when you state you want to follow you don't fetch the entire log file you just get wherever it happens to be (and maybe a little more for context). If you want the whole file you don't pass in .
Any update? This is really annoying and I'm thinking of patching my k8s.

I think the default API timeout has been lengthened to 60 minutes Defined: Used for API server: It looks like the kubelet timeout is still 5 minutes, so that would gate log streaming to 5 minutes:
More nuances in Looks like the API http server times out after 60 minutes: Watches time out between 5 and 10 minutes: Kubelet http server still times out after 5 minutes
Which means that getting logs timeouts after 5 minutes?
yeah
did intentionally leave the kubelet timeout at 5 minutes, or should it be using the same ReadWriteTimeout as the api server?
nm, just merged the pr. did intentionally leave the kubelet timeout at 5 minutes, or should it be using the same ReadWriteTimeout as the api server?
we could easily bump up the kubelet timeout. The handlers on the kubelet don't have their own built in timeouts (like I did for watch), so a potential downside is long hanging /stats requests could hog connections, and depending on why they're hanging, continue consuming kubelet/cpu/cadvisor time. had a suggestion previously about using elasticsearch, are you running with a cluster that doesn't have the addons (, if you set it up with kube-up it should)?
IMO there's no reason not to make kubelet server's timeout really long, at least for these requests.
I'm trying to put in a fix to increase the kubelet timeouts to 1 hour to match the master. Unfortunately adding proper timeout handling for these cases may not make 1.0, but hopefully this can make it less annoying.


Question: // 1. One or more of the provided EndpointSlices have older generations than the //    corresponding tracked ones. // 2. The tracker is expecting one or more of the provided EndpointSlices to be <del> //    deleted. </del> <ins> //    deleted. (EndpointSlices that have already been marked for deletion are ignored here.) </ins> // 3. The tracker is tracking EndpointSlices that have not been provided. func (est *EndpointSliceTracker) StaleSlices(service *v1.Service, endpointSlices []*discovery.EndpointSlice) bool { est.lock.Lock()

As discussed in , Endpoint(Slice) controllers can get stuck if an Endpoints or EndpointSlice resource is stuck in a terminating state. I don't think there's much we can do for Endpoints here since the same name is reused, but EndpointSlice controllers can ignore EndpointSlices in a terminating state. See No response All supported versions Any Any Any Any Any
/sig network
/triage accepted
deleting a service with a finalizer doesn't affect the endpointslice, it doesn't change its status to termination or unready Repro: finalizer to the service and delete it, it keeps waiting until the finalizer is removed with the deletion timestamp set. the endpoint slice associated Do you mean that when the endpoint slice controller detects that the Service is being deleted should switch the endpoint slice status to Terminating? cc:
I don't think we need to do anything special if the Service is waiting to be deleted. There are many legitimate reasons for this to happen, including waiting for infrastructure to be removed. My main concern with a finalizer was that one on an EndpointSlice could cause the controller to get stuck on a Service. We don't have the same risk with a finalizer on a Service - I don't think that would cause the controller to get stuck in any way.
i was unable to repro the issue on my machine: I was monitoring the logs of , and the endpointslice controller never complained about , when I deleted the service. Though, I was able to get the controller to log this error under a different scenario. If we don't explicitly remove the finalizer from the endpointslice, and instead re-create the pod and service like: From what I can understand, because the endpointslice with the finalizer is owned by a service with a different UID than the new endpointslice, it is marked as expected for deletion . The endpointslice controllers calls , which returns true for the endpointslice with the finalizer, because of the above reason. I might be wrong anywhere here, so please let me know if that is the case. As for further action, I'm not sure what can be done here? We could check the endpointslice for finalizers and then skip them . Keen to hear your thoughts about this.


Question: "github.com/GoogleCloudPlatform/kubernetes/pkg/labels" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry/minion" "github.com/GoogleCloudPlatform/kubernetes/pkg/registry/registrytest" <del> "github.com/GoogleCloudPlatform/kubernetes/pkg/util" </del> ) func TestServiceRegistryCreate(t *testing.T) {

We have seen that on VirtualBox in particular kubelet picks first interfaces, which is usually NATed and is of no use. In particular the issue comes up with service IP, which gets mapped to endpoint on the NATed interface.
If this is still a problem, can you explain more - I don't quite understand - and suggest heuristics for better solutions?
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. 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


Question: } return persistentvolumes, nil } <ins> func CreatePVSource(zone string) (*v1.PersistentVolumeSource, error) { diskName, err := CreatePDWithRetryAndZone(zone) if err != nil { return nil, err } if TestContext.Provider == "gce" || TestContext.Provider == "gke" { return &v1.PersistentVolumeSource{ GCEPersistentDisk: &v1.GCEPersistentDiskVolumeSource{ PDName:   diskName, FSType:   "ext3", ReadOnly: false, }, }, nil } else if TestContext.Provider == "aws" { return &v1.PersistentVolumeSource{ AWSElasticBlockStore: &v1.AWSElasticBlockStoreVolumeSource{ VolumeID: diskName, FSType:   "ext3", }, }, nil } else { return nil, fmt.Errorf("Provider not supported") } } func DeletePVSource(pvSource *v1.PersistentVolumeSource) error { if TestContext.Provider == "gce" || TestContext.Provider == "gke" { return DeletePDWithRetry(pvSource.GCEPersistentDisk.PDName) } else if TestContext.Provider == "aws" { return DeletePDWithRetry(pvSource.AWSElasticBlockStore.VolumeID) } else { return fmt.Errorf("Provider not supported") } } </ins>

For statically created PVs, the persistent volume label admission controller adds the zone label to the PV object. If the admission controller is not enabled or has some bugs, then an e2e test would be helpful for catching these errors. /assign
There are no sig labels on this issue. Please by:<br(1) mentioning a sig: <br(2) specifying the label manually: <br<brNote: method (1) will trigger a notification to the team. You can find the team list and label list


Question: } } <ins> // doFixDeprecatedTaintKeyPass checks and replaces deprecated taint key with proper key name if needed. func (nc *Controller) doFixDeprecatedTaintKeyPass(node *v1.Node) error { taintsToAdd := []*v1.Taint{} taintsToDel := []*v1.Taint{} for _, taint := range node.Spec.Taints { if taint.Key == algorithm.DeprecatedTaintNodeNotReady { // delete old taint tDel := taint taintsToDel = append(taintsToDel, &tDel) // add right taint tAdd := taint tAdd.Key = algorithm.TaintNodeNotReady taintsToAdd = append(taintsToAdd, &tAdd) glog.Warningf("Detected deprecated taint key: %v on node: %v, will substitute it with %v", algorithm.DeprecatedTaintNodeNotReady, node.GetName(), algorithm.TaintNodeNotReady) break } } if len(taintsToAdd) == 0 && len(taintsToDel) == 0 { return nil } if !util.SwapNodeControllerTaint(nc.kubeClient, taintsToAdd, taintsToDel, node) { return fmt.Errorf("failed to swap taints of node %+v", node) } return nil } </ins> func (nc *Controller) doNoScheduleTaintingPass(node *v1.Node) error { // Map node's condition to Taints. taints := []v1.Taint{}

Almost all style strings use dashes, rather than javascript names. vs .
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
Thanks for notification, a quick fix is submitted.
/cc
The PR here isn't merged yet. Can we make that happen please? We're still in alpha, so should be ok
Should I add the v1.8 milestone to this issue?
Hope so. We are pending in , need approve from
I opened with safe changes. "not-ready" change needs to be discussed more, as it's a breaking change. I believe it's best with fixing that to the time we'll be moving to beta, as we'll need to do another breaking change, i.e. remove 'alpha' from the key.
Aren't we doing this at the 11th hour? Is this going to hit 1.8?
Strings like this that are part of the core API should be part of a design doc that is formally reviewed by an API group. We need to find ways to catch this stuff earlier. We should also have an evolving API style guide that lists stuff like this. /cc
Thanks , let me make some summary: quick fix for 1.8 is , will be merged soon. final fix is , we are collaborating to reach a final solution and it's not target 1.8
Agree with Joe, can someone open a PR to that documents that taint names should follow the naming conventions for annotations?


Question: // ListRoutes in the cloud environment. func (g *Cloud) ListRoutes(ctx context.Context, clusterName string) ([]*cloudprovider.Route, error) { <del> timeoutCtx, cancel := cloud.ContextWithCallTimeout() </del> <ins> timeoutCtx, cancel := context.WithTimeout(ctx, 1*time.Hour) </ins> defer cancel() mc := newRoutesMetricContext("list")

What happened: Ref , there are some GCE wrapper functions that don't properly respect the passed in context, e.g: We need to figure out a better way to handle this, but I'm hesitate to change it right away without enough thinking. File this issue for tracking purpose. cc
/sig cloud-provider /area provider/gcp
How about checking the deadline of the passed in ctx: If the timeout is longer than what cloud.ContextWithCallTimeout expects, create context with 1 hour timeout.
We should consider () as well as deadline. How about monitor user's timeout like this? cancel our context when timeout.
If the time period till ctx.Deadline() is shorter than 1 hour, there is no need to call cloud.ContextWithCallTimeout(). We can use ctx directly in that case.
Another option may be better:
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


Question: // Returns the name of the VM on which this code is running. // Prerequisite: this code assumes VMWare vmtools or open-vm-tools to be installed in the VM. <ins> // Will attempt to determine the machine's name via it's UUID in this precedence order, failing if neither have a UUID: // * cloud config value VMUUID // * sysfs entry </ins> func getVMName(client *govmomi.Client, cfg *VSphereConfig) (string, error) { <del> addrs, err := net.InterfaceAddrs() if err != nil { return "", err </del> <ins> var vmUUID string if cfg.Global.VMUUID != "" { vmUUID = cfg.Global.VMUUID } else { // This needs root privileges on the host, and will fail otherwise. vmUUIDbytes, err := ioutil.ReadFile("/sys/devices/virtual/dmi/id/product_uuid") if err != nil { return "", err } vmUUID = string(vmUUIDbytes) cfg.Global.VMUUID = vmUUID </ins> } <del> if len(addrs) == 0 { return "", fmt.Errorf("unable to retrieve Instance ID") </del> <ins> if vmUUID == "" { return "", fmt.Errorf("unable to determine machine ID from cloud configuration or sysfs") </ins> } // Create context

What keywords did you search in Kubernetes issues before filing this one?: VMware, vSphere, IP, UUID BUG REPORT. Kubernetes version: Environment: Cloud provider or hardware configuration: VMware vSphere 6.5.0 OS : Debian GNU/Linux 8.7 (jessie) Kernel : Install tools: Kargo What happened: Some containers were launched on a node with a name containing the hostname of a different node and the does not retrieve the right node name : Here is retrieved instead of . When using the VSphere Cloud provider, the node name is retrieved from the function in Since this PR (), the node data are retrieved based on the IP address instead of the UUID. The function gets all the IP address and check if one of the IP on any interface matches a VM on vSphere. The problem is that the docker0 interface has the same IP on all the nodes (usually 172.17.0.1) and this IP is referenced into VMware. As this IP may be the first to appear in the it will match the first VM that vSphere gives with the function and this can be any VM running Docker on vSphere. Thus, the provider has a big chance to not get the informations for the VM it is running on, leading to an inconsistent state in the cluster (wrong pod name for example). Anything else we need to know: An idea would be to first retrieve the VM name with the function and if no results use the IP address (and add an exclusion to not use the interface). What do you think ? If you think this might be the right way to do, we can try to propose the PR. Thanks for your feedback.
Wow, this very much is a bad, bad bug. It was introduced by one of my colleagues here at HPE. It's made worse if you run multiple Kubernetes clusters in the same vSphere Datacenter. I'll send a PR upstream tomorrow to resolve this. I think it's best to go back to using dmidecode, but maybe someone from VMware ( or ?) has another suggestion? This would still require root access, but I can't think of a better way to get the machine's ID.
Related issue Will dig in more. For now instead of making it a value determined runtime the deployment framework should have root privileges and can populate it as part of the cloud config post VM creation.
is my colleague.

A little more info and a few ideas. I would also support going back to ` (still requires root though). We could also have the following logic: Get UUID and use it to get the VM Name with FindByUUID if possible, If not, get the hostname and use FindByDNSName, If still nothing is found, keep the current logic, excluding docker0 from the interfaces we examine. However, I agree with that getting this from the cloud config may be the best and most reliable solution.
I'm working on a patch right now that will do the following: Add a VMUUID field to the cloud config If VMUUID is not set, will use Error out if neither one is available
PR is - if someone would like to review :)


Question: description: "cpu manager add - container update error", regErr:      nil, updateErr:   fmt.Errorf("fake update error"), <del> expErr:      fmt.Errorf("fake update error"), </del> <ins> expErr:      nil, </ins> }, }

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: There will always be extra UpdateContainerResources CRI call even when cpu set is empty. This is unneeded. What you expected to happen: Only call UpdateContainerResources when cpu set is set. 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:
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 node


Question: svctest.SetNodePorts(30118, 0)), // set [0] to HCNP's value, omit [1] expectError: true, }, <ins> }, { name: "update-hcnp", create: svcTestCase{ svc: svctest.MakeService("foo", svctest.SetTypeLoadBalancer, svctest.SetExternalTrafficPolicy(api.ServiceExternalTrafficPolicyTypeLocal), svctest.SetPorts( svctest.MakeServicePort("p", 867, intstr.FromInt(867), api.ProtocolTCP), svctest.MakeServicePort("q", 5309, intstr.FromInt(5309), api.ProtocolTCP)), svctest.SetNodePorts(30093, 30076), svctest.SetHealthCheckNodePort(30118)), expectClusterIPs:          true, expectNodePorts:           true, expectHealthCheckNodePort: true, }, update: svcTestCase{ svc: svctest.MakeService("foo", svctest.SetTypeLoadBalancer, svctest.SetExternalTrafficPolicy(api.ServiceExternalTrafficPolicyTypeLocal), svctest.SetPorts( svctest.MakeServicePort("p", 867, intstr.FromInt(867), api.ProtocolTCP), svctest.MakeServicePort("q", 5309, intstr.FromInt(5309), api.ProtocolTCP)), svctest.SetNodePorts(30093, 30076), svctest.SetHealthCheckNodePort(30111)), expectError: true, }, </ins> }} helpTestCreateUpdateDelete(t, testCases)

We are currently using v1.19 and it seems that if you have a service with set to then changing the health check node port is not supported. One way to get around this is by changing the to and then changing it back to in addition to specifying the with the desired port number. This behavior is not very well documented and the below error message is not very useful: I wonder if we could also add another case below to release the current health check port and allow changing it to the user specified value given it's valid? It's possible that after creating a someone wants to change it to a user-provided and the current way to do it is only by toggling the . This feature with the documentation would be more straightforward way to make any port changes.
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 network
19 is EOL, last supported version is 1.22 It seems the message has changed since then, this area had important changes in latest releases that improved the API behavior However, the field still can not be updated once set, what you do switching the is wiping the value and reallocating it. It is a documentation problem then
IMO, the amount of effort it would take to make this mutable is not justified when there is a workaround. Convince me the workaround doesn't work? Overall HCNP is a buried implementation detail.
I can't speak much to the amount of effort, but I can speak a bit to the value: a user, I don't expect healthcheckNodePort to be immutable. I'm not sure if my mental model is too simplistic, but it feels like a part of the configuration I control, and I can change NodePorts, so why not the healthcheckNodePort. the work around isn't necessarily obvious. It also takes experimenting with to know that it'll even work. this in a production environment is not trivial.

If changing the healthcheckNodePort was supported then you could change the config to the state you want it to be, and your rollout orchestration tooling goes and applies it to your collection of k8s clusters. With the work around you now have to have a 2 step process. After step 1 of this process your service is using a traffic policy which might break your application (say you depend on client ip). So to avoid the downtime you'd have to build some reasonably off-pattern orchestration that doesn't just apply the configuration from the commit you used for your release, but instead two commits, or two configs, etc. Operationally this isn't actually that cheap to build, especially as this is likely to be a one-off operation and not something you do every release. Not exactly the same thing, but related to healthcheckNodePort, I've also found that specifying it explicitly vs not explicitly in the config, and switching between the two modes, has unexpected behavior as well. If you started out as having it specified, applying a config with it unspecified tries to allocate a new value, and complains that it can't change healthcheckNodePort for traffic policy local. Why not just use the already allocated value? Going from unallocated to specifying it explicitly at the same value seems to works fine.
The latter issue should be fixed in recent releases - what version are you seeing that on? I understand it would be more consistent to be mutable but there are real downstream implications to changing it, code complexity, test complexity, etc, and I don't understand why you want to change it in the first place. Humans should not be paying attention to that field. It should not even be in spec, but for historical reasons.
Same version as original post, v1.19. Glad to hear that issue is fixed in later versions! We're making steady progress updating, but not all caught up yet. I don't want to insist on this fix, as I said I'm not aware of the fix complexity and leave it up to you guys to balance that out, just wanted to provide the value perspective. As for not being exposed to users at all, I think we'd probably have been better off if we never knew about it.

Unfortunately our original configs had it explicitly set, eventually ran into conflicts in various k8s clusters and tried to transition to having it be unspecified, and thus ran into the above situation.
Yeah, there's really no good reason to set it, pretty much ever, and lots of reasons not to. I will cross-check that it is fixed if I get a moment tomorrow.
It has been fixed by you Tim
I thought so, I just wanted to triple check :)


Question: <ins> # See the OWNERS docs at https://go.k8s.io/owners reviewers: - dep-reviewers - pacoxu - gautierdelorme approvers: - dep-approvers - pacoxu </ins>

Add a file to track dependencies we want to remove or avoid picking back up. Examples: (as opposed to ) {analysis,spec,strfmt,validate} () and () () Add a presubmit that uses to do the following: if any items in the "unwanted but still present" list are no longer present and prompts to move them to the "absent and not allowed" list if any items in the "absent and not allowed" list are present and fails. Dependency updates often reintroduce problematic dependencies that were previously dropped. /area code-organization /cc
/sig architecture /triage accepted /help
This request has been marked as needing help from a contributor. 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 : /sig architecture /triage accepted /help 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 may help with it. /assign I checked the code, there is already a logic to check forbidden dependencies. can draw a go mod graph
yeah, that was sort of ad-hoc, and doesn't do the ratcheting bit we want (record a dependency we have but don't want, once we no longer use it, require moving it to the forbidden list)


Question: function verify-prereqs { for x in gcloud gcutil gsutil; do if [ "$(which $x)" == "" ]; then <del> echo "Can't find $x in PATH, please fix and retry." </del> <ins> echo "Can't find $x in PATH, please fix and retry." 1>&2 </ins> exit 1 fi done

I'm following the documentation on this doc: Everything works until this command: I get this error consistently from different VMs (a Debian and a CoreOS). Maybe I have to edit /etc/hosts to add the "external-ip" with the public IP of some server? Docs don't seem clear. Thanks, Riccardo
Its failing to look up your master correctly. You can try setting KUBERNETES_MASTER=http://<your IP hearBrendan On Sep 21, 2014 5:45 AM, "Riccardo Carlesso" wrote:


Question: defaultGVK := scope.Kind original := r.New() trace.Step("About to convert to expected version") <del> obj, gvk, err := scope.Serializer.DecoderToVersion(s.Serializer, defaultGVK.GroupVersion()).Decode(body, &defaultGVK, original) </del> <ins> decoder := scope.Serializer.DecoderToVersion(s.Serializer, schema.GroupVersion{Group: defaultGVK.Group, Version: runtime.APIVersionInternal}) obj, gvk, err := decoder.Decode(body, &defaultGVK, original) </ins> if err != nil { err = transformDecodeError(typer, err, original, gvk, body) scope.err(err, w, req)

The API server converts objects to internal versions for processing by admission plugins and rest handlers. RawExtension fields are converted correctly during create requests, but are left in external versions when handling update requests. This means that admission plugins and rest handlers expecting internal versions will fail


Question: <ins> /* 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 mount import ( "fmt" "os" "k8s.io/klog" ) // CleanupMountPoint unmounts the given path and // deletes the remaining directory if successful. // if extensiveMountPointCheck is true // IsNotMountPoint will be called instead of IsLikelyNotMountPoint. // IsNotMountPoint is more expensive but properly handles bind mounts within the same fs. func CleanupMountPoint(mountPath string, mounter Interface, extensiveMountPointCheck bool) error { // mounter.ExistsPath cannot be used because for containerized kubelet, we need to check // the path in the kubelet container, not on the host. pathExists, pathErr := PathExists(mountPath) if !pathExists { klog.Warningf("Warning: Unmount skipped because path does not exist: %v", mountPath) return nil } corruptedMnt := IsCorruptedMnt(pathErr) if pathErr != nil && !corruptedMnt { return fmt.Errorf("Error checking path: %v", pathErr) } return doCleanupMountPoint(mountPath, mounter, extensiveMountPointCheck, corruptedMnt) } // doCleanupMountPoint unmounts the given path and // deletes the remaining directory if successful. // if extensiveMountPointCheck is true // IsNotMountPoint will be called instead of IsLikelyNotMountPoint. // IsNotMountPoint is more expensive but properly handles bind mounts within the same fs. // if corruptedMnt is true, it means that the mountPath is a corrupted mountpoint, and the mount point check // will be skipped func doCleanupMountPoint(mountPath string, mounter Interface, extensiveMountPointCheck bool, corruptedMnt bool) error { if !corruptedMnt { var notMnt bool var err error if extensiveMountPointCheck { notMnt, err = mounter.IsNotMountPoint(mountPath) } else { notMnt, err = mounter.IsLikelyNotMountPoint(mountPath) } if err != nil { return err } if notMnt { klog.Warningf("Warning: %q is not a mountpoint, deleting", mountPath) return os.Remove(mountPath) } } // Unmount the mount path klog.V(4).Infof("%q is a mountpoint, unmounting", mountPath) if err := mounter.Unmount(mountPath); err != nil { return err } notMnt, mntErr := mounter.IsLikelyNotMountPoint(mountPath) if mntErr != nil { return mntErr } if notMnt { klog.V(4).Infof("%q is unmounted, deleting the directory", mountPath) return os.Remove(mountPath) } return fmt.Errorf("Failed to unmount path %v", mountPath) } // TODO: clean this up to use pkg/util/file/FileExists // PathExists returns true if the specified path exists. func PathExists(path string) (bool, error) { _, err := os.Stat(path) if err == nil { return true, nil } else if os.IsNotExist(err) { return false, nil } else if IsCorruptedMnt(err) { return true, err } else { return false, err } } </ins>

<!-- 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: pod with smb(cifs) mount could not be terminated on Windows when that smb account is invalid, the pod will be stuck forever What you expected to happen: How to reproduce it (as minimally and precisely as possible): a pod with azure file mount on Windows the storage account of azure file invalid the pod with azure file mount could not be terminated forever Anything else we need to know?: similar to case: Environment: Kubernetes version (use ): v1.12.6 Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Others: /assign /sig windows


Question: <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 { lc := config.GetLinux() if lc == nil { return nil } // Apply security context. if err := applySandboxSecurityContext(lc, createConfig.Config, hc, ds.network, separator); err != nil { return err } // Set sysctls. hc.Sysctls = lc.Sysctls return nil } </del>

<!-- 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


Question: } By("Creating the Google Device Plugin pod for NVIDIA GPU in GKE") <del> devicePluginPod = f.PodClient().CreateSync(framework.NVIDIADevicePlugin(f.Namespace.Name)) </del> <ins> devicePluginPod, err = f.ClientSet.CoreV1().Pods(metav1.NamespaceSystem).Create(framework.NVIDIADevicePlugin()) framework.ExpectNoError(err) </ins> By("Waiting for GPUs to become available on the local node") Eventually(func() bool {

https://k8s- The following tests are broken: NVIDIA GPU Device Plugin PriorityLocalStorageEvictionOrdering PriorityMemoryEvictionOrdering Looks like some new validation was to prevent two things: PodPriority directly system-critical priority classes outside of the kube-system namespace. To fix this, we need to create new priority classes for these tests. cc /kind failing-test /sig node /sig scheduling /priority important-soon
/kind bug
/assign
This doesn't appear to have fixed the tests. Tests now panic during the Aftereach in which the PriorityClass is deleted. /reopen
Panic:
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 . /lifecycle rotten
Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . Send feedback to sig-testing, kubernetes/test-infra and/or . /close
Closing this issue. <detailsIn response to : Rotten issues close after 30d of inactivity. Reopen the issue with . Mark the issue as fresh with . /close 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


Question: "//pkg/runtime:go_default_library", "//pkg/util/errors:go_default_library", "//pkg/util/strategicpatch:go_default_library", <ins> "//pkg/util/validation:go_default_library", </ins> "//vendor:github.com/spf13/cobra", ], )

Is this a BUG REPORT or FEATURE REQUEST? (choose one):BUG REPORT Kubernetes version (use ):Client Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"6+", GitVersion:"v1.6.0-alpha.0.2610+-dirty", GitCommit:"", GitTreeState:"dirty", BuildDate:"2016-12-29T06:28:44Z", GoVersion:"go1.7.1", Compiler:"gc", Platform:"linux/amd64"} What happened:
Could someone from please help with triage. Thanks!
There is already a PR on the way.