...

Internal Implementation Details

NOTE - Current implementation will support the ISTIO service mesh technology and SD-WAN load balancer and ExternalDNS as DNS provider.  The plugin architecture of the controller makes it extensible to work with any Service mesh technology and any external load balancer as well. It is also designed to configure and communicate with external DNS servers. 

JIRA

...

1. Gateways - The inbound/outbound access for the service mesh. It is an envoy service
2. VirtualServices -  To expose the service outside the service mesh
3. DestinationRule - To apply rules for the traffic flow
4. AuthorizationPolicy - Authorization for service access
5. serviceEntry - add Add an external service into the mesh
6. Authentication Policy - Authenticate external communication

...

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-intent-set
POST BODY:
{
	"name": "john",
	"description": "Traffic intent groups"
    "set":[
      {
         "us-to-us":"abc"
      },
      {
         "inbound":"abc"
      },
      {
         "outbound":"abc"
      }
   ]
}

1.

...

POST

...

...

Inbound access 

POST

URL: /v2/projects/{project-name}/composite-apps/blue-app/{version}/traffic-intent-set/us-toinbound-us-intents/

POST BODY:
{
	"metadata": {
	"name": "servicehttpbin<>" // unique name for each intent
    "description": "connectivity intent for micro-service to micro-serviceinbound communication"
	"userdata1": <>,
	"userdata2": <>
	}

	"spec": { // update the memory allocation for each field as per OpenAPI standards
	"application": "<app1>",
	"servicename": "httpbin01httpbin" //actual name of the client service - {istioobject - serviceEntry of client's cluster}
	"protocolexternalName": "HTTPhttpbin.k8s.com",
	"headlesstraffic-weeight": "false", // defaultDefault is false"". OptionUsed "True"for willredirecting maketraffic surepercentage allwhen thecompound instances API is called
	"protocol": "HTTP",
	"headless": "false", // default is false. Option "True" will make sure all the instances of the headless service will have access to the client service
	"mutualTLS": "MUTUAL", // Supportdefault 2is modessimple. SIMPLE,Option MUTUAL withwill externalenforce client.mtls For{istioobject inter- and intra cluster, mtls is enabled by default
	destinationRule}
	"port" : "80", // port on which service is exposed as through servicemesh, not the port it is actually running on
	"serviceMesh": "istio", // get it from cluster record

	// Traffic
configuration
	"loadbalancingTypesidecar-proxy": "ConsistenHashyes", // "Simple"The and "consistentHash" are the two modes
	"loadBalancerMode": "httpCookie" // Modes for consistentHash - "httpHeaderName", "httpCookie", "useSourceIP", "minimumRingSize", Modes for simple - "LEAST_CONN", "ROUND_ROBIN", "RANDOM", "PASSTHROUGH" // choices of the mode must be explicit
	"httpHeader": john-user // Input for the hash when in "consistentHash" LB type and mode as "httpHeader"
	"httpCookie": user // Input for Hash in "ConsistenHash" LB and mode as "httpCookie" . Name of the cookie to maitain stick sessions.
	"maxConnections": 10 //connection pool for tcp and http traffic
	"timeOut" : 5 // in Seconds. Connection timeout for tcp and idleTimeout for http

	// credentials for mTLS
	"Servicecertificate" : {serverCertificate.pem} // Present actual certificate here. Optional, default "", required only if mTLS is set to "MUTUAL"
	"ServicePrivateKey" : {serverPrivateKey.pem} // Present actual private key here. Required only if mTLS is "MUTUAL"
	"caCertificate": {caCertificate.pem} // file should contain the public certificates for all root CAs that is trusted to authenticate your clients // not required for cluster level communication 
	
	}
}

RETURN STATUS: 201
RETURN BODY: 
{ 
  "name": "servicehttpbin"
  "Message": "Inbound service created"
}

GET

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-intent-set/uservice-to-uservice-intent/servicehttpbin

RETURN STATUS: 201
RETURN BODY:
{
	"metadata":{
	"name": "servicehttpbin" //unique name for each intent
    "description": "connectivity intent for micro-service to microservice communication" 
	}

	spec:{	 
	"inboundservicename": "httpbin01" //actual name of the client service 
	"protocol": "HTTP",
	"headless": "false", // default is false. Option "True" will make sure all the instances of the headless service will have access to the client service
	"mutualTLS": "MUTUAL", // Support 2 modes. SIMPLE, MUTUAL with external client. For inter and intra cluster, mtls is enabled by default
	"port" : "80", // port on which service is exposed as through servicemesh, not the port it is actually running on
	"serviceMesh": "istio", // get it from cluster record

	// Traffic configuration
	"loadbalancingType": "ConsistenHash", // "Simple" and "consistentHash" are the two modes
	"loadBalancerMode": "httpCookie" // Modes for consistentHash - "httpHeaderName", "httpCookie", "useSourceIP", "minimumRingSize", Modes for simple - "LEAST_CONN", "ROUND_ROBIN", "RANDOM", "PASSTHROUGH"
	"httpHeader": x-user // Input for the hash when in "consistentHash" LB type and mode as "httpHeader"
	"httpCookie": user // Input for Hash in "ConsistenHash" LB and mode as "httpCookie" . Name of the cookie to maitain stick sessions.
	"maxConnections": 10 //connection pool for tcp and http traffic
	"timeOut" : 5 // in Seconds. Connection timeout for tcp and idleTimeout for http
	
	// credentials for mTLS
	"Servicecertificate" : {serverCertificate.pem} // Present actual certificate here. Optional, default "", required only if mTLS is set to "MUTUAL"
	"ServicePrivateKey" : {serverPrivateKey.pem} // Present actual private key here. Required only if mTLS is "MUTUAL"
	"caCertificate": {caCertificate.pem} // file should contain the public certificates for all root CAs that is trusted to authenticate your clients // not required for cluster level communication
	}
}

DELETE 

DELETE
URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/uservice-to-uservice-intent/servicehttpbin

RETURN STATUS: 204

POST - with the client details

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/uservice-to-uservice-intent/clients
POST BODY:

{
		"clientServiceName": "sleep01",features (mTLS, LB, Circuit breaking) are not available to services without istio-proxy. Only inbound routing is possible.
	// Traffic management fields below are valid only if the sidecar-proxy is set to "yes"
	"traffic-management-info" : {
	// Traffic configuration - Loadbalancing is applicable per service. The traffic to this service is distrbuted amongst the pods under it.
	"loadbalancingType": "ConsistenHash", // "Simple" and "consistentHash" are the two modes - {istioobject - destinationRule}
	"loadBalancerMode": "httpCookie" // Modes for consistentHash - "httpHeaderName", "httpCookie", "useSourceIP", "minimumRingSize", Modes for simple - "LEAST_CONN", "ROUND_ROBIN", 	"RANDOM", "PASSTHROUGH" // choices of the mode must be explicit - {istioobject - destinationRule}
	"httpCookie": "user1" // Name of the cookie to maitain sticky sessions - {istioobject - destinationRule}

	// Circuit Breaking
	"maxConnections": 10 //connection pool for tcp and http traffic - {istioobject - destinationRule}
	"concurrenthttp2Requests": 1000 // concurent http2 requests which can be allowed - {istioobject - destinationRule}
	"httpRequestPerConnection": 100 // number of http requests per connection. Valid only for http traffic - {istioobject - destinationRule}
	"consecutiveErrors": 8 // Default is 5.  Number of consecutive error before the host is removed - {istioobject - destinationRule}
	"baseEjectionTime" : 15 // Default is 5, - {istioobject - destinationRule}
	"intervalSweep": 5m, //time limit before the removed hosts are added back to the load balancing pool. - {istioobject - destinationRule}
	}

	// credentials for mTLS.
	"Servicecertificate" : "" // Present actual certificate here.
	"ServicePrivateKey" : "" // Present actual private key here.
	"caCertificate" : "" // present the trusted certificate to verify the client connection, Required only when mtls mode is MUTUAL	
	}
}

RETURN STATUS: 201
RETURN BODY: 
{ 
  "name": "<name>"
  "Message": "inbound service created"
}

GET

URL: /v2/projects/{project-name}/composite-apps/blue-app/{version}/traffic-intent-set/inbound-intents/<name>

