modelgen

Object Model

Contiv Object model is defined as a JSON schema (based on http://json-schema.org) and various backend and client libraries are auto generated from the schema.

modelgen tool is the schema compiler that generates various backend and client libraries.

Object model generation

Currently following are generated from the modelgen tool:

• Go backend: This includes the REST API server and object database. This acts as the model and view layers in a model-view-controller architectire.
• Web UI: This includes the javascript views for each object.
• Go client: golang REST client for the objects.
• Python client: python REST client for the objects.

Adding new object

To add a new object simply create new json file in contiv/contivModel repository with all necessary attributes(See below for json schema guide) and run following command:

contivModel$ make build

This will recompile the schema and generate backend and client libraries. To use the newly generated backend or client library, simply include it in your project

import(
    "github.com/contiv/contivModel"
    )

Note: If you are using godep in your project, you need to godep import the updated library into your project

Modifying an existing object

To modify an existing object, just modify the json schema in contiv/contivModel repository and run:

contivModel$ make build

this will update the contivModel/contivModel.go and other client libraries.

Using object model backend

Below is the architecture of contiv model backend as seen by netmaster. In a typical model-view-controller architecture, contivModel acts as the model and view layer. Projects using contiv model only has to write the controller layer.

Auto generated contiv model backend handles the REST APIs, it persists the objects to a distributed KV store(like etcd) and provides callbacks to netmaster's API controller object. API controller object acts as the controller in MVC architecture.

Registering for an object

A controller has to register for callbacks for each object it supports. For example, this is how netmaster's controller object registers for callbacks on all objects it supports

	// initialize the model objects
	contivModel.Init()

	// Register Callbacks
	contivModel.RegisterGlobalCallbacks(ctrler)
	contivModel.RegisterAppCallbacks(ctrler)
	contivModel.RegisterEndpointGroupCallbacks(ctrler)
	contivModel.RegisterNetworkCallbacks(ctrler)
	contivModel.RegisterPolicyCallbacks(ctrler)
	contivModel.RegisterRuleCallbacks(ctrler)
	contivModel.RegisterServiceCallbacks(ctrler)
	contivModel.RegisterServiceInstanceCallbacks(ctrler)
	contivModel.RegisterTenantCallbacks(ctrler)

Object Relation management

One of the common problems faced by most backend systems is expressing relation between objects. A relational database is often used in such cases. Distributed KV stores dont provide a good way to express relationship between objects. Objmodel tries to provide a mechanism similar to graph databases using Links and Linksets.

Links are used for heirarchical relations. E.g. network belongs to a tenant or rule belongs to a policy

Linksets are used for multi-way relations. E.g policy is used by a list of endpointGroups or an app has a list of services

Almost all graph-like relations can be expressed using these two primitives. Links and Linksets are persisted to distributed KV store along with the objects.

In memory cache

ContivModel has an in-memory cache of all objects for higher performance. Controller objects can find these objects using Findxxx() function where xxx refers to the object name. Controller objects can also create/delete objects using Createxxx() or Deletexxx() functions. An in-memory cache of Links and Linksets are also kept and can be accessed using same APIs. While modifying objects in cache, its important to remember that any changes to the object must be written to persistent store using