Revising remote functionality

[preminger]

We've been rethinking how the functionality that currently lives under the singularity remote command is organized.

I'll lay out our current thoughts here, and we'd welcome any feedback from the community on these ideas.

---

Command groups

It might make sense to split the relevant functionality into (up to) three different commands:

• singularity registry: manage logins to OCI registries (outside of Singularity Cloud Services / Singularity Enterprise installs); in other words, DockerHub and the like
• singularity keyserver: manage keyservers; in particular, adding them to the list, determining their order, and removing them from the list
• singularity remote: now stripped down to managing only the interactions with Singularity Cloud Services and/or Singularity Enterprise installs

(Feedback is welcome both on the idea of splitting things up this way, and on the names of the new commands.)

Functionality changes

• Currently, singularity remote add doesn't select the newly-added remote as current. For most use cases, it makes sense to automatically do that. The idea is to change this, and possibly add a --notcurrent flag to remote add that suppresses this behavior.

UI changes

• Avoiding double-negations:
  • The output of the singularity remote list subcommand is currently organized in a somewhat unintuitive fashion. For example, it includes a column titled INSECURE whose values can be YES and NO, the latter requiring the user to parse a double negation (INSECURE: NO).
  • Ditto for the Authenticated Logins section.
  • Reversing the polarity would probably be helpful here (e.g. SECURE: YES/NO; but see below).
• Increasing visual usability:
  • Much of the output generate by singularity remote & its subcommands involves tables populated by YES/NO values. Even setting aside the polarity issue mentioned above, this is a visually "busy" output & not the most useful.
  • Two potential alternatives:
    1. Preserve the table structure, but use blank (=an empty table cell) instead of NO and a visual mark (e.g. an asterisk) instead of YES. This should make the tables much easier to visually comprehend.
    2. Alternatively, we could scrap the table output entirely – and instead, when listing individual remotes, just add a parenthesized list of their relevant properties (i.e., those properties for which the table would have indicated YES or an asterisk). Example:

SylabsCloud (cloud.sylabs.io; active, global)
company-remote (enterprise.example.com; global)
myremote (enterprise.example.com)

---

We welcome your feedback!

[dtrudg]

@preminger I've looked at this a couple of times in the past week, and I think I'm 👍 on all of it. I think separating the auth against oci registries from Enterprise/SCS remotes would be a big win, as people are generally confused by how it works at present.

The only question in my mind is whether @EmmEff and @tri-adam think the singularity registry / singularity keyserver / singularity remote split is the right one.

Please could you start taking the individual steps in this proposal, and creating issues for them? Thanks!

[preminger]

Is okay if I put the first three bullets under a single Issue (and PR)?

[dtrudg]

The re-arranging of commands? I would personally split it into at least two...

• Move keyserver operations from remote to keyserver.
• Move oci registry operations from remote to registry.

Each one will be quite a large change to split the packages like the CLI, update the CLI doc strings, tests etc.

[preminger]

Upshot of above discussion has been distilled into several issues —

• move keyserver-related operations from remote to new keyserver command #1893
• move OCI registry operations from remote to new registry command #1894
• automatically select argument to remote add as current remote #1895
• "content-centric" format of remote list output, instead of table #1896

— which have been addressed in these PRs:

• move keyserver-related cmds from remote to their own cmd #1905
• move OCI/Docker-registry-related cmds from remote to their own cmd #1908
• clean up format of remote list output #1919
• remote add sets new endpoint as default, suppressible via flag #1920
• add indicator for the default remote in keyserver list output #1958
• fix listing of authenticated logins to cover both registries and keyservers #1959