- Handle contains sequence and identifier.
This way datastore integration can be done
at bitseq level.
Signed-off-by: Alessandro Boch <aboch@docker.com>
- In order to facilitate usage of datastore
- This makes it slower. Efficiency will be
revisited later after datastore integration
is done.
Signed-off-by: Alessandro Boch <aboch@docker.com>
- Initial version
- It allows handling reservation/release of a finite set
of resources through large bitmask.
- It represents the bitmask as a list of equal
consecutive 32 bits long bitmask symbols.
It basically operates on a run-length encoding
of the bitmask without encode/decode processing.
Signed-off-by: Alessandro Boch <aboch@docker.com>
1. replaced --net option for service UI with SERVICE.[NETWORK] format
2. Making using of the default network/driver backend support
3. NetworkName and NetworkType from the UI/API can be empty string
and it will be replaced with DefaultNetwork and DefaultDriver
As per the design goals, we wanted to keep libnetwork core free of
handling defaults. Rather, the clients (docker & dnet) must handle the
defaultness of these entities.
Also, since there is no API to get these Default values from the
backend, UI will not handle the default values either. Hence, this falls
under the responsibility of the API layer to handle this specific case.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Since the Config is a read-only entity, Confg() method returned a value
instead of the pointer. In cases the config is nil, we should return an
empty config.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
The configuration format for docker runtime is based on daemon flags and
hence adjusting the libnetwork configuration to accomodate it by moving
the TOML based configuration to the dnet tool.
Also changed the controller configuration via options
Signed-off-by: Madhu Venugopal <madhu@docker.com>
* When userland-proxy is disabled, enable hairpin mode on the host-side of the veth
* When userland-proxy is enabled, fix the iptable rules appropriately
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Currently store makes use of a static isReservedNetwork check to decide
if a network needs to be stored in the distributed store or not. But it
is better if the check is not static, but be determined based on the
capability of the driver that backs the network.
Hence introducing a new capability mechanism to the driver which it can
express its capability during registration. Making use of first such
capability : Scope. This can be expanded in the future for more such cases.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
* Removed network from being marshalled (it is part of the key anyways)
* Reworked the watch function to handle container-id on endpoints
* Included ContainerInfo to be marshalled which needs to be synchronized
* Resolved multiple race issues by introducing data locks
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Currently we craete container mac address completely
randomly. But we probably need to generate based on
IP so that the mac address stays the same for a given
IP.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Unless it is a forbidden error, libnetwork should not fail a forced
delete of a network and endpoint if the driver throws an error.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
