diff options
Diffstat (limited to 'platformdoc/docs/concepts')
| -rw-r--r-- | platformdoc/docs/concepts/clamp.md | 8 | ||||
| -rw-r--r-- | platformdoc/docs/concepts/dti.md | 10 | ||||
| -rw-r--r-- | platformdoc/docs/concepts/on_sd.md | 52 | ||||
| -rw-r--r-- | platformdoc/docs/concepts/policy.md | 8 | ||||
| -rw-r--r-- | platformdoc/docs/concepts/service-designer.md | 8 |
5 files changed, 86 insertions, 0 deletions
diff --git a/platformdoc/docs/concepts/clamp.md b/platformdoc/docs/concepts/clamp.md new file mode 100644 index 00000000..f2eec839 --- /dev/null +++ b/platformdoc/docs/concepts/clamp.md @@ -0,0 +1,8 @@ + +# Closed Loop / CLAMP + +Closed Loop is a concept where when certain conditions are observed in the network by a component, messages are sent to a particular controller that then responds to those conditions. No manual intervention is needed. Thus the 'loop' is closed automatically. Closed Loop services are configured in the CLAMP UI, which is a non-DCAE component. + +There is no specific configuration in the component specification for closed loop services, and currently it is a manual process between the developer and the CLAMP support team, to discuss which configuration parameters are affected. These parameters can also be policy editable. + +Refer to the [Configuration Grid](/components/component-specification/configuration-grid) for more information. diff --git a/platformdoc/docs/concepts/dti.md b/platformdoc/docs/concepts/dti.md new file mode 100644 index 00000000..4af71187 --- /dev/null +++ b/platformdoc/docs/concepts/dti.md @@ -0,0 +1,10 @@ + +# DTI (DCAE Topology Interface) Reconfiguration + +Services that support DTI Reconfiguration are installed (with input provided by a DESIGNER (via SDC UI) or Operations (via Dashboard) to indicate which `vnfType-vnfFuncId` is to be processed by that service. When deployed, the service run but does not collect data until a DTI Event comes in. + +Whenever a network event occurs, resulting in the deployment or undeployment of a `vnfType-vnfFuncId`, it is recorded in A&AI and reported to the DTI Topology VM. The DTI Event is then received by the DTI HANDLER, which uses its values to retrieve one or more reconfiguration blueprints from INVENTORY, and then uploads those blueprint(s) to CLOUDIFY MANAGER. It then creates deployment(s) from those blueprint(s), populates them with the DTI Event values (as inputs), and then executes the install workflow on those deployment(s). + +The platform then executes the reconfigure script (configured in the Auxilary section of the component specification), passing the entire DTI Event to the component. The component can process the individual event or make a call to the CONFIG BINDING SERVICE to retrieve all of the vnfType-vnfFuncIds that are to be processed by the service. + +Refer to the [DTI Reconfiguration](/components/component-specification/docker-specification/#dti-reconfiguration) for more information. diff --git a/platformdoc/docs/concepts/on_sd.md b/platformdoc/docs/concepts/on_sd.md new file mode 100644 index 00000000..5e6a2f20 --- /dev/null +++ b/platformdoc/docs/concepts/on_sd.md @@ -0,0 +1,52 @@ +NOTE: THIS PAGE IS A STUB RIGHT NOW. NEEDS EDITING AND WORK. + +# CDAP Cuda Service discovery example. + +NOTE: The below URLs were temporary when the app was deployed, they are no longer valid. +However you can re-create all of this using the commands in https://codecloud.web.att.com/projects/ST_DCAECNTR/repos/dcae_cli_cdap_examples/browse/cuda. + +I deployed CUDA and got back the instance name: b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com. + +If another DCAE service component, like a collector or downstream analytics, were to perform a service lookup on this CUDA app, they would eventually get back a broker URL: http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com + +Which returns a JSON that looks like this: + +``` +{ + "appname":"b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com", + "namespace":"cuda", + "healthcheckurl":"http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com/healthcheck", + "metricsurl":"http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com/metrics", + "url":"http://135.205.226.76:32773/application/b30b7b640fa14539890efa768b4649a2.70900c87-1c82-4690-a0b1-e0aa72cbab84.0-4-1.cdap-cuda.rework-central.dcae.ecomp.att.com", + "connectionurl":"http://135.205.226.110:11015/v3/namespaces/cuda/streams/cuda_appInputStream", + "serviceendpoints":[ + { + "url":"http://135.205.226.110:11015/v3/namespaces/cuda/apps/b30b7b640fa14539890efa768b4649a270900c871c824690a0b1e0aa72cbab84041cdapcudareworkcentraldcaeecompattcom/services/cuda_appOutputDataQuery/methods/allrows", + "method":"GET" + }, + { + "url":"http://135.205.226.110:11015/v3/namespaces/cuda/apps/b30b7b640fa14539890efa768b4649a270900c871c824690a0b1e0aa72cbab84041cdapcudareworkcentraldcaeecompattcom/services/cuda_appOutputDataQuery/methods/lastrow", + "method":"GET" + } + ] +} +``` + +There are important service discovery keys in this JSON. The first is connectionurl. That is the full URL to this application’s stream. The collector can POST data to that URL. + +The second important key is serviceendpoints. These are formed using the information found in the spec. These are, again like connectionurl, full URIs that point to the actual data service. You can try hitting one of those in your browser: http://135.205.226.110:11015/v3/namespaces/cuda/apps/b30b7b640fa14539890efa768b4649a270900c871c824690a0b1e0aa72cbab84041cdapcudareworkcentraldcaeecompattcom/services/cuda_appOutputDataQuery/methods/allrows + +And you will get back the output: +``` +[ + { + "[0]":"{\"start\": 1, \"engagements\": [{\"transcript\": [{\"type\": \"chat.scriptlineSent\", \"senderId\": \"ss754c\", \"content\": \"My SSN is $Identity.ssn. $Identity.name, Thanks for choosing AT\u0026T. My name is $Identity.name and I will be happy to assist you with our plans and services.\", \"iso\": \"2016-05-31T21:59:55-07:00\", \"timestamp\": 1464757195034, \"senderName\": \"agent\"}], \"engagementID\": \"744878782903999181\"}], \"numFound\": 1}" + } +] +``` +This is what we call “service discovery”. A component wants to know how to connect to an application and all they know is that applications name. Through a series of HTTP calls which I’m glossing over here, they eventually get back the URL I showed above which returns that JSON containing all important URLs associated with that application. + +When DMaaP is introduced, this conversation is going to change. In that case, instead of discovering an application directly, you may instead discover a feed that feeds into/out of that app. + + + diff --git a/platformdoc/docs/concepts/policy.md b/platformdoc/docs/concepts/policy.md new file mode 100644 index 00000000..3838dc22 --- /dev/null +++ b/platformdoc/docs/concepts/policy.md @@ -0,0 +1,8 @@ + +# Policy (not yet implemented) + +Policy is a concept where certain configuration is specified as being 'set' by Operations via a Policy UI. + +The specific configuration that represents Policy for a given service is designated in the component specification as `policy_editable`, and has a `policy_schema` defined. At any time thereafter, the values can be set in the POLICY UI. Once set, POLICY HANDLER will update the values in CONSUL. If the component is running, it will notify the component that it's policy has changed, and the component will call the CONFIG BINDING SERVICE to obtain a current set of its configuration. + +Refer to the [Configuration Grid](/components/component-specification/configuration-grid) for more information. diff --git a/platformdoc/docs/concepts/service-designer.md b/platformdoc/docs/concepts/service-designer.md new file mode 100644 index 00000000..5f45f318 --- /dev/null +++ b/platformdoc/docs/concepts/service-designer.md @@ -0,0 +1,8 @@ + +# Service Design + +Service Design is a concept where the `Service Designer` role uses the `Service Design and Creation (SDC) Tool to compose and services from available components. In doing so, the Service Designer will need to provide certain input that is required by those components. + +The specific configuration that represents input that at Service Designer can provide is designated in the component specification as `designer_editable`. + +Refer to the [Configuration Grid](/components/component-specification/configuration-grid) for more information. |