platformmanagement_public_425 - image usage report tool

[soltysh]

This is last element of my card. Sample output looks like this:

# oadm image-refs
test/django-ex:latest (sha256:a045cf8a5baa7e0031bc44195ecfbad107a2bfb3fc8f1a6afdbe1497fb721d14)
BuildConfigs:
- <none>
Builds:
- <none>
DeploymentConfigs:
- test/django-ex
ReplicationControllers:
- test/django-ex-1
Pods:
- test/django-ex-1-3sjbz

@smarterclayton since you've mentioned you don't like #9542 being a separate command. How about joining the two into oadm images which can do both based on flags?
@miminar first commit is the reuse we've talked about :)

[smarterclayton]

I'm kind of averse to both of these - they don't fit our existing CLI model and I'm not sure I understand the use case they are solving. Link to trello card here please?

[soltysh]

Here you go: https://trello.com/c/L9Coo2Zi/425-5-admin-can-understand-manage-image-use

[smarterclayton]

Ok, that helps. I'd like to refocus this on two things:

1. Getting data out of the platform in a usable way for admin scripting and
   stats gathering - not a high level output, but a low level output. The
   "pretty" output here isn't really targeted for that, but the graph may
   potentially allow it
2. Doing a better summarization to highlight problem spots and abusers

I think the underlying stuff you're doing is a good start, but I'd ask a
couple of things:

1. I want to get the output of this in a form I can do further manipulation
2. that means CSV or JSON (and maybe even go templates) based on a
   structured internal representation that retrieves information that is
   annoying to fetch today
3. What are the questions that we have to answer (written out as an end
   user would ask) and how can we answer the most questions with the least
   implementation

The output in this PR to start is likely not scriptable, but I expect end
users to put this into an automated process and periodically run a sweep
(or import it into another metric platform).

I'd kind of expect the following:

1. Per image, identify all the parents in the platform that share common
   parent layers (i.e. if image A contains a subset of image B's layers,
   starting at the first layer, A is a potential parent of B) and surface that
   information in a structured way, probably including which image stream tags
   reference that image now (or which ones have historical references)
2. Per image, identify the number of places it is deployed in a pod - use
   the controller metadata on the pod to identify which controller created it
   as well (rather than having to load all controllers). A follow up could
   identify this data
3. Flag images without metadata information (imported from Docker 1.10 or
   before we started tracking image size)
4. Given that info, assemble a summary layer that reports by image stream
   and namespace - return information per image stream that includes total
   unique storage size (every layer that is tagged only in this image stream),
   total size (sum of all referenced layers), number of unique images, number
   of unique layers, etc

The first 3 allow me to perform image related queries. The last one allows
me to assess the impact an individual user has on the platform.

I would expect the UI on this to be a tabular representation of any of
those layers (image, image stream, or namespace) that is easily greppable,
sortable, cuttable, with an optional JSON/YAML output.

On Mon, Jun 27, 2016 at 4:31 PM, Maciej Szulik [email protected]
wrote:

Here you go:
https://trello.com/c/L9Coo2Zi/425-5-admin-can-understand-manage-image-use

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9587 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ABG_p-hvR4d0P6HTLqoQOl6olOSTvrTMks5qQDMugaJpZM4I_Vy5
.

[smarterclayton]

See kubernetes/kubernetes#11382 for a rough equivalent. They turn the core data into an intermediate form which is usable. Then they do a simple display with Get. we want the same thing for this.

[smarterclayton]

This might just be oc top image and oc top imagestream

[soltysh]

Thanks, will check this out.

[soltysh]

@smarterclayton ptal if this is going in the right direction. What is left atm is only the printing logic. The data aggregation part is ready for review.

[soltysh]

@smarterclayton this is ready for review, for now only one possible output is supported but this can be easily expanded as a followup. Please let me know what you think. Here's the sample output:

$ # oadm top images
NAME                 IMAGESTREAMTAG            PARENTS                   USAGE                         METADATA    STORAGE     
sha256:e3ad517f317ad openshift/python:3.4                                                              yes     313.67MiB   
sha256:633e1b01fc1e7 openshift/python:2.7                                                              yes     315.61MiB   
sha256:87d711264f83e openshift/wildfly:9.0                                                             yes     699.17MiB   
sha256:01f097ffb2399 openshift/perl:5.16                                                               yes     272.75MiB   
sha256:26a597bf64607 openshift/mongodb:3.2                                                             yes     280.01MiB   
sha256:946e2682af3e3 openshift/php:5.5                                                                 yes     306.80MiB   
sha256:4d04b60ca007e openshift/postgresql:9.2                                                          yes     99.23MiB    
sha256:1da960d283b9a openshift/ruby:2.0                                                                yes     233.85MiB   
sha256:91d3acc47b622 openshift/mongodb:2.6                                                             yes     326.83MiB   
sha256:3dcd565fd2230 openshift/postgresql:9.4                                                          yes     99.97MiB    
sha256:5bb7a50c3f968 openshift/wildfly:8.1                                                             yes     653.26MiB   
sha256:80c985739a78b openshift/python:latest                                                           yes     303.12MiB   
sha256:a3b5726d37163 openshift/mongodb:2.4                                                             yes     223.86MiB   
sha256:74861c4629ee7 openshift/mariadb:10.1                                                            yes     195.33MiB   
sha256:8515ff3cc0742 openshift/perl:5.20                                                               yes     276.50MiB   
sha256:b6d97ea7512d9 openshift/php:5.6                                                                 yes     299.08MiB   
sha256:1503c02d475d4 openshift/mysql:5.6                                                               yes     164.16MiB   
sha256:9ef421182d18b openshift/jenkins:1                                                               yes     396.18MiB   
sha256:64461b5111fc7 openshift/ruby:2.2                                                                yes     234.33MiB   
sha256:0e19a0290ddc1 test/ruby-ex:latest       sha256:64461b5111fc71ec   Deployment: ruby-ex-1/test    yes     150.65MiB   
sha256:a968c61adad58 test/django-ex:latest     sha256:80c985739a78b760   Deployment: django-ex-1/test  yes     186.07MiB   
sha256:4082f3865ca23 openshift/wildfly:10.0                                                            yes     702.56MiB   
sha256:2f915cc0ab614 openshift/postgresql:9.5                                                          yes     100.33MiB   
sha256:11e6aa02fba1c openshift/nodejs:4                                                                yes     254.26MiB   
sha256:04102620cde7d openshift/python:3.3                                                              yes     309.64MiB   
sha256:187ed028270ab openshift/ruby:2.3                                                                yes     249.60MiB   
sha256:68de7ac0fe6f4 openshift/mysql:5.5                                                               yes     146.23MiB   
sha256:97506ab5d0627 openshift/nodejs:0.10           

# oadm top imagestreams
NAME            STORAGE     IMAGES  LAYERS  
openshift/python    1.21GiB     4   36  
openshift/wildfly   2GiB        3   36  
openshift/jenkins   396.18MiB   1   7   
openshift/perl      549.23MiB   2   18  
openshift/mongodb   830.68MiB   3   15  
openshift/ruby      717.76MiB   3   27  
openshift/mysql     310.39MiB   2   12  
test/ruby-ex        150.65MiB   1   10  
openshift/mariadb   195.33MiB   1   3   
openshift/nodejs    508.71MiB   2   19  
openshift/php       605.89MiB   2   18  
openshift/postgresql    299.52MiB   3   15  
test/django-ex      186.07MiB   1   10  

[soltysh]

Added tests per @mfojtik request.

[smarterclayton]

Looks good, two requests:

1. split top into a top level command and its sub functions into child commands (so kubectl top images should itself be a command). Can keep initializing them here, but is a more correct factoring (like oc create).
2. add more specific tests in test-cmd to verify anything is actually returned.

[soltysh]

@smarterclayton commands split (1 - checked), for no 2 it doesn't make any sense to add more tests to test-cmd since it doesn't have any images nor imagestreams. I'll work on unittest and maybe some extended as a followup if you don't mind.

[smarterclayton]

You can create images directly via oc create and then test it. So test-cmd
is the best place to start.

On Tue, Jul 26, 2016 at 8:20 AM, Maciej Szulik [email protected]
wrote:

@smarterclayton https://github.com/smarterclayton commands split (1 -
checked), for no 2 it doesn't make any sense to add more tests to test-cmd
since it doesn't have any images nor imagestreams. I'll work on unittest
and maybe some extended as a followup if you don't mind.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#9587 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pwNiYApC0AipYrq7V0VlQYW3WolPks5qZft3gaJpZM4I_Vy5
.

[soltysh]

@smarterclayton added unit tests and cmd tests, ptal.

[soltysh]

I don't want to have more aggressive checks here, since none of this information is stable enough. More aggressive checks are done in unit testing.

[smarterclayton]

You can just import a fake image that is stable. We have several of those.

[soltysh]

Hmmm... I must have missed those. I'll update.

[soltysh]

[test]

[soltysh]

Test flake #8427.

[merge]

[soltysh]

Flake #9938

re-[merge]

[soltysh]

Flake #10002.

re-[merge]

[soltysh]

Flake #9775 #9490

re-[merge]

[soltysh]

#9775 again...

re-[merge]

[soltysh]

Fixed the tests comparing array since they were flaking.

[soltysh]

Tightened infos array comparisons more.

[soltysh]

#9775 again...

re-[merge]

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/7417/) (Image: devenv-rhel7_4731)

[soltysh]

Rebased on top of master to hopefully bypass the flake.

[openshift-bot]

Evaluated for origin test up to 505b462

[openshift-bot]

Evaluated for origin merge up to 505b462

[openshift-bot]

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/7250/)

[stevekuznetsov]

re[merge]

[soltysh]

#9775 again...

re-[merge]

[deads2k]

@soltysh @smarterclayton how are we going to handle this in combination with kubectl top command upstream? We're going to have some subcommands and some arguments? I don't think I want different oadm top and oc top commands.

[deads2k]

@fabianofranz you probably want to chase the upstreams too.

[soltysh]

@deads2k the commands is created in such a way to be possible to hook the subcommands into upstream's kubectl top. There won't be any userside command, at least not for now.

[deads2k]

@deads2k the commands is created in such a way to be possible to hook the subcommands into upstream's kubectl top. There won't be any userside command, at least not for now.

That's different than the construction of the upstream top command and the upstream top command will be split between user things and admin things.

@fabianofranz how would you try to integrate these two things together?

[fabianofranz]

We made arguments before about not mixing args and subcommands.

Unless node and pod in upstream's kubectl top become subcommands when the user/admin split happens, that's what we will have here. For example, flags in kubectl top node|pod ... will cascade and be visible here.

[soltysh]

We made arguments before about not mixing args and subcommands.

image|imagestreams where resource arguments, but on Clayton's request I've moved those to subcommands. I don't see any problems changing this later on, as long as we're able to maintain backwards compatibility. Other option is to make these commands experimental, which is good alternative for now.

[deads2k]

We made arguments before about not mixing args and subcommands.

Unless node and pod in upstream's kubectl top become subcommands when the user/admin split happens, that's what we will have here. For example, flags in kubectl top node|pod ... will cascade and be visible here.

Sounds like that should be pushed on upstream.