Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add per-unit resource usage to pod status replies #58

Merged
merged 4 commits into from
Jun 13, 2019

Conversation

ldx
Copy link
Contributor

@ldx ldx commented Jun 11, 2019

No description provided.

@ldx ldx requested a review from justnoise June 11, 2019 18:36
Copy link
Contributor

@justnoise justnoise left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm mostly concerned with full-on buying of float64s as our storage mechanism since we're only storing ints. That said, I don't know exactly what the best thing to do is. We could either store ints and hope that we never need to add floats or we could store floats and have to deal with those. From googling around a bit, it doesn't seem like we'll loose too much from storing floats until we get up to 2**53 of anything...

}
defer control.Delete()
pid := os.Getpid()
err = control.Add(cgroups.Process{Pid: pid})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it's the default behavior that child processes get put into the parent's the cgroup?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly!

return metrics
}
if cm.CPU != nil && cm.CPU.Usage != nil {
metrics["cpuUsage"] = float64(cm.CPU.Usage.Total)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should these values continue to be float64s? It seems that all our metrics are ints.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we'll need to circle back to metrics as we try more use cases (k8s pod autoscaler, etc). I'd prefer not to do much more until we have a better idea how metrics will be used.

@@ -108,6 +108,15 @@ func (s *Server) statusHandler(w http.ResponseWriter, r *http.Request) {
var resourceUsage api.ResourceMetrics
if time.Since(s.lastMetricTime) > minMetricPeriod {
resourceUsage = s.metrics.GetSystemMetrics()
for _, us := range append(status, initStatus...) {
unitResourceUsage := s.metrics.GetUnitMetrics(us.Name)
for k, v := range unitResourceUsage {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of updating the map, would it make sense to name these correctly (with the unit name) in metrics.go?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea 👍

@ldx ldx force-pushed the vilmos-unit-resourceusage branch from 12fb454 to f0b2962 Compare June 13, 2019 17:43
@ldx ldx merged commit 9303852 into master Jun 13, 2019
@ldx ldx deleted the vilmos-unit-resourceusage branch June 13, 2019 17:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants