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

Proposed Cluster (CSI) Volume Command (rebase) #3606

Merged
merged 2 commits into from
May 17, 2022

Conversation

thaJeztah
Copy link
Member

@thaJeztah thaJeztah commented May 13, 2022


This proposal involves merging the cluster volume specific options and commands with the existing volume subcommand. There are a handful of new create flags which are only applicable to cluster volumes. There is also a new flag for list, which lists only cluster volumes and formats the table differently.

Examples of the output can be found in the new .golden files.

@thaJeztah
Copy link
Member Author

looks like most of the intermediate commits no longer built (due to the vendoring changes), so I squashed them

- Write test for cluster volumes
- Add inspect test, add update command
- Add cluster volume opts to create
- Add requisite and preferred topology flags
- volume: move cluster bool in opts

Signed-off-by: Drew Erny <derny@mirantis.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah thaJeztah marked this pull request as ready for review May 13, 2022 18:12
@codecov-commenter
Copy link

Codecov Report

Merging #3606 (c994476) into master (d0df532) will increase coverage by 0.05%.
The diff coverage is 69.61%.

❗ Current head c994476 differs from pull request most recent head 2a77228. Consider uploading reports for the commit 2a77228 to get more accurate results

@@            Coverage Diff             @@
##           master    #3606      +/-   ##
==========================================
+ Coverage   58.96%   59.02%   +0.05%     
==========================================
  Files         288      289       +1     
  Lines       24419    24588     +169     
==========================================
+ Hits        14399    14513     +114     
- Misses       9148     9202      +54     
- Partials      872      873       +1     

@thaJeztah
Copy link
Member Author

Made some changes;

Annotated docker volume update and the cluster-volume flags on docker volume create both for documentation, and to hide them if swarm is not enabled (or the daemon is too old); for example;

docker volume update
docker volume update requires API version 1.42, but the Docker daemon API version is 1.41

And I removed the -g shorthand for --group (for now); we're trying to be conservative on shorthand flags, as they easily "conflict" with other options, and to reserve them for options that are very frequently used. It's easier to add later, than to remove/deprecated.

Worth noting that docker stack deploy does not yet support this feature, and may need changes in the compose-spec (?); we probably need a follow-up after this to add support for it.

And of course, we need to do a full review of the UX before GA (are we ok with all the flags? should some be "combined"?)

Comment on lines 46 to 49
flags.BoolVar(&options.cluster, "cluster", false, "Display only cluster volumes, and use cluster volume list formatting")

Copy link
Member Author

Choose a reason for hiding this comment

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

Let me annotate this one as well

Perhaps we should have a --filter for this, but we can discuss that further

This hides the flags when connecting to an older engine, or if
swarm is not enabled, and is also used to add badges in the
documentation.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
@thaJeztah
Copy link
Member Author

@dperny @corhere @tianon @cpuguy83 PTAL

Comment on lines +108 to +111
return flags.Changed("group") || flags.Changed("scope") ||
flags.Changed("sharing") || flags.Changed("availability") ||
flags.Changed("type") || flags.Changed("secrets") ||
flags.Changed("limit-bytes") || flags.Changed("required-bytes")
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it be feasible to derive the set of flags to check from the annotations so that it couldn't get out of sync with the flag definitions?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, there's some things to clean up in this area. I had a variant where I defined a slice of flag-names that are related, and used the slice for both setting the annotations and for this code, but in the end decided to keep my changes on top of @dperny's PR minimal

My goal with this rebase was to have the PR in a "mergeable" state, so that I could do a test-build/test-release of 22.06 with at least something that exposes the new feature. So I only fixed the type renames from upstream, and added the second commit to have the correct annotations on the flags.

@@ -37,6 +55,7 @@ func newCreateCommand(dockerCli command.Cli) *cobra.Command {
}
options.name = args[0]
}
options.cluster = hasClusterVolumeOptionSet(cmd.Flags())
Copy link
Contributor

Choose a reason for hiding this comment

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

I think creating a cluster volume should be explicitly set by the user, rather than implied by setting any of the cluster-volume options so that users don't unintentionally create cluster volumes by setting a generically-named flag. Strawman: the --group flag pulls double-duty as the "create a cluster volume" flag by renaming it to ‑‑cluster‑volume GROUPNAME and making it an error to set any of the other cluster-only options unless that flag is also set. If a user wanted for whatever reason to create a cluster volume in the empty-string group, they could do so explicitly: docker volume create ‑‑cluster‑volume ""

Copy link
Member Author

Choose a reason for hiding this comment

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

I was considering that we could use the --scope flag to match docker network create. However docker network create accepts --scope=swarm for "swarm managed / scoped networks" and --scope=local for node-local networks, so we may have to do a follow-up to make that work as an option.

We should finalise that discussion before "GA" of 22.06, but I'd be ok with shipping what we have now in the first builds, and do follow-ups on that (as long as changes are done before 22.06 GA)

Copy link
Member

@rumpl rumpl left a comment

Choose a reason for hiding this comment

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

Let's get this one in, we can fix the UX/flags/todos in a followup

@dperny
Copy link
Contributor

dperny commented May 17, 2022

This looks fine to me for now. I'm more than happy to make any UI changes desired. UI is the easy/fun part.

@thaJeztah
Copy link
Member Author

Okay; let's get this in for now

@olljanat
Copy link
Contributor

olljanat commented Feb 5, 2023

FYI. I have build some example scripts and guidance to https://github.com/olljanat/csi-plugins-for-docker-swarm about how to make existing CSI plugins working with Swarm which those who following this discussion might find useful.

matt9ucci added a commit to matt9ucci/DockerCompletion that referenced this pull request Feb 9, 2023
matt9ucci added a commit to matt9ucci/DockerCompletion that referenced this pull request Feb 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants