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

Do not allow service creation on ingress network #1600

Merged
merged 1 commit into from
Oct 5, 2016
Merged

Do not allow service creation on ingress network #1600

merged 1 commit into from
Oct 5, 2016

Conversation

aboch
Copy link

@aboch aboch commented Oct 4, 2016

Related to moby/moby#27147

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
9303692245a0        bridge              bridge              local
c4f927d72329        docker_gwbridge     bridge              local
1de6d5796506        host                host                local
640eymcv5g3c        ingress             overlay             swarm
7af0bf63afad        none                null                local
$ 
$ docker network inspect ingress | grep Id
        "Id": "640eymcv5g3cabu4jdffrandw",
$ 
$ docker service create --network 640eymcv5g3cabu4jdffrandw busybox top
Error response from daemon: rpc error: code = 3 desc = Service cannot be explicitly attached to "ingress" network which is a swarm internal network
$ 
$ docker service create --network ingress busybox top
Error response from daemon: rpc error: code = 3 desc = Service cannot be explicitly attached to "ingress" network which is a swarm internal network
$ 
$ docker service create --network 640eymcv5g3c busybox top
Error response from daemon: rpc error: code = 3 desc = Service cannot be explicitly attached to "ingress" network which is a swarm internal network
$

@codecov-io
Copy link

codecov-io commented Oct 4, 2016

Current coverage is 53.80% (diff: 39.13%)

Merging #1600 into master will decrease coverage by 0.08%

@@             master      #1600   diff @@
==========================================
  Files            84         84          
  Lines         13929      13957    +28   
  Methods           0          0          
  Messages          0          0          
  Branches          0          0          
==========================================
+ Hits           7507       7510     +3   
- Misses         5417       5432    +15   
- Partials       1005       1015    +10   

Sunburst

Powered by Codecov. Last update e20bd5b...3e59f1f

continue
}
if _, ok := network.Spec.Annotations.Labels["com.docker.swarm.internal"]; ok {
return grpc.Errorf(codes.InvalidArgument, "Service cannot be explicitly connected to the ingress network")
Copy link
Contributor

Choose a reason for hiding this comment

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

The error message probably should extract the name from the network since may be in the future we may have more than one internal network. Also It should probably be rephrased to something like Service cannot be explicitly attached to "ingress" network which is an internal network

Copy link
Author

Choose a reason for hiding this comment

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

Changed the error, retested (updated outcome in the description). Thanks.

Copy link
Contributor

@mrjana mrjana left a comment

Choose a reason for hiding this comment

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

LGTM

@dongluochen
Copy link
Contributor

LGTM

@rogaha
Copy link

rogaha commented Oct 5, 2016

LGTM, thanks for working on it @aboch

@rogaha
Copy link

rogaha commented Oct 5, 2016

Just a heads up, it also closes this issue: moby/moby#25396

@vieux
Copy link
Contributor

vieux commented Oct 5, 2016

LGTM

// FindNetwork is a utility function which returns the first
// network for which the target string matches the ID, or
// the name or the ID prefix.
func FindNetwork(tx ReadTx, target string) *api.Network {
Copy link
Contributor

Choose a reason for hiding this comment

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

@aboch does this function need to return errors?

Copy link
Author

Choose a reason for hiding this comment

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

No, it is a best effort function on the same line of the existing Getnetwork().
If one query fails (ID, name or id pefix), it moves to the next one.

Eventually, the outcome will be the same as we would have if we reported an error happening during one query: We would eventually not be able to identify an network.

From the caller perspective, it will be a failure regardless.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thanks for clarifying.

Copy link
Contributor

@nishanttotla nishanttotla left a comment

Choose a reason for hiding this comment

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

LGTM

@LK4D4
Copy link
Contributor

LK4D4 commented Oct 5, 2016

LGTM

@LK4D4 LK4D4 merged commit 6cb6e54 into moby:master Oct 5, 2016
@vieux
Copy link
Contributor

vieux commented Oct 5, 2016

@LK4D4 can you please create a PR against docker/1.12.x with this change ?

mavenugo added a commit to mavenugo/docker that referenced this pull request Oct 6, 2016
aaronlehmann added a commit to aaronlehmann/swarmkit that referenced this pull request Oct 6, 2016
PR moby#1600 added a FindNetwork function to the store package to resolve a
NetworkAttachment's target by ID, name, or name prefix. I think this is
based on a misleading comment in the NetworkAttachment definition saying
that the target can be a name or an ID. In fact, it's always an ID, and
existing code passes it directly to GetNetwork.

Clarify the comment and remove FindNetwork.

Signed-off-by: Aaron Lehmann <[email protected]>
niau pushed a commit to vasil-yordanov/swarmkit that referenced this pull request Oct 21, 2016
PR moby#1600 added a FindNetwork function to the store package to resolve a
NetworkAttachment's target by ID, name, or name prefix. I think this is
based on a misleading comment in the NetworkAttachment definition saying
that the target can be a name or an ID. In fact, it's always an ID, and
existing code passes it directly to GetNetwork.

Clarify the comment and remove FindNetwork.

Signed-off-by: Aaron Lehmann <[email protected]>
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.

9 participants