[08:22:21] Found where the missing link was, "in Netbox, set the server's BGP custom field to True". This is not yet set to true. All other steps are done, do we still need to run homer after this? Following the guide on https://wikitech.wikimedia.org/wiki/Kubernetes/Clusters/Add_or_remove_nodes#Step_1:_Add_node_to_BGP [08:23:52] cc akosiaris jayme --^ [09:56:18] <_joe_> I would assume it's safer to re-run homer, it should be idempotent if no changes are there [10:03:47] stevemunene: yes, otherwise the switches and routers won't know to BGP peer with the nodes [12:57:09] do we have a metric indicating how much time a pod took before actually starting? I'd like to capture the time it takes to mount volumes, setup the sandbox, network, etc. Thanks! [12:58:20] ah, `kube_pod_start_time` sounds promising [12:58:57] ah, no, it seems to be some kind of start_time - epoch [14:24:02] no, I don't think so. We have some information at the node level about how much these types of operations take (e.g. run_podsandbox at https://grafana.wikimedia.org/d/000000472/kubernetes-kubelets?orgId=1&from=now-1h&to=now&timezone=utc&var-cluster=000000017&viewPanel=panel-17) but they are not per pod, just aggregates. There is some information at [14:24:03] the pod level encoded in e.g. kube_pod_status_ready_time and kube_pod_status_initialized_time. Substracting them tells you some info about how much time passed before the pod is ready, but this isn't what you want. [14:25:00] The poor man's approach, if you are debugging something specific, might be to empty a node, assign the pod you care for on that node and look at the aggregate statistics the kubelet keeps, knowing your sample size is (almost) 1.