RETURN STATUS: 201
RETURN BODY:
{
	"metadata": {
	"name": "<>" // unique name for each intent
    "description": "connectivity intent for stateless micro-service to stateless micro-service communication"
	"userdata1": <>,
	"userdata2": <>
	}

	"spec": { // update the memory allocation for each field as per OpenAPI standards
	"application": "<app1>",
	"servicename": "<>" //actual name of the client service - {istioobject - serviceEntry of client's cluster}
	"externalName": "<>" // prefix to expose this service outside the cluster
	"protocol": "", // supported protocols are HTTP, TCP, UDP and HTTP2
	"headless": "", // default is false. Option "True" will make sure all the instances of the headless service will have access to the client service
	"mutualTLS": "", // default is simple. Option MUTUAL will enforce mtls {istioobject - destinationRule}
	"port" : "80", // port on which service is exposed as through servicemesh, not the port it is actually running on
	"serviceMesh": "istio", // get it from cluster record
	"sidecar-proxy": "yes", // The features (mTLS, LB, Circuit breaking) are not available to services without istio-proxy. Only inbound routing is possible.

	/ Traffic management fields below are valid only if the sidecar-proxy is set to "yes"
	"traffic-management-info" : {
		// Traffic configuration - Loadbalancing is applicable per service. The traffic to this service is distrbuted amongst the pods under it.
		"loadbalancingType": "", // "Simple" and "consistentHash" are the two modes - {istioobject - destinationRule}
		"loadBalancerMode": "" // Modes for consistentHash - "httpHeaderName", "httpCookie", "useSourceIP", "minimumRingSize", Modes for simple - "LEAST_CONN", "ROUND_ROBIN", 	"RANDOM", "PASSTHROUGH" // choices of the mode must be explicit - {istioobject - destinationRule}
		"httpCookie": "user1" // Name of the client service.cookie to maitain sticky sessions - {istioobject - destinationRule}

		// Circuit Breaking
		"headlessmaxConnections": "true", //connection defaultpool isfor false.tcp Optionand "True"http willtraffic generate- the{istioobject required configs for all the instances of headless service- destinationRule}
		"egressgatewayconcurrenthttp2Requests": "true" ,  // Optional, default = false, All the outbound traffic from this service will flow through a dedicated egress gateway
}

RETURN STATUS: 201
RETURN BODY:
{ 
  "name": "sleep01"
  "Message": "Client created"
}

GET -  The Client resource

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/uservice-to-uservice-intent/clients/sleep01
RETURN STATUS: 201
RETURN BODY:

	"clientService": {
		"clientServiceName": "sleep01", // if any then allow all the external applications to connect, check for serviceaccount level access
		"headless": "true", // default is false. Option "True" will generate the required configs for all the instances of headless service
		"egressgateway": "true" ,  // Optional, default = false, All the outbound traffic from this service will flow through a dedicated egress gateway
		
	 }

DELETE

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/uservice-to-uservice-intent/clients/sleep01

RETURN STATUS: 204

Security Resource

POST

concurent http2 requests which can be allowed - {istioobject - destinationRule}
		"httpRequestPerConnection": "" // number of http requests per connection. Valid only for http traffic - {istioobject - destinationRule}
		"consecutiveErrors": "" // Default is 5.  Number of consecutive error before the host is removed - {istioobject - destinationRule}
		"baseEjectionTime" : "" // Default is 5, - {istioobject - destinationRule}
		"intervalSweep": '', //time limit before the removed hosts are added back to the load balancing pool. - {istioobject - destinationRule}
		}	

	// credentials for mTLS.
	"Servicecertificate" : "" // Present actual certificate here.
	"ServicePrivateKey" : "" // Present actual private key here.
	"caCertificate" : "" // present the trusted certificate to verify the client connection, Required only when mtls mode is MUTUAL

	// Access Control
	"namespaces": [] // Workloads from this namespaces can access the inbound service - {istioobject - authorizationPolicy}
	"serviceAccountAccess" : {[ "SaDetails": ["ACTION": "URI"]} // {istioobject - authorizationPolicy, will be applied for the inbound service}
	
	}
}

DELETE 

DELETE
URL: /v2/projects/{project-name}/composite-apps/{compositeblue-app-name}/{version}/traffic-groupintent-intentset/uservice-to-uservice-intent/clients/sleep01/security/security-intent

{
	
	"userAccess": [{userName: "Todd", accessList:Action:["/health_check": GET, "/status/: GET, "/upload": POST]}, {userName: "Thor", accessList:["/health_check": GET, "/status/: GET, "/upload": POST]} ] // These are the user in k8s
}


RETURN STATUS: 204

Traffic Resource??

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/uservice-to-uservice-intent/clients/sleep01/traffic/traffic-intent

