docker network create provides a facility to define networks both within a docker host ('bridge') and between docker hosts ('overlay').
SDC's fabric implementation can reasonably provide this as well.
Former user commented on 2016-03-18T17:45:51.000-0400 (edited 2016-03-18T17:51:40.000-0400):
Hi @Former user - I think we may want to stick to just the 'overlay' driver option since Triton's networking is always across all Triton-eligible hosts in the DC. There won't be a scenario for creating a single-host network, as what the 'bridge' option is for.
The docker remote API network create endpoint currently requires only the network name. All other attributes are set to certain default values. In our case, we may want to mandate the passing of the 'subnet' value. Other than that, the attributes Triton networking requires can be set to default values as well. I think this may be what we need:
Attribute
Required?
Default
Validation
name
required
none
netname validation as defined in joyent schemas
subnet
required
none
subnet validation as defined in joyent schemas
driver
optional
overlay
ignored, always set to 'overlay'
gateway
optional
none
v4 address as defined in joyent schemas, but will need to accept v6 in the future
ip-range
optional
entire range allowed for subnet
same as napi provision start/end ip validation
internal
optional
none
when present, maps to internet_nat=true in napi
ipam-driver
optional
default
ignored, i.e. always set to 'default'
ipam-opt
optional
none
ignored
opt
optional
none
may consider using this for passing resolvers and routes
You mentioned some additional options/attributes required for overlay network but I believe those are meant for the docker host (passed when bringing up the docker daemon) instead of the containers. If that's correct, we can totally ignore those.
Let me know if the above makes sense. Thanks.
cc/@Former user
Former user commented on 2016-03-18T17:56:53.000-0400:
Regarding the DNS integration - since we have chosen to do service discovery in a different way in CNS, I think we can disregard the DNS portion of docker networking in our implementation.
We can also disregard the 'links' functionality as it predates docker networking, and is considered a legacy feature. (https://docs.docker.com/engine/userguide/networking/work-with-networks/)
Todd Whiteman commented on 2017-09-25T18:13:16.000-0400:
For docker network create, there are some differences (in what docker allows v's what NAPI allows) that should be discussed:
1) the subnet field is optional in docker/docker - docker uses a free /24 subnet (i.e. 192.168.1.0 to 192.168.1.255) when not specified. I think we should follow suit here, and modify NAPI.CreateFabricNetwork (or create a new endpoint) to allow the creation of a fabric network that finds/uses a free subnet, and errors when none are available.
2) NAPI has the additional concept of a vlan_id (required in the CreateFabricNetwork call). For sdc-docker, that means a call to NAPI.CreateFabricVLAN. But first, one needs a vlan_id to do the creation, so similar to CreateFabricNetwork above, we should modify NAPI to find/use a free vlan_id (there are 4095 possible vlan_id's) when one is not supplied. Note that the alternative (we made vlan_id a required parameter), it would need to be passed through as a network option, e.g.:
docker network create --subnet 192.168.1.0/24 --label triton.network.vlan_id=97 MyDockerNetworkTodd Whiteman commented on 2017-09-25T18:19:26.000-0400:
FYI, this sdc-docker branch holds the 'docker network create' functionality:
https://github.com/joyent/sdc-docker/tree/DOCKER-723
with the limitation that the subnet must be provided (required) and that a free vlan_id is found by querying all existing vlan_id's and then finding a free one from that set.
Note that the behaviour of the vlan_id handling (finding a free default vlan_id) will also affect 'docker network rm', in that deleting a docker network should also free up (delete) it's associated fabric vlan when it's no longer referenced.
Former user commented on 2017-11-01T00:53:56.000-0400:
So, the NAPI stuff is almost good to go. There is one small question, however. While the `subnet` param is now optional, the `provision_ip_start` and `provision_ip_end` params are required. NAPI currently validates these 3 params such that the start-IP and end-IP are both within the `subnet`. The questions is this: do we want to make start-IP and end-IP optional as well (and we fill them in if we find a subnet), or do we want to choose a subnet that contains both start-IP and end-IP (we would have to make use both IPs are private IPs)?
I have a bias in favor of the former, but would like to hear why the latter might be a better idea.
cc: @Former user
Former user commented on 2017-11-01T13:03:24.000-0400:
The "NAPI stuff" is NAPI-434#icft=NAPI-434 right?
Former user commented on 2017-11-01T13:44:15.000-0400:
@Former user: Yep.
Former user commented on 2017-11-01T14:45:37.000-0400:
@Former user Yes, if sdc-docker is going to call NAPI CreateFabricNetwork and have NAPI select a free subnet, then it is also going to require NAPI to select reasonable provision_start_ip and provision_end_ip.
I assume, but I'm not sure, that NAPI will want to make start_ip the second IP – reserving the first (.1) for a gateway?
Likewise, I assume NAPI will make end_ip, second last IP – reserving .255 for broadcast.
@Todd Whiteman, @Former user When selecting a subnet, are we settling on NAPI picking a /24 range (e.g. 192.168.N.0/24)?
I'm happy to be overruled by Cody.
Former user commented on 2017-11-01T16:08:45.000-0400:
@Former user: So, just discussed this over lunch. Basically we settled on (a) selecting a sane range if the subnet is to be auto-allocated, and (b) creating a second set of HTTP params that explicitly tell NAPI that auto-allocation is desired, and that doesn't overload the meaning of the 'subnet' param (which is what the code currently does, and shouldn't). Part of one new params mentioned in (b) is the prefix-length — so that sdc-docker can specify the /24 range (and so that other consumers can do whatever they want).
Former user commented on 2017-11-02T16:15:16.000-0400:
Sounds good, thanks.