diff options
author | VENKATESH KUMAR <vv770d@att.com> | 2020-04-02 23:39:28 -0400 |
---|---|---|
committer | VENKATESH KUMAR <vv770d@att.com> | 2020-04-02 23:48:26 -0400 |
commit | c790dcb3bbd3c498e0f838837c212ce185e70da5 (patch) | |
tree | cbde7e82480efbdc3a26844e2e03bf4806aeaaa8 /platformdoc/docs/architecture | |
parent | cfb11090aa5fbcb7d38870cdeeb7c21e48b077df (diff) |
dcae doc cleanup
Remove old markdown platform doc
Change-Id: I592775a24d17d7d786708cde008703f4d899946c
Signed-off-by: VENKATESH KUMAR <vv770d@att.com>
Issue-ID: DCAEGEN2-1891
Signed-off-by: VENKATESH KUMAR <vv770d@att.com>
Diffstat (limited to 'platformdoc/docs/architecture')
-rw-r--r-- | platformdoc/docs/architecture/pieces.md | 7 | ||||
-rw-r--r-- | platformdoc/docs/architecture/service-discovery.md | 15 | ||||
-rw-r--r-- | platformdoc/docs/architecture/services.md | 11 |
3 files changed, 0 insertions, 33 deletions
diff --git a/platformdoc/docs/architecture/pieces.md b/platformdoc/docs/architecture/pieces.md deleted file mode 100644 index 7787359f..00000000 --- a/platformdoc/docs/architecture/pieces.md +++ /dev/null @@ -1,7 +0,0 @@ -# Platform technologies - -* [Cloudify](http://getcloudify.org/) -* [Consul](https://www.consul.io/) -* [Docker](https://www.docker.com/) -* [CDAP](https://cdap.io/) -* [Registrator](https://github.com/gliderlabs/registrator) diff --git a/platformdoc/docs/architecture/service-discovery.md b/platformdoc/docs/architecture/service-discovery.md deleted file mode 100644 index 9831efcf..00000000 --- a/platformdoc/docs/architecture/service-discovery.md +++ /dev/null @@ -1,15 +0,0 @@ -# Service Discovery - -Service discovery is an architecture pattern used for components (micro-services) to locate each other. The DCAE platform uses [server-side discovery](http://microservices.io/patterns/server-side-discovery.html) and is using [Consul](https://www.consul.io/) as the service registry solution. - -## Service Registration - -All components are required to register with Consul in order to be discovered. There are two methods of registration: self and 3rd party. The DCAE platform uses 3rd party registration which means components don't actually make the registration calls but defers that responsibility to a platform service. - -### Implementation for Docker - -[Registrator](http://gliderlabs.com/registrator/latest/) is an open source application that is responsible for registering all components that run as Docker containers. Registrator watches the local Docker engine's activity log and will register and unregister a Docker container when the container is started and stopped. - -### Implementation for CDAP - -The CDAP broker is a REST web service that is responsible for registering all components that run as CDAP applications. diff --git a/platformdoc/docs/architecture/services.md b/platformdoc/docs/architecture/services.md deleted file mode 100644 index f17f563b..00000000 --- a/platformdoc/docs/architecture/services.md +++ /dev/null @@ -1,11 +0,0 @@ -# 'Services' Overview - -DCAE Services run on the DCAE platform. A service either monitors the virtualized network services or does analytics. A service is composed of one or more components, and performs a business need. - -Services are created in a 'Service Design and Creation' tool called 'Service Assurance Flow Designer' by a Service Designer. This is done by - -* 'compose'ing a service from the available SDC catalog components (actually from the TOSCA models representing the components), then -* 'submit'ing the service, which generates a Cloudify blueprint, which is then automatically uploaded to INVENTORY, and then deployed by DEPLOYMENT HANDLER (and CLOUDIFY) (once a DTI Event is triggered for the service). It should be noted that some service flows, specifally 'closed-loop' flows, are not initiated by DTI, but are done by CLAMP. - -Only a few services are supported in SDC so far, and therefore steps above are done manually by the Onboarding Team for most services. - |