docker: tags and org

[DavidGOrtega]

We are publishing some images that might not be used anymore:

• dvcorg/cml-cloud-runner
• dvcorg/cml-py3-cloud-runner
• dvcorg/cml-gpu-cloud-runner
• dvcorg/cml-gpu-py3-cloud-runner

@elleobrien do you use anyone of these in our docs/videos?

[elleobrien]

Nope, by the time I made my video with the GPU we had already consolidate the gpu into base cml container! Thanks for thinking of this, though.

[elleobrien]

To me, it's okay to deprecate all of them.

[0x2b3bfa0]

@DavidGOrtega, it looks like these repositories aren't being used anymore, and the number of pulls (~200 in total) hasn't increased in a while. May we remove them directly, or should they be soft-deprecated with a message instead? In the former case, they should be removed manually through the Docker Hub web interface, because the API doesn't support this operation for token-authenticated users.

[0x2b3bfa0]

🔔 @iterative/cml, I'm deleting them unless anybody states otherwise.

[DavidGOrtega]

@0x2b3bfa0 lgtm

[casperdcl]

I guess you've checked download counts aren't increasing? https://hub.docker.com/u/dvcorg

[0x2b3bfa0]

the number of pulls (~200 in total) hasn't increased in a while

I checked it a few weeks ago and there weren't any new downloads in 5 days. Does this timespan sound reasonable?

[casperdcl]

You should also be able to tell when each tag was last pulled.

I would say it's fine to stop updating them but not necessarily delete them from the hub yet.

[0x2b3bfa0]

You should also be able to tell when each tag was last pulled.

I have been unable to find how to gat that information after a cursory search. Does Docker Hub store that information?
We'll need to ask somebody that's part of the organization. 🙏 Thanks!

I would say it's fine to stop updating them but not necessarily delete them from the hub yet.

After a deeper investigation, I noticed that these image names were being used in the cml.dev documentation prior to 0.3.0.

While I only have written data for 5 days, the numbers are the same as 45 days ago if my brain didn't mix the digits. 😄 Nevertheless, caution doesn't hurt and we can leave them there just in case.

[shcheklein]

[casperdcl]

120 inactive images and these ain't part of 'em hah

[0x2b3bfa0]

🤔 Let's leave this running for a while before taking any decision: https://github.com/0x2b3bfa0/cml-docker-statistics

[DavidGOrtega]

@casperdcl @0x2b3bfa0 You have to take into account also that originally I developed images to test and use ala test- command and probably is that the case

[0x2b3bfa0]

@DavidGOrtega, do you mean that some of these 120 inactive images could be just stale testing images?

[0x2b3bfa0]

Activity in the last 45 days

• cml-cloud-runner had two pulls: one at 2021-05-12 08:06:29 UTC, and the other ~58 minutes later.
• cml-gpu-cloud-runner had zero pulls
• cml-gpu-py3-cloud-runner had zero pulls
• cml-py3-cloud-runner had zero pulls

Source: https://github.com/0x2b3bfa0/cml-docker-statistics

[0x2b3bfa0]

🔔 @iterative/cml, 👍🏼 upvote to delete these container repositories or 👎🏼 downvote to soft-deprecate them by putting a big, red warning sign somewhere.

Reasons to delete

We only have two good and updated container repositories: cml for end users and cml-test for internal testing. The others don't serve any other obvious purpose apart from confusing users, and we have a dozen of them still published on Docker Hub — most of them not documented anywhere.

Reasons to keep

As a local saying states, you can measure a hundred times, but cut only once (approximate translation). Potentially destructive actions should be only taken after a healthy amount of warnings, just in case we have some user that started to use these containers but decided not to pull them but on leap years to make us think that there are zero users.

[DavidGOrtega]

cml-cloud-runner had two pulls: one at 2021-05-12 08:06:29 UTC, and the other ~58 minutes later.
🤔

[0x2b3bfa0]

Same results for the 45 days sliding window. Shall we take a decision?

[casperdcl]

action points:

• make latest point to 0-dvc2-base1-gpu
  • may break some user workflows but that's their fault for not pinning. latest is a "user beware" flag
• don't bother deleting old images/tags
  • remove them from all documentation
  • don't update them so they show as not updated for months in the hub's tag list
• also push active tags to iterativeai/cml (soft-deprecate dvcorg/cml)
  • check credentials - ideally one bot user with push access to both orgs
  • solves problem with dvcorg having lots of outdated images/tags. iterativeai will be "clean"

[0x2b3bfa0]

I would say it's fine to stop updating them but not necessarily delete them from the hub yet.

🔔 @casperdcl, 10 months and 6 pulls later... 🤔

[0x2b3bfa0]

don't update them so they show as not updated for months in the hub's tag list

@casperdcl, given that we don't control third–party blog posts and other resources, I wonder if we should revisit that decision and update cml-py3 to display a deprecation warning on every run. 🤔