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

Grpc change for network options in service spec #2176

Merged
merged 1 commit into from
May 15, 2017

Conversation

abhi
Copy link
Contributor

@abhi abhi commented May 10, 2017

Service command is being updated to accept network
specfic options like name,alias and driver options.The
commit contains changes to grpc service api and adopting
the same in task attachment

Signed-off-by: Abhinandan Prativadi [email protected]

api/types.proto Outdated
// Addresses specifies a list of ipv4 and ipv6 addresses
// preferred. If these addresses are not available then the
// attachment might fail.
repeated string addresses = 3;

//Driver options is a map of driver specific options for the network target
Copy link
Collaborator

Choose a reason for hiding this comment

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

// DriverOpts is a map of driver-specific options for the network target.

The added lines above have trailing whitespace; please remove the tab characters.

Copy link
Contributor

Choose a reason for hiding this comment

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

Isn't there already a type for this?

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd prefer that we avoid using the map types here, as their order is undefined.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@aaronlehmann I added spaces that were non existent only for this message in the file to make it consistent.
@stevvooe I don't see a type. And I believe we do pack messages in map. Is there an alternative or any known issues with this approach ?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@stevvooe: Are you talking about Driver?

Copy link
Collaborator

Choose a reason for hiding this comment

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

@stevvooe: I'm not sure I understand the question, but this is the definition of Driver:

// Driver is a generic driver type to be used throughout the API. For now, a
// driver is simply a name and set of options. The field contents depend on the
// target use case and driver application. For example, a network driver may
// have different rules than a volume driver.
message Driver {
        string name = 1;
        map <string, string> options = 2;
}

Copy link
Contributor

Choose a reason for hiding this comment

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

So, are these options propagated to the target then? How are they different from the existing service spec options?

I must be missing a detail here.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@stevvooe: Which existing service spec options are you talking about? I don't see any on the network attachment level, but I may also be missing something.

Copy link
Contributor

Choose a reason for hiding this comment

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

@abhinandanpb as a best practice always add the dependent PR links and that will help the reviewers to map the usage.

@stevvooe @aaronlehmann I think the usage details as expressed in moby/moby#33130 and docker/cli#62 will help explain this new option. Essentially, these are some of the user-specified service options that are passed to the network drivers. Labels are NOT sent to the drivers and in other docker objects we have introduced driver-opts to pass on such operator specific params to the drivers (volumes and network). Service object was missing it and via this PR @abhinandanpb is introducing it.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Can you please update the comment as requested above: https://github.com/docker/swarmkit/pull/2176/files#r115864626

This will make it consistent with the godoc-style comments elsewhere in this message that refer to the camelcased versions of the names.

@aaronlehmann
Copy link
Collaborator

I see that some unrelated generated .pb.go files are being changed. Are you running Go 1.7.x? I think other versions of go generate these files differently.

@abhi
Copy link
Contributor Author

abhi commented May 10, 2017

@aaronlehmann I believe the changes are due to the ripple effect due to the changes in the NetworkAttachmentConfig since its being used in other messages directly or embedded via another message ? I am using go1.8

@aaronlehmann
Copy link
Collaborator

We're using Go 1.7 right now, but we'll probably switch to Go 1.8 within a day or two when Docker switches over. If the PR can wait until then, the problem with inconsistent protobuf generation should go away.

@abhi abhi force-pushed the network-opt branch 2 times, most recently from 5ec0573 to 4fd6c58 Compare May 11, 2017 06:43
@codecov
Copy link

codecov bot commented May 11, 2017

Codecov Report

Merging #2176 into master will increase coverage by 0.25%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2176      +/-   ##
==========================================
+ Coverage   59.99%   60.24%   +0.25%     
==========================================
  Files         119      119              
  Lines       19784    19785       +1     
==========================================
+ Hits        11869    11920      +51     
+ Misses       6564     6534      -30     
+ Partials     1351     1331      -20

@abhi
Copy link
Contributor Author

abhi commented May 11, 2017

@aaronlehmann generated from a vm with go1.7. PTAL

@aaronlehmann
Copy link
Collaborator

@abhinandanpb: Thanks.

@mavenugo
Copy link
Contributor

@aaronlehmann @abhinandanpb moby/moby is updated to go1.8.1. Can you please get this PR reviewed ? This PR is the base dependency on moby/moby#33130 and docker/cli#62

Copy link
Contributor

@mavenugo mavenugo left a comment

Choose a reason for hiding this comment

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

LGTM (NAM)

@aaronlehmann
Copy link
Collaborator

LGTM

I was hoping to get "Driver options" in the comment changed to DriverOpts to be consistent with the other comments, and to remove the tabs on empty lines, but I don't want to hold this up over that.

Service command is being updated to accept network
specfic options like name,alias and driver options.The
commit contains changes to grpc service api and adopting
the same in task attachment

Signed-off-by: Abhinandan Prativadi <[email protected]>

temp
@abhi
Copy link
Contributor Author

abhi commented May 12, 2017

@aaronlehmann addressed all comments. PTAL.

@aaronlehmann
Copy link
Collaborator

Still LGTM, thanks

@thaJeztah
Copy link
Member

ping @aluzzardi @stevvooe @aboch PTAL

@aluzzardi
Copy link
Member

LGTM

@aluzzardi aluzzardi merged commit 993a222 into moby:master May 15, 2017
@stevvooe
Copy link
Contributor

How will consumers of this field no which driver these options are valid for?

@stevvooe
Copy link
Contributor

Effectively, I think that the DriverOpts need to be namespaced by driver or included with a driver structure.

It also needs to be clarified that this is parameterizing the attachment to a network and not the network itself.

@mavenugo
Copy link
Contributor

@stevvooe this field is used in conjunction with network (docker/cli#62) and is not an independent field. Each network is backed by one and only driver and hence the driver-opt for a given service is that network/driver specific.
am not sure if that answers your question. Please let me know.

@stevvooe
Copy link
Contributor

@mavenugo Are they parameterizing the creation of a network or the attachment to a network? Right now, from the field documentation on the protobuf, this is not clear in the way these are intended to be used.

@mavenugo
Copy link
Contributor

okay. I found the documentation okay because // Map of all the driver options for this network was written inside of NetworkAttachment object and hence contextually it can make sense. But if you think we should better comment it, I will let @abhinandanpb make it more descriptive.

@stevvooe
Copy link
Contributor

@mavenugo That comment is misleading. They are the options for attaching to the network. The network is already created and the options are already specified when it was created. In that sense, it doesn't really make sense contextually, as these cannot parameterize a driver because it has already been created.

Should these be called DriverAttachmentOpts or something like that?

@mavenugo
Copy link
Contributor

@stevvooe yes. the DriverAttachmentOpts makes it clear.
@abhinandanpb wdyt ?

abhi added a commit to abhi/swarmkit that referenced this pull request May 15, 2017
Addressing comment from stevvooe on
 moby#2176

Signed-off-by: Abhinandan Prativadi <[email protected]>
abhi added a commit to abhi/swarmkit that referenced this pull request May 15, 2017
Addressing comment from stevvooe on
 moby#2176

Signed-off-by: Abhinandan Prativadi <[email protected]>
abhi added a commit to abhi/swarmkit that referenced this pull request May 16, 2017
Addressing comment from stevvooe on
 moby#2176

Signed-off-by: Abhinandan Prativadi <[email protected]>
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