{
	
	
}

RETURN STATUS: 204

The above intent will generate the following configuration provided the service mesh is istio.

...

1. Cluster01

...

1. serviceentry - "sleep01"
2. destinationrules- loadbalancing, mTLS,
3. virtualservice - "externalName" 
4. authentication policy - authentication for intracluster services
5. Authentication Policy - External user authentication

...

1. egressgateway - if "true", create service
2. destinationrules - direct traffic from service to egressgateway
3. headless - create virtualservices per instance of headless service

NOTE - The default authorization policy must have with "deny-all" under spec as we need to disable all the communication between microservices during istio installation

2. External service to access Inbound service - Inbound access

NOTE - These are the services whose nature is not known. These services are assumed to have FQDN as a point of connectivity

POST

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/inbound-intent/
POST BODY:
{
	"name": <name> //unique name for each intent
    "description": <description> 
	"inboundservicename": "mysql" //actual name of the client service
	"description": "bookinfo app", 
	"protocol": "HTTP",
	"externalName": "", // Optional, default = "", Not required for Outbound access since the communication will be initialted from inboundservice
	"headless": "false", // default is false. Option "True" will make sure all the instances of the headless service will have access to the client service
	"mutualTLS": "true", // Setting this to true will create a dedicated egrees gateway for the service "httpbin01" on whichever cluster it is running on
	"port" : "80", // port on which service is exposed as through servicemesh, not the port it is actually running on 
	"serviceMesh": "istio", // get it from cluster record
	"loadbalancing": "true", // optional
}
RETURN STATUS: 201
RETURN BODY: 
{ 
  "Message": "outbound coonectivity intent creation success "
  "description": "Connectivity intent for inbound service to connect to external services"
}

POST -  External service to access inbound service

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/inbound-intent/<intent-name>/clients
POST BODY:
{
	"name": <name> //unique name for each intent
   	"description": <description>
	"externalServiceName": {cnn.edition.com} // Only the FQDN of the service name is required
	"externalCaCertificate" : {clientCaCert.pem} // Present the actual client certificate
}

RETURN STATUS: 201
RETURN BODY: 
{ 
  "Message": "Success "
  "description": "External service given access to inbound service"
}

Security

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/inbound-intent/<intent-name>/clients/client01/security

{
	"name": <name> //unique name for each intent
    "description": <description>
	"externalAuthenticationissuer": "https://accounts.google.com",
    "externalAuthenticationjwksURI" : "https://www.googleapis.com/oauth2/v3/certs",
	"userAccess": [{userName: "Todd", accessList:Action:["/health_check": GET, "/status/: GET, "/upload": POST]}, {userName: "Thor", accessList:["/health_check": GET, "/status/: GET, "/upload": POST]} ] // These are the external users
}


RETURN STATUS: 204

3. Outbound access

POST - 

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/outbound-intent/<intent-name>/clients/


POST BODY:
{
	"name": "<name>" //unique name for each intent
    "description": <description> 
	"inboundservicename": "httpbin01" //actual name of the client service 
	"protocol": "HTTP",
	"headless": "false", // default is false. Option "True" will make sure all the instances of the headless service will have access to the client service
	"mutualTLS": "MUTUAL", // Support 2 modes. SIMPLE, MUTUAL with external client. For inter and intra cluster, mtls is enabled by default
	"port" : "80", // port on which service is exposed as through servicemesh, not the port it is actually running on
	"serviceMesh": "istio", // get it from cluster record
	// Traffic configuration
	"loadbalancingType": "ConsistenHash", // "Simple" and "consistentHash" are the two modes
	"loadBalancerMode": "httpCookie" // Modes for consistentHash - "httpHeaderName", "httpCookie", "useSourceIP", "minimumRingSize", Modes for simple - "LEAST_CONN", "ROUND_ROBIN", "RANDOM", "PASSTHROUGH"
	"httpHeader": x-user // Input for the hash when in "consistentHash" LB type and mode as "httpHeader"
	"httpCookie": user // Input for Hash in "ConsistenHash" LB and mode as "httpCookie" . Name of the cookie to maitain stick sessions.
	"maxConnections": 10 //connection pool for tcp and http traffic
	"timeOut" : 5 // in Seconds. Connection timeout for tcp and idleTimeout for http
	// credentials for mTLS
	"Servicecertificate" : {serverCertificate.pem} // Present actual certificate here. Optional, default "", required only if mTLS is set to "MUTUAL"
	"ServicePrivateKey" : {serverPrivateKey.pem} // Present actual private key here. Required only if mTLS is "MUTUAL"
	"caCertificate": {caCertificate.pem} // file should contain the public certificates for all root CAs that is trusted to authenticate your clients // not required for cluster level communication 
}

RETURN STATUS: 201
RETURN BODY: 
{ 
  "name": "servicehttpbin"
  "Message": "Inbound service created"
}

POST - Provide access to an external service from inbound service

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/inbound-intent/
POST BODY:
	{
		"externalServiceName": {cnn.edition.com} // Only the FQDN of the service name is required
	}

RETURN STATUS: 201
RETURN BODY: 
{ 
  "Message": "Success "
  "description": "External service given access to inbound service"
}

...

...

sub-types in API for {connectivity-sub-type}

...

Development

1. go API library - https://github.com/gorilla/mux
2. backend - mongo - https://github.com/onap/multicloud-k8s/tree/master/src/k8splugin/internal/db - Reference
3. intent to config conversion - use go templates and admiral? https://github.com/istio-ecosystem/admiral
4. writing the config to etcd - WIP
5. Unit tests and Integration test - go tests

External DNS - Design and intent API

See here:  External DNS provider update design and intent API

External application communication intents

Considering DNS resolution,  No DNS resolution (IP addresses), Egress proxies of the Service Mesh, Third-party egress proxy

User facing communication intents

Considering Multiple DNS Servers

Considering multiple user-facing entities

Considering RBAC/ABAC

Internal Design details

Guidelines that need to keep in mind

• Support for metrics that can be retrieved by Prometheus
• Support for Jaeger distributed tracing by including open tracing libraries around HTTP calls.
• Support for logging that is understood by fluentd
• Mutual exclusion of database operations (keeping internal modules accessing database records simultaneously and also by replication entities of the scheduler micro-service).
• Resilience - ensure that the information returned by controllers is not lost as the synchronization of resources to remote edge clouds can take hours or even days when the edge is not up and running and possibility of restart of scheduler micro service in the meantime.
• Concurrency - Support multiple operations at a time and even synchronizing resources in various edge clouds in parallel.
• Performance - Avoiding file system operations as much as possible.

...

inbound-intents/<name>

RETURN STATUS: 204

2. Outbound access

POST - 

URL: /v2/projects/{project-name}/composite-apps/{composite-app-name}/{version}/traffic-group-intent/outbound-intents/
POST BODY:
{
	"metadata": {
	"name": "<name>" // unique name for each intent
    "description": "connectivity intent add client communication"
	"application": "<app1>",
	"userdata1": <>,
	"userdata2": <>
	}

	spec: {
		"clientServiceName": "<>", // Name of the client service
		"type": "", // options are istio, k8s and external
		"inboundServiceName": "<>"
		"headless": "false", // default is false. Option "True" will generate the required configs for all the instances of headless service
	}
}

RETURN STATUS: 201
RETURN BODY:
{ 
  "name": "<name>"
  "Message": "Client created"
}

3. Compound Service access

URL: /v2/projects/{project-name}/composite-apps/blue-app/{version}/traffic-intent-set/compound-intents/

POST BODY:
{
	"metadata": {
	"name": "<>" // unique name for each intent
    "description": "connectivity intent for inbound communication"
	"userdata1": <>,
	"userdata2": <>
	}

	"spec": { 
	"application": "<app1>",
	"externalPrefix": "/canary"
	
	}
}

RETURN STATUS: 201
RETURN BODY: 
{ 
  "name": "<name>"
  "Message": "inbound service created"
}

Note - After the compound intent is created, Call the inbound services under it and make sure you assign the weightage to each service under it. As shown in the below example

URL: /v2/projects/{project-name}/composite-apps/blue-app/{version}/traffic-intent-set/compound-intents/{compoungd-intent-name}/inbound-intents/

POST BODY:
{
	"metadata": {
	"name": "<>" // unique name for each intent
    "description": "connectivity intent for inbound communication"
	"userdata1": <>,
	"userdata2": <>
	}

	"spec": { // update the memory allocation for each field as per OpenAPI standards
	"application": "<app1>",
	"servicename": "httpbin" //actual name of the client service - {istioobject - serviceEntry of client's cluster}
	"externalName": "httpbin.k8s.com"
	"traffic-weight": "50" // Default is "". Used for redirecting traffic percentage when compound API is called
	"protocol": "HTTP",
	"headless": "false", // default is false. Option "True" will make sure all the instances of the headless service will have access to the client service
	"mutualTLS": "MUTUAL", // default is simple. Option MUTUAL will enforce mtls {istioobject - destinationRule}
	"port" : "80", // port on which service is exposed as through servicemesh, not the port it is actually running on
	"serviceMesh": "istio", // get it from cluster record
	"sidecar-proxy": "yes", // The features (mTLS, LB, Circuit breaking) are not available to services without istio-proxy. Only inbound routing is possible.
	// Traffic management fields below are valid only if the sidecar-proxy is set to "yes"
	"traffic-management-info" : {
	// Traffic configuration - Loadbalancing is applicable per service. The traffic to this service is distrbuted amongst the pods under it.
	"loadbalancingType": "ConsistenHash", // "Simple" and "consistentHash" are the two modes - {istioobject - destinationRule}
	"loadBalancerMode": "httpCookie" // Modes for consistentHash - "httpHeaderName", "httpCookie", "useSourceIP", "minimumRingSize", Modes for simple - "LEAST_CONN", "ROUND_ROBIN", 	"RANDOM", "PASSTHROUGH" // choices of the mode must be explicit - {istioobject - destinationRule}
	"httpCookie": "user1" // Name of the cookie to maitain sticky sessions - {istioobject - destinationRule}

	// Circuit Breaking
	"maxConnections": 10 //connection pool for tcp and http traffic - {istioobject - destinationRule}
	"concurrenthttp2Requests": 1000 // concurent http2 requests which can be allowed - {istioobject - destinationRule}
	"httpRequestPerConnection": 100 // number of http requests per connection. Valid only for http traffic - {istioobject - destinationRule}
	"consecutiveErrors": 8 // Default is 5.  Number of consecutive error before the host is removed - {istioobject - destinationRule}
	"baseEjectionTime" : 15 // Default is 5, - {istioobject - destinationRule}
	"intervalSweep": 5m, //time limit before the removed hosts are added back to the load balancing pool. - {istioobject - destinationRule}
	}

	// credentials for mTLS.
	"Servicecertificate" : "" // Present actual certificate here.
	"ServicePrivateKey" : "" // Present actual private key here.
	"caCertificate" : "" // present the trusted certificate to verify the client connection, Required only when mtls mode is MUTUAL	
	}
}

RETURN STATUS: 201
RETURN BODY: 
{ 
  "name": "<name>"
  "Message": "inbound service created"
}

Scenarios supported for the current release

Development

1. go API library - https://github.com/gorilla/mux
2. backend - mongo - https://github.com/onap/multicloud-k8s/tree/master/src/k8splugin/internal/db - Reference
3. intent to config conversion - use go templates and admiral? https://github.com/istio-ecosystem/admiral
4. writing the config to etcd - WIP
5. Unit tests and Integration test - go tests

External DNS - Design and intent API

See here:  External DNS provider update design and intent API

External application communication intents

Considering DNS resolution,  No DNS resolution (IP addresses), Egress proxies of the Service Mesh, Third-party egress proxy

User facing communication intents

Considering Multiple DNS Servers

Considering multiple user-facing entities

Considering RBAC/ABAC

Internal Design details

Guidelines that need to keep in mind

• Support for metrics that can be retrieved by Prometheus
• Support for Jaeger distributed tracing by including open tracing libraries around HTTP calls.
• Support for logging that is understood by fluentd
• Mutual exclusion of database operations (keeping internal modules accessing database records simultaneously and also by replication entities of the scheduler micro-service).
• Resilience - ensure that the information returned by controllers is not lost as the synchronization of resources to remote edge clouds can take hours or even days when the edge is not up and running and possibility of restart of scheduler micro service in the meantime.
• Concurrency - Support multiple operations at a time and even synchronizing resources in various edge clouds in parallel.
• Performance - Avoiding file system operations as much as possible.

Modules (Description, internal structures etc..)

Service Mesh Config:

Main Function:  the module is invoked by traffic controller after traffic controller receives
                          intents from external world, and parses requests from traffic controller and
                          extracts some key information to assemble a new yaml file for creating instances
                          of inbound services and clients based on istio.

Main Operations:

1. create/destroy inbound services (API: Add Inbound service)
2. create/destroy client services (API: Add Clients)
3. create/remove security details for client services (API: Add Security details for clients)
4. create/destroy ServiceEntry for inbound services used by clients
5. create/destroy DestinationRules for both inbound and client services
6. create/destroy VirtualService for client services
7. create/destroy AuthorizationPolicy for inbound services used by clients

The key information includes but not limited:

• client name
• inbound service name
• protocol: http/https/tcp
• TLS options: no/simple/mutual
• port

The interface between SM config and Traffic Controller: maybe via gPRC, and APIs are TBD

Traffic Controller

Main Function:  it acts as main controlling loop/daemon, and receives the request in a form of
                         REST from external modules e.g. orchestrator. Then it parses these requests and
                         figures out the exact purposes which these requests want to express
                         e.g. service creation, DNS update or workload adjust. Afterwards, it invoke corresponding
                         components like SM config, DNS updater, to fulfill these requirements by creating
                         and configuring related uServices based on the various mechanisms of istio.

Main steps:

0. Traffic controller need to be registered in orchestrtor by calling the APIs provided by orchestrtor

1. Orchestrtor starts to instantiate the traffic controller

2. Traffic controller finds the config files about various plugins like SM config,
    Loadbalancers and DNS updater from some certain locations, and then instantiate
    these plugins. Here, these plugins may be defined as istio VirtualService and
    their associated yaml files should be provided beforehand.

3. Traffic controller need to have some health-check about the instances of these
    plugins and make sure they are up and running well(some heath-check criteria
    also need to be defined).

4. Traffic controller may need to notify orchestrator that it, including the plugins,
    is ready to serve (which API provided by orchestrator should be invoked?).

5. At this moment, orchestrator can start to monitor and manage the life-cycle of traffic
    controller. And the way/APIs of monitor and manage need to be clarified.
    (Is HA is required for traffic controller?)

6. Users/admin are allowed to send their request to create uServices or access the running
    uServices directly via REST, like the inbound/client services creation. After traffic controller
    convert the intents to service description, the generated yml files which will be used by istio
    to create uSevices should be given to workload scheduler/placement helper to place and
    instantiate these uService on edge cloud clusters. Namely, traffic controller need to inform
    the workload scheduler/placement helper that there are some uServices to be placed and
    instantiated on edge cloud clusters.

7. Traffic controller need to call DNS module to expose the domain names of services to external world, 
    after it is aware of these uServices have been instantiated on edge cloud clusters. (how is traffic controller 
    aware of the accomplishment of of uServices instantiation?)

8. Traffic controller may need to manage the lifecycle of uServices (or done by some modules within orchestrator?)
    by a way e.g. detecting the heartbeat from various uServices periodically e.g. one check per 10 seconds.

9. Considering the HA, traffic controller should instantiate at least 2 of those plugins, and should be
    able to monitor the health of those instances of plugins. when any of instances is down, traffic controller
    can restart/recreate one for it again.

LoadBalancer (aka GSLB/LB controller?)

GSLB(Geo-replicated Services LB/LB controller) is used to balance incoming load across multiple istio-ingress-gateways.
It shall be able to be aware of the run-time load of various working uService instances which are distributed on different
edge clouds or the general load level of each kind of uService in each edge cloud by interacting with actual LB(e.g. metallb,
or other module except metallb) running on one edge cloud. Metallb is responsible for the load balance jobs between instances
of uService within an edge cloud, while GSLB(controller) shall be in charge of guiding the traffic load to multiple edge clouds.
GSLB(LB controller) should be aware of  the public IPs (achieved by using metallb? or SDWAN?) of all edge clouds. 

GSLB(LB controller) get requests from external users, and it evaluates the load level of the uServices that the user want to access
on various edge clouds, and then choose one certain edge cloud on which the targeted(or a set of) uService instance is running, 
next GSLB returns the domain name of the chosen uService instance to users, so users can utilize this new domain name to access
their expected uService. These steps mentioned above imply that those domain names associated with different uServices distributed
on edge clouds should point to the IP address of center cloud on which GSLB is running first, after GSLB figure out to which edge cloud
the users' request should be forwarded, the real domain name of uServices is given back to users by GSLB.

....

Sequence flows

Test cases

...