-
Notifications
You must be signed in to change notification settings - Fork 616
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
Conversation
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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
?
There was a problem hiding this comment.
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;
}
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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. |
@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 |
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. |
5ec0573
to
4fd6c58
Compare
Codecov Report
@@ 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 |
@aaronlehmann generated from a vm with go1.7. PTAL |
@abhinandanpb: Thanks. |
@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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM (NAM)
d50d87a
to
9c0ee6d
Compare
LGTM I was hoping to get "Driver options" in the comment changed to |
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
@aaronlehmann addressed all comments. PTAL. |
Still LGTM, thanks |
ping @aluzzardi @stevvooe @aboch PTAL |
LGTM |
How will consumers of this field no which driver these options are valid for? |
Effectively, I think that the It also needs to be clarified that this is parameterizing the attachment to a network and not the network itself. |
@stevvooe this field is used in conjunction with |
@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. |
okay. I found the documentation okay because |
@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 |
@stevvooe yes. the |
Addressing comment from stevvooe on moby#2176 Signed-off-by: Abhinandan Prativadi <[email protected]>
Addressing comment from stevvooe on moby#2176 Signed-off-by: Abhinandan Prativadi <[email protected]>
Addressing comment from stevvooe on moby#2176 Signed-off-by: Abhinandan Prativadi <[email protected]>
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]