Add gitlab:elastic:ifo output to kubesos
In gitlab-org/gitlab!91243 (merged) we're going to introduce a new rake task called gitlab:elastic:info. This is being introduced to gitlabsos via gitlabsos#59 (closed).
Per slack discussion (internal link): GitlabSOS is for omnibus instances, while KubeSOS has a similar purpose for Cloudnative GitLab so this rake task should be added in KubeSOS as well
/cc @cleveland @vstoianovici @dgruzd
Designs
Relates to
- gitlabsos #59
Activity
marked this issue as related to gitlabsos#59 (closed)
mentioned in merge request gitlab-org/gitlab!91243 (merged)
added groupglobal search label
I can see the value in this but KubeSOS is a kubectl and helm wrapper and is not integrated with GitLab itself. For example it can be run against the runner chart and it will still work. But the runner chart has no toolbox pod nor ability to run rake commands. You could actually run it against any cluster even one unrelated to GitLab because it queries via helm and the kube-api.
We could execute commands on the task-runner pod if it exists, but the code would become complicated and messy and likely unsuitable for bash.
Also Advanced Search is an optional feature, there are many rake tasks (do we add all of them?) and rake tasks are slow which is at odds with this as a lightweight, fast-to-run and easy to audit script.
Also Advanced Search is an optional feature, there are many rake tasks (do we add all of them?) and rake tasks are slow which is at odds with this as a lightweight, fast-to-run and easy to audit script.
@amulvany I suggested adding it to GitLabSOS because it's helpful to have this information when support engineers are working with cases about Advanced Search. They often use GitLabSOS to pull logs that we look at and having this rake task would save a few back and forth communication.
KubeSOS seems like a harder one to solve for due to the issues you outlined. Is it better to ask for the rake task output manually when support cases come in for self managed running Advanced Search on k8s?
I tend to agree with @amulvany. Whilst it would be fairly trivial to include logic to determine what is 'possible' to capture, KubeSOS needs to be kept as a generic first pass tool.
However, if there is 'stuff' that GitLabSOS captures in a first pass that KubeSOS doesn't then it does feel that K8s installations are somewhat disadvantaged in terms of triage.
Do we need a K8s version of GitLabSOS? Otherwise we have to ask customers to manually execute those bits that KubeSOS doesn't capture.
-
Do we need a K8s version of GitLabSOS? Otherwise we have to ask customers to manually execute those bits that KubeSOS doesn't capture.
I thought KubeSOS was was the k8s version of GitLabSOS but this discussion helped me realize the tool is for quick capture of k8s configuration settings and logs.
I think it's a great idea to have a k8s version of GitLabSOS that does exactly what it does. Perhaps GitLabSOS could be modified to have a flag to run against k8s installations?
-
Having looked at GitLabSOS there's only a couple of commands that could be common.
GitLabSOS captures more around the OS and traditional log files etc. that don't really make sense in a K8s deployment, so probably best to keep them separate. I thought there was a lot more GitLab specific in GitLabSOS that could be considered for KubeSOS but seems not.
mentioned in issue #20