Skip to content

add filtering on node labels#2662

Merged
anshulpundir merged 1 commit intomoby:masterfrom
dperny:filter-on-node-labels
Aug 3, 2018
Merged

add filtering on node labels#2662
anshulpundir merged 1 commit intomoby:masterfrom
dperny:filter-on-node-labels

Conversation

@dperny
Copy link
Copy Markdown
Collaborator

@dperny dperny commented Jun 8, 2018

Signed-off-by: Drew Erny drew.erny@docker.com

- What I did

Previously, the Labels filter was the only one available and only filtered on engine labels. Now, a NodeLabels filter can be passed to filter on node labels as wel

A rewrite of #2062.

Relates to moby/moby#27231, moby/moby#28209

nota bene, this will require plumbing in the engine to fully work.

- How I did it

  • modified the GRPC protos to add a new field to the available filters.
  • plumbed this field to the controlapi

- How to test it

Automated test was written.

- Description for the changelog

Added support in swarmkit for filtering on node labels.

Copy link
Copy Markdown
Contributor

@cyli cyli left a comment

Choose a reason for hiding this comment

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

Would it make sense to change this to EngineLabels and NodeLabels to distinguish? The GRPC object would be the same (because the field number is the same) but the variable name would change.

In moby we'd have to do more for backwards compatibility when translating objects, but in swarmkit the change might be ok.

Other than that and a whitespace nit LGTM.

Thanks for addressing this so quickly.

Comment thread api/control.proto Outdated
message Filters {
repeated string names = 1;
repeated string id_prefixes = 2;
// Labels refers to engine labels, which are labels set by the user on the
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nitpick: Tab/whitespace seems off from the existing code.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

i always screw that up

@dperny dperny force-pushed the filter-on-node-labels branch from 0c6105f to affb4de Compare June 8, 2018 21:06
Signed-off-by: Drew Erny <drew.erny@docker.com>
@dperny dperny force-pushed the filter-on-node-labels branch from affb4de to 9d58676 Compare June 8, 2018 21:07
@codecov
Copy link
Copy Markdown

codecov bot commented Jun 18, 2018

Codecov Report

Merging #2662 into master will increase coverage by 0.18%.
The diff coverage is 100%.

@@            Coverage Diff            @@
##           master   #2662      +/-   ##
=========================================
+ Coverage   62.02%   62.2%   +0.18%     
=========================================
  Files         134     134              
  Lines       21739   21743       +4     
=========================================
+ Hits        13483   13526      +43     
+ Misses       6810    6773      -37     
+ Partials     1446    1444       -2

@Vanuan
Copy link
Copy Markdown

Vanuan commented Jul 1, 2018

So what would cli look like? docker node ls -f "node-label=*" ?

@thaJeztah
Copy link
Copy Markdown
Member

Would it make sense to change this to EngineLabels and NodeLabels to distinguish?

@dperny @cyli If possible, I would be in favour of that; I agree it's more readable and less likely to confuse their purpose (I think the original implementation in #2062 also did a rename?)

So what would cli look like? docker node ls -f "node-label=*" ?

See moby/moby#28209 (comment). To be consistent with --constraint (on docker service), it will likely be;

To be discussed (either keep the old behavior and ignore node-labels, or filter by both);

docker node ls --filter label=foo

Filter by engine labels:

docker node ls --filter engine.label=foo

Filter by node label:

docker node ls --filter node.label=foo

@dperny
Copy link
Copy Markdown
Collaborator Author

dperny commented Aug 3, 2018

I don't think it's a great idea to rename the GRPC field, because it'll require refactoring the whole codebase to accommodate the new names. If we were to do that, I'd suggest doing it in a separate PR.

@dperny
Copy link
Copy Markdown
Collaborator Author

dperny commented Aug 3, 2018

Otherwise, we can kick the CLI bikeshed down the road a bit.

@anshulpundir
Copy link
Copy Markdown
Contributor

I don't think it's a great idea to rename the GRPC field, because it'll require refactoring the whole codebase to accommodate the new names. If we were to do that, I'd suggest doing it in a separate PR.

SGTM.

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.

6 participants