Add the Netplugin design doc

[mapuri]

No description provided.

[mapuri]

@jainvipin, I have posted the first draft of design spec for Netplugin. Kindly review and let me know your comments.

[lexlapax]

I'll add input as separate comments..

in the "Endpoint" section,
Is there a reason to call a group of endpoints a "network" rather than "Endpoint Group"?
As I was reading the definition of "network" in this context, it describes a group of endpoints that are able to communicate with each other, not specifically anything at L2, or L3. In some sense, it's almost a policy..

Now this does bring up the question around policies, however that can be dealt with at the management function level, and not deal with it here. (as an eg, openstack neutron group policy extension chose to go the route of combining policies with endpoint definitions, and hence the word "endpoint group" was changed to "policy target group") .. In this projects case, there's probably no reason to avoid the phrase "endpoint group".

[lexlapax]

One of things that I was thinking about was actually putting in examples of desired state for networking containers together. The purpose behind the examples would be two fold: a) highlight real world use cases, b) and how the netplugin framework may help you get there..

A couple of example desired state may be:

a) an end-user (non-admin) driven deployment of containers that describes the desired connectivity between his/her containers, and the networking happens behind the scenes ( using management software such as kubernetes , mesos, or even swarm )

b) a highly multi-tenant container deployment /runtime environment, where the boundaries of tenancy are defined by groups of containers (pods, mesos frameworks, whatever) and their associated resources and metadata rather than by a VM/host based multi-tenancy as it exists in the openstack world.
...

These are just the start of examples .. let me know if it makes sense, and I can create SVGs to describe different end-state deployment examples where netplugin would have to provide value.

[lexlapax]

I'll also take a stab at correcting minor typos for the design doc, and maybe rewriting some sentences to make the concepts clearer.. and see if I can submit a pull request for that.

[lexlapax]

In the "High Level Design" section,
An implied third option for deployment, even though possible with the current design, is not explicitly stated and probably can be stated.

Computer management with netplugin CLI based Interface
wherein a management function / agent may call a CLI command (e.g. netdcli) instead of calling the network/rest api.

---

| Managenment Function (Central command control)
|
|--------------------------------------
|
V_______________
| Server/Switch (in a managed cluster)
| _______________________________________
| | Management Function (agent)
| |______________________________________
| |
| V________________________
| | Netplugin CLI command (agent)
| |______________________________________
| |
| V________________________
| | Netplugin Daemon (Management function's network interface implementation)
| | | __________________________
| | --> |
| | | Plugin ______________ __________________
| | | --> | |
| | | | Driver --> | Network Function
| --------------------------------------- |
|
|----------------------------------------

[mapuri]

@lexlapax, thanks for the review. I have replied to multiple comments in one shot below, hope that is ok.

Is there a reason to call a group of endpoints a "network" rather than "Endpoint Group"?

Yeah, this is to get to definition of basic constructs that leads to the ultimate definition and implementation of the Netplugin core API i.e. the Interfaces. Note that this terminology is independent of the implementations like L2, L3 (networking centric) or policy groups (management centric). We can call it endpoint-group as well but network seemed more intuitive to describe grouping of endpoints based on a pattern i.e. communication. Endpoint-group leaves that to be a bit vague.

One of things that I was thinking about was actually putting in examples of desired state for networking containers together. ...... let me know if it makes sense, and I can create SVGs to describe different end-state deployment examples where netplugin would have to provide value.

Thanks, yes it does makes sense to document use cases for Netplugin. But I am not sure if a design document is the right place. Care to write and contribute a use case writeup instead? I would be happy to help with inputs where needed.

I'll also take a stab at correcting minor typos for the design doc, and maybe rewriting some sentences to make the concepts clearer.. and see if I can submit a pull request for that

sure, appreciate the help!

Computer management with netplugin CLI based Interface
wherein a management function / agent may call a CLI command (e.g. netdcli) instead of calling the network/rest api.

Well using a CLI as an interface is certainly possible but as of now I haven't envisioned a cli interface for Netplugin itself, since with current design it integrates with management function at the northbound and is invoked indirectly through the management function's UI (which could be REST, CLI or even RPC). Example. The netdcli mimics a management function UI and the netplugin binary mimics the daemon-based implementation that calls into the Plugin Interface of the Netplugin based on certain triggers like docker and etcd events.