diff options
Diffstat (limited to 'docs/clamp/controlloop/design-impl')
10 files changed, 2306 insertions, 18 deletions
diff --git a/docs/clamp/controlloop/design-impl/clamp-controlloop-runtime.rst b/docs/clamp/controlloop/design-impl/clamp-controlloop-runtime.rst index 5bea627f..0077b3de 100644 --- a/docs/clamp/controlloop/design-impl/clamp-controlloop-runtime.rst +++ b/docs/clamp/controlloop/design-impl/clamp-controlloop-runtime.rst @@ -5,4 +5,250 @@ The CLAMP Control Loop Runtime ############################## -To be completed. +.. contents:: + :depth: 3 + + +This article explains how CLAMP Control Loop Runtime is implemented. + +Terminology +*********** +- Broadcast message: a message for all participants (participantId=null and participantType=null) +- Message to a participant: a message only for a participant (participantId and participantType properly filled) +- ThreadPoolExecutor: ThreadPoolExecutor executes the given task, into SupervisionAspect class is configured to execute tasks in ordered manner, one by one +- Spring Scheduling: into SupervisionAspect class, the @Scheduled annotation invokes "schedule()" method every "runtime.participantParameters.heartBeatMs" milliseconds with a fixed delay +- MessageIntercept: "@MessageIntercept" annotation is used into SupervisionHandler class to intercept "handleParticipantMessage" method calls using spring aspect oriented programming +- GUI: graphical user interface, Postman or a Front-End Application + +Design of Rest Api +****************** + +Create of a Control Loop Type ++++++++++++++++++++++++++++++ +- GUI calls POST "/commission" endpoint with a Control Loop Type Definition (Tosca Service Template) as body +- CL-runtime receives the call by Rest-Api (CommissioningController) +- It saves to DB the Tosca Service Template using PolicyModelsProvider +- if there are participants registered, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) + +Delete of a Control Loop Type ++++++++++++++++++++++++++++++ +- GUI calls DELETE "/commission" endpoint +- CL-runtime receives the call by Rest-Api (CommissioningController) +- if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message +- the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition +- It deletes the Control Loop Type from DB + +Create of a Control Loop +++++++++++++++++++++++++ +- GUI calls POST "/instantiation" endpoint with a Control Loop as body +- CL-runtime receives the call by Rest-Api (InstantiationController) +- It validates the Control Loop +- It saves the Control Loop to DB +- Design of an update of a Control Loop +- GUI calls PUT "/instantiation" endpoint with a Control Loop as body +- CL-runtime receives the call by Rest-Api (InstantiationController) +- It validates the Control Loop +- It saves the Control Loop to DB + +Delete of a Control Loop +++++++++++++++++++++++++ +- GUI calls DELETE "/instantiation" endpoint +- CL-runtime receives the call by Rest-Api (InstantiationController) +- It checks that Control Loop is in UNINITIALISED status +- It deletes the Control Loop from DB + +"issues control loop commands to control loops" ++++++++++++++++++++++++++++++++++++++++++++++++ + +case **UNINITIALISED to PASSIVE** + +- GUI calls "/instantiation/command" endpoint with PASSIVE as orderedState +- CL-runtime checks if participants registered are matching with the list of control Loop Element +- It updates control loop and control loop elements to DB (orderedState = PASSIVE) +- It validates the status order issued +- It triggers the execution to send a broadcast CONTROL_LOOP_UPDATE message +- the message is built by ControlLoopUpdatePublisher using Tosca Service Template data and ControlLoop data. (with startPhase = 0) +- It updates control loop and control loop elements to DB (state = UNINITIALISED2PASSIVE) + +case **PASSIVE to UNINITIALISED** + +- GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState +- CL-runtime checks if participants registered are matching with the list of control Loop Element +- It updates control loop and control loop elements to DB (orderedState = UNINITIALISED) +- It validates the status order issued +- It triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message +- the message is built by ControlLoopStateChangePublisher with controlLoopId +- It updates control loop and control loop elements to DB (state = PASSIVE2UNINITIALISED) + +case **PASSIVE to RUNNING** + +- GUI calls "/instantiation/command" endpoint with RUNNING as orderedState +- CL-runtime checks if participants registered are matching with the list of control Loop Element. +- It updates control loop and control loop elements to DB (orderedState = RUNNING) +- It validates the status order issued +- It triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message +- the message is built by ControlLoopStateChangePublisher with controlLoopId +- It updates control loop and control loop elements to DB (state = PASSIVE2RUNNING) + +case **RUNNING to PASSIVE** + +- GUI calls "/instantiation/command" endpoint with UNINITIALISED as orderedState +- CL-runtime checks if participants registered are matching with the list of control Loop Element +- It updates control loop and control loop elements to db (orderedState = RUNNING) +- It validates the status order issued +- It triggers the execution to send a broadcast CONTROL_LOOP_STATE_CHANGE message +- the message is built by ControlLoopStateChangePublisher with controlLoopId +- It updates control loop and control loop elements to db (state = RUNNING2PASSIVE) + +StartPhase +********** +The startPhase is particularly important in control loop update and control loop state changes because sometime the user wishes to control the order in which the state changes in Control Loop Elements in a control loop. + +How to define StartPhase +++++++++++++++++++++++++ +StartPhase is defined as shown below in the Definition of TOSCA fundamental Control Loop Types yaml file. + +.. code-block:: YAML + + startPhase: + type: integer + required: false + constraints: + - greater-or-equal: 0 + description: A value indicating the start phase in which this control loop element will be started, the + first start phase is zero. Control Loop Elements are started in their start_phase order and stopped + in reverse start phase order. Control Loop Elements with the same start phase are started and + stopped simultaneously + metadata: + common: true + +The "common: true" value in the metadata of the startPhase property identifies that property as being a common property. +This property will be set on the CLAMP GUI during control loop commissioning. +Example where it could be used: + +.. code-block:: YAML + + org.onap.domain.database.Http_PMSHMicroserviceControlLoopElement: + # Consul http config for PMSH. + version: 1.2.3 + type: org.onap.policy.clamp.controlloop.HttpControlLoopElement + type_version: 1.0.1 + description: Control loop element for the http requests of PMSH microservice + properties: + provider: ONAP + participant_id: + name: HttpParticipant0 + version: 1.0.0 + participantType: + name: org.onap.k8s.controlloop.HttpControlLoopParticipant + version: 2.3.4 + uninitializedToPassiveTimeout: 180 + startPhase: 1 + +How StartPhase works +++++++++++++++++++++ +In state changes from UNITITIALISED → PASSIVE, control loop elements are started in increasing order of their startPhase. + +Example with Http_PMSHMicroserviceControlLoopElement with startPhase to 1 and PMSH_K8SMicroserviceControlLoopElement with startPhase to 0 + +- CL-runtime sends a broadcast CONTROL_LOOP_UPDATE message to all participants with startPhase = 0 +- participant receives the CONTROL_LOOP_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 0) +- CL-runtime receives CONTROL_LOOP_UPDATE_ACT messages from participants and set the state (from the CL element of the message) to PASSIVE +- CL-runtime calculates that all CL elements with startPhase = 0 are set to proper state and sends a broadcast CONTROL_LOOP_UPDATE message with startPhase = 1 +- participant receives the CONTROL_LOOP_UPDATE message and runs to PASSIVE state (only CL elements defined as startPhase = 1) +- CL-runtime calculates that all CL elements are set to proper state and set CL to PASSIVE + +In that scenario the message CONTROL_LOOP_UPDATE has been sent two times. + +Design of managing messages +*************************** + +PARTICIPANT_REGISTER +++++++++++++++++++++ +- A participant starts and send a PARTICIPANT_REGISTER message +- ParticipantRegisterListener collects the message from DMaap +- if not present, it saves participant reference with status UNKNOWN to DB +- if is present a Control Loop Type, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming) +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) +- It triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered +- MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner +- SupervisionScanner starts the monitoring for participantUpdate + +PARTICIPANT_UPDATE_ACK +++++++++++++++++++++++ +- A participant sends PARTICIPANT_UPDATE_ACK message in response to a PARTICIPANT_UPDATE message +- ParticipantUpdateAckListener collects the message from DMaap +- MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_UPDATE_ACK in SupervisionScanner +- SupervisionScanner removes the monitoring for participantUpdate +- It updates the status of the participant to DB + +PARTICIPANT_STATUS +++++++++++++++++++ +- A participant sends a scheduled PARTICIPANT_STATUS message +- ParticipantStatusListener collects the message from DMaap +- MessageIntercept intercepts that event and adds a task to handle PARTICIPANT_STATUS in SupervisionScanner +- SupervisionScanner clears and starts the monitoring for participantStatus + +CONTROLLOOP_UPDATE_ACK +++++++++++++++++++++++ +- A participant sends CONTROLLOOP_UPDATE_ACK message in response to a CONTROLLOOP_UPDATE message. It will send a CONTROLLOOP_UPDATE_ACK - for each CL-elements moved to the ordered state as indicated by the CONTROLLOOP_UPDATE +- ControlLoopUpdateAckListener collects the message from DMaap +- It checks the status of all control loop elements and checks if the control loop is primed +- It updates the CL to DB if it is changed +- MessageIntercept intercepts that event and adds a task to handle a monitoring execution in SupervisionScanner + +CONTROLLOOP_STATECHANGE_ACK ++++++++++++++++++++++++++++ +Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK + +Design of monitoring execution in SupervisionScanner +**************************************************** +Monitoring is designed to process the follow operations: + +- to determine the next startPhase in a CONTROLLOOP_UPDATE message +- to update CL state: in a scenario that "ControlLoop.state" is in a kind of transitional state (example UNINITIALISED2PASSIVE), if all - CL-elements are moved properly to the specific state, the "ControlLoop.state" will be updated to that and saved to DB +- to retry CONTROLLOOP_UPDATE/CONTROL_LOOP_STATE_CHANGE messages. if there is a CL Element not in the proper state, it will retry a broadcast message +- to retry PARTICIPANT_UPDATE message to the participant in a scenario that CL-runtime do not receive PARTICIPANT_UPDATE_ACT from it +- to send PARTICIPANT_STATUS_REQ to the participant in a scenario that CL-runtime do not receive PARTICIPANT_STATUS from it + +The solution Design of retry, timeout, and reporting for all Participant message dialogues are implemented into the monitoring execution. + +- Spring Scheduling inserts the task to monitor retry execution into ThreadPoolExecutor +- ThreadPoolExecutor executes the task +- a message will be retry if CL-runtime do no receive Act message before MaxWaitMs milliseconds + +Design of Exception handling +**************************** +GlobalControllerExceptionHandler +++++++++++++++++++++++++++++++++ +If error occurred during the Rest Api call, CL-runtime responses with a proper status error code and a JSON message error. +This class is implemented to intercept and handle ControlLoopException, PfModelException and PfModelRuntimeException if they are thrown during the Rest Ali calls. +All of those classes must implement ErrorResponseInfo that contains message error and status response code. +So the Exception is converted in JSON message. + +RuntimeErrorController +++++++++++++++++++++++ +If wrong end-point is called or an Exception not intercepted by GlobalControllerExceptionHandler, CL-runtime responses with a proper status error code and a JSON message error. +This class is implemented to redirect the standard Web error page to a JSON message error. +Typically that happen when a wrong end-point is called, but also could be happen for not authorized call, or any other Exception not intercepted by GlobalControllerExceptionHandler. + +Handle version and "X-ONAP-RequestID" +************************************* +RequestResponseLoggingFilter class handles version and "X-ONAP-RequestID" during a Rest-Api call; it works as a filter, so intercepts the Rest-Api and adds to the header those information. + +Media Type Support +****************** +CL-runtime Rest Api supports **application/json**, **application/yaml** and **text/plain** Media Types. The configuration is implemented in CoderHttpMesageConverter. + +application/json +++++++++++++++++ +JSON format is a standard for Rest Api. For the conversion from JSON to Object and vice-versa will be used **org.onap.policy.common.utils.coder.StandardCoder**. + +application/yaml +++++++++++++++++ +YAML format is a standard for Control Loop Type Definition. For the conversion from YAML to Object and vice-versa will be used **org.onap.policy.common.utils.coder.StandardYamlCoder**. + +text/plain +++++++++++ +Text format is used by Prometheus. For the conversion from Object to String will be used **StringHttpMessageConverter**. diff --git a/docs/clamp/controlloop/design-impl/clamp-gui-controlloop.rst b/docs/clamp/controlloop/design-impl/clamp-gui-controlloop.rst index 9064889b..71d0a053 100644 --- a/docs/clamp/controlloop/design-impl/clamp-gui-controlloop.rst +++ b/docs/clamp/controlloop/design-impl/clamp-gui-controlloop.rst @@ -2,7 +2,140 @@ .. _clamp-gui-controlloop: -The CLAMP GUI for Control Loops -############################### +The Policy GUI for Control Loops +******************************** -To be completed. +.. contents:: + :depth: 4 + +.. _Introduction: + +1. Introduction +############### +The Policy GUI for Control Loops is designed to provide a user the ability to interact with the Control Loop Runtime to perform several actions. The actual technical design of the Control Loop Runtime is detailed in :ref:`clamp-controlloop-runtime`. All of the endpoints and the purpose for accessing those endpoints is discussed there. In the current release of the GUI, the main purposes are to perform the below: + +- Commission new Tosca Service Templates. +- Editing Common Properties. +- Priming/De-priming Control Loop Definitions. +- Decommission existing Tosca Service Templates. +- Create new instances of Control Loops. +- Change the state of the Control Loops. +- Delete Control Loops. + +These functions can be carried out by accessing the Controlloop Runtime alone but this should not be required for a typical user to access the system. That is why the Controlloop GUI is required. The remainder of this document will be split into 2 main sections. The first section will show the overall architecture of ControlLoop with the GUI included, so that the reader can see where it fits in to the system. Then the section will outline the individual components required for a working GUI and outline how GUI interacts with these components and why. The final section has a diagram to show the flow of typical operations from the GUI, all the way down to the participants. + +2. GUI-focussed System Architecture +################################### +An architectural/functional diagram has bee provided in below. This does not show details of the other components involved in the GUI functionality. Most of the detail is provided for the GUI itself. + + .. image:: ../images/gui/GUI-Architecture.png + :align: center + +The remainder of this section outlines the different elements that comprise the architecture of the GUI and how the different elements connect to one another. + +2.1 Policy CLAMP GUI +-------------------- + +2.1.1 CLAMP GUI +================ +The original Clamp project used the GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Connection to all of these services is managed by the Camel Exchange present in the section :ref:`Policy Clamp Backend`. + +Class-based react components are used to render the different pages related to functionality around + +- Creating loop instances from existing templates that have been distributed by SDC. +- Deploying/Undeploying policies to the policy framework. +- Deploying/Undeploying microservices to the policy framework. +- Deleting Instances. + +Although this GUI deploys microservices, it is a completely different paradigm to the new ControlLoop participant-based deployment of services. Details of the CLAMP GUI are provided in :ref:`clamp-builtin-label` + +2.1.2 Controlloop GUI +===================== + +The current control loop GUI is an extension of the previously created GUI for the Clamp project. The Clamp project used the CLAMP GUI to connect to various onap services, including policy api, policy pap, dcae, sdc and cds. Although the current control loop project builds upon this GUI, it does not rely on these connected services. Instead, the ControlLoop GUI connects to the ControlLoop Runtime only. The ControlLoop Runtime then communicates with the database and all the ControlLoop participants (indirectly) over DMAAP. + +The CLAMP GUI was originally housed in the clamp repository but for the Istanbul release, it has been moved to the policy/gui repo. There are 3 different GUIs within this repository - clamp-gui (and ControlLoop gui) code is housed under the "gui-clamp" directory and the majority of development takes place within the "gui-clamp/ui-react" directory. + +The original CLAMP GUI was created using the React framework, which is a light-weight framework that promotes use of component-based architecture. Previously, a class-based style was adopted to create the Clamp components. It was decided that ControlLoop would opt for the more concise functional style of components. This architecture style allows for the logical separation of functionality into different components and minimizes bloat. As you can see from the image, there is a "ControlLoop" directory under components where all of our ControlLoop components are housed. + + .. image:: ../images/gui/ComponentFileStructure.png + +Any code that is directly involved in communication with outside services like Rest Apis is under "ui-react/src/api". The "fetch" Javascript library is used for these calls. The ControlLoop service communicates with just the ControlLoop Runtime Rest Api, so all of the communication code is within "ui-react/src/api/ControlLoopService.js". + +2.1.2.1 Services +"""""""""""""""" +The ControlLoop GUI is designed to be service-centric. This means that the code involved in rendering and manipulating data is housed in a different place to the code responsible for communication with outside services. The ControlLoop related services are those responsible for making calls to the commissioning and instantiation endpoints in the ControlLoop Runtime. Another detail to note is that both the ControlLoop and CLAMP GUI use a proxy to forward requests to the policy clamp backend. Any URLs called by the frontend that contain the path "restservices/clds/v2/" are forwarded to the backend. Services are detailed below: + +- A commissioning call is provided for contacting the commissioning API to commission a tosca service template. +- A decommissioning call is provided for calling the decommissioning endpoint. +- A call to retrieve the tosca service template from the runtime is provided. This is useful for carrying out manipulations on the template, such as editing the common properties. +- A call to get the common or instance properties is provided. This is used to provide the user an opportunity to edit these properties. +- Calls to allow creation and deletion of an instance are provided +- Calls to change the state of and instance are provided. +- Calls to get the current state and ordered state of the instances, effectively monitoring. + +These services provide the data and communication functionality to allow the user to perform all of the actions mentioned in the :ref:`Introduction`. + +2.1.2.2 Components +"""""""""""""""""" +The components in the architecture image reflect those rendered elements that are presented to the user. Each element is designed to be as user-friendly as possible, providing the user with clean uncluttered information. Note that all of these components relate to and were designed around specific system dialogues that are present in :ref:`system-level-label`. + +- For commissioning, the user is provided with a simple file upload. This is something the user will have seen many times before and is self explanatory. +- For the edit of common properties, a JSON editor is used to present whatever common properties that are present in the service template to the user in as simple a way possible. The user can then edit, save and recommission. +- A link is provided to manage the tosca service template, where the user can view the file that has been uploaded in JSON format and optionally delete it. +- Several functions are exposed to the user in the "Manage Instances" modal. From there they can trigger, creation of an instance, view monitoring information, delete an instance and change the state. +- Before an instance is created, the user is provided an opportunity to edit the instance properties. That is, those properties that have not been marked as common. +- The user can change the state of the instance by using the "Change" button on the "Manage Instances" modal. This is effectively where the user can deploy and undeploy an instance. +- Priming and De-priming take place as a result of the action of commissioning and decommissioning a tosca service template. A more complete discussion of priming and de-priming is found here :ref:`controlloop-participant-protocol-label`. +- As part of the "Manage Instances" modal, we can monitor the state of the instances in 2 ways. The color of the instance highlight in the table indicates the state (grey - uninitialised, passive - yellow, green - running). Also, there is a monitoring button that allows use to view the individual elements' state. + +.. _Policy Clamp Backend: + +2.2 Policy Clamp Backend +------------------------ +The only Rest API that the ControlLoop frontend (and CLAMP frontend) communicates with directly is the Clamp backend. The backend is written in the Springboot framework and has many functions. In this document, we will only discuss the ControlLoop related functionality. Further description of non-ControlLoop Clamp and its' architecture can be found in :ref:`clamp-builtin-label`. The backend receives the calls from the frontend and forwards the requests to other relevant APIs. In the case of the ControlLoop project, the only Rest API that it currently requires communication with is the runtime ControlLoop API. ControlLoop adopts the same "request forwarding" method as the non-ControlLoop elements in the CLAMP GUI. This forwarding is performed by Apache Camel Exchanges, which are specified in XML and can be found in the directory shown below in the Clamp repository. + + .. image:: ../images/gui/CamelDirectory.png + +The Rest Endpoints for the GUI to call are defined in "clamp-api-v2.xml" and all of the runtime ControlLoop rest endpoints that GUI requests are forwarded to are defined in ControlLoop-flows.xml. If an Endpoint is added to the runtime ControlLoop component, or some other component you wish the GUI to communicate with, a Camel XML exchange must be defined for it here. + +2.3 ControlLoop Runtime +----------------------- +This is where all of the endpoints for operations on ControlLoops are defined thus far. Commissioning, decommissioning, control loop creation, control loop state change and control loop deletion are all performed here. The component is written using the Springboot framework and all of the code is housed in the runtime-ControlLoop directory shown below: + + .. image:: ../images/gui/RuntimeControlloopDirectory.png + +The rest endpoints are split over two main classes; CommissioningController.java and InstantiationController.java. There are also some rest endpoints defined in the MonitoringQueryController. These classes have minimal business logic defined in them and delegate these operations to other classes within the controlloop.runtime package. The ControlLoop Runtime write all data received on its' endpoints regarding commissioning and instantiation to its; database, where it can be easily accessed later by the UI. + +The Runtime also communicates with the participants over DMAAP. Commissioning a control loop definition writes it to the database but also triggers priming of the definitions over DMAAP. The participants then receive those definitions and hold them in memory. Similarly, upon decommissioning, a message is sent over DMAAP to the participants to trigger de-priming. + +Using DMAAP, the Runtime can send; updates to the control loop definitions, change the state of control loops, receive information about participants, receive state information about control loops and effectively supervise the control loops. This data is then made available via Rest APIs that can be queried by the frontend. This is how the GUI can perform monitoring operations. + +More detail on the design of the Runtime ControlLoop can be found in :ref:`clamp-controlloop-runtime`. + +2.4 DMAAP +--------- +DMAAP is comonent that provides data movement services that transports and processes data from any source to any target. It provides the capability to: +- Support the transfer of messages between ONAP components, as well as to other components +- Support the transfer of data between ONAP components as well as to other components. +- Data Filtering capabilities +- Data Processing capabilities +- Data routing (file based transport) +- Message routing (event based transport) +- Batch and event based processing + +Specifically, regarding the communication between the ControlLoop Runtime and the ControlLoop Participants, both components publish and subscribe to a specific topic, over which data and updates from the participants and control loops are sent. The ControlLoop Runtime updates the current statuses sent from the participants in the database and makes them available the the GUI over the Rest API. + +2.5 The Participants +-------------------- +The purpose of the ControlLoop participants is to communicate with different services on behalf of the ControlLoop Runtime. As there are potentially many different services that a ControlLoop might require access to, there can be many different participants. For example, the kubernetes participant is responsible for carrying out operations on a kubernetes cluster with helm. As of the time of writing, there are three participants defined for the ControlLoop project; the policy participant, the kubernetes participant and the http participant. The participants are housed in the directory shown below in the policy-clamp repo. + + .. image:: ../images/gui/ParticipantsDirectory.png + +The participants communicate with the Runtime over DMAAP. Tosca service template specifications, ControlLoop updates and state changes are shared with the participants via messages from runtime ControlLoop through the topic "POLICY-CLRUNTIME-PARTICIPANT". + +3. GUI Sample Flows +################### +The primary flows from the GUI to the backend, through DMAAP and the participants are shown in the diagram below. This diagram just serves as an illustration of the scenarios that the user will experience in the GUI. You can see factually complete dialogues in :ref:`system-level-label`. + + .. image:: ../images/gui/GUI-Flow.png diff --git a/docs/clamp/controlloop/design-impl/participants/http-participant.rst b/docs/clamp/controlloop/design-impl/participants/http-participant.rst index 87f0ec6f..b4b9b858 100644 --- a/docs/clamp/controlloop/design-impl/participants/http-participant.rst +++ b/docs/clamp/controlloop/design-impl/participants/http-participant.rst @@ -5,8 +5,6 @@ HTTP Participant ################ -.. warning:: To be completed - The CLAMP HTTP participant receives configuration information from the CLAMP runtime, maps the configuration information to a REST URL, and makes a REST call on the URL. Typically the HTTP Participant is used with another participant such as the @@ -16,8 +14,10 @@ participant can be used to configure the microservice over its REST interface.Of the HTTP participant works towards any REST service, it is not restricted to REST services started by participants. + .. image:: ../../images/participants/http-participant.png + The HTTP participant runs a Control Loop Element to handle the REST dialogues for a particular application domain. The REST dialogues are whatever REST calls that are required to implement the functionality for the application domain. @@ -26,12 +26,6 @@ The HTTP participant allows the REST dialogues for a Control Loop to be managed. particular Control Loop may require many *things* to be configured and managed and this may require many REST dialogues to achieve. -A *Configuration Entity* describes a concept that is managed by the HTTP participant. A -Configuration Entity can be created, Read, Updated, and Deleted (CRUD). The user defines -the Configuration Entities that it wants its HTTP Control Loop Element to manage and -provides a sequence of parameterized REST commands to Create, Read, Update, and Delete -each Configuration Entity. - When a control loop is initialized, the HTTP participant starts a HTTP Control Loop element for the control loop. It reads the configuration information sent from the Control Loop Runtime runs a HTTP client to talk to the REST endpoint that is receiving @@ -42,8 +36,15 @@ Control Loop B. Configuring a Control Loop Element on the HTTP participant for a Control Loop ----------------------------------------------------------------------------- +A *Configuration Entity* describes a concept that is managed by the HTTP participant. A +Configuration Entity can be created, Read, Updated, and Deleted (CRUD). The user defines +the Configuration Entities that it wants its HTTP Control Loop Element to manage and +provides a sequence of parameterized REST commands to Create, Read, Update, and Delete +each Configuration Entity. + +Sample tosca template defining a http participant and a control loop element for a control loop. :download:`click here <tosca/tosca-http-participant.yml>` -The user configures the following properties in the CLAMP GUI for the HTTP participant: +The user configures the following properties in the TOSCA for the HTTP participant: .. list-table:: :widths: 15 10 50 @@ -93,11 +94,40 @@ The *RestRequest* type is described in the following table: - An enum for the HTTP method {GET, PUT, POST, DELETE} * - path - String - - The path of the REST endopint relative to the baseUrl + - The path of the REST endpoint relative to the baseUrl * - body - String - The body of the request for POST and PUT methods * - expectedResponse - HttpStatus - The expected HTTP response code fo the REST request -
\ No newline at end of file + +Http participant Interactions: +------------------------------ +The http participant interacts with Control Loop Runtime on the northbound via DMaap. It interacts with any microservice on the southbound over http for configuration. + +The communication for the Control loop updates and state change requests are sent from the Control Loop Runtime to the participant via DMaap. +The participant invokes the appropriate http endpoint of the microservice based on the received messages from the Control Loop Runtime. + + +startPhase: +----------- +The http participant is often used along with :ref:`Kubernetes Participant <clamp-controlloop-k8s-participant>` to configure the microservice after the deployment. +This requires the Control Loop Element of http participant to be started after the completion of deployment of the microservice. This can be achieved by adding the property `startPhase` +in the Control Loop Element of http participant. Control Loop Runtime starts the elements based on the `startPhase` value defined in the Tosca. The default value of startPhase is taken as '0' +which takes precedence over the Control Loop Elements with the startPhase value '1'. Http Control Loop Elements are defined with value '1' in order to start the Control Loop Element in the second phase. + +Http participant Workflow: +-------------------------- +Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Control Loop Runtime to register this participant on the runtime database. +The user can commission the tosca definitions from the Policy Gui to the Control Loop Runtime that further updates the participant with these definitions via DMaap. +Once the control loop definitions are available in the runtime database, the Control Loop can be instantiated with the default state "UNINITIALISED" from the Policy Gui. + +When the state of the Control Loop is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the http participant receives the control loop state change event from the runtime and +configures the microservice of the corresponding Control Loop Element over http. +The configuration entity for a microservice is associated with each Control Loop Element for the http participant. +The http participant holds the executed http requests information along with the responses received. + +The participant is used in a generic way to configure any entity over http and it does not hold the information about the microservice to unconfigure/revert the configurations when the +state of Control Loop changes from "PASSIVE" to "UNINITIALISED". + diff --git a/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst b/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst index 1e1a05a3..b30dff39 100644 --- a/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst +++ b/docs/clamp/controlloop/design-impl/participants/k8s-participant.rst @@ -5,4 +5,134 @@ Kubernetes Participant ###################### -.. warning:: To be completed +The kubernetes participant receives a helm chart information from the CLAMP runtime and installs the helm chart in to the +k8s cluster on the specified namespace. It can fetch the helm chart from remote helm repositories as well as from any of the repositories +that are configured on the helm client. The participant acts as a wrapper around the helm client and creates the required +resources in the k8s cluster. + +The kubernetes participant also exposes REST endpoints for onboarding, installing and uninstalling of helm charts from the +local chart database which facilitates the user to also use this component as a standalone application for helm operations. + +In Istanbul version, the kubernetes participant supports the following methods of installation of helm charts. + +- Installation of helm charts from configured helm repositories and remote repositories passed via TOSCA in CLAMP. +- Installation of helm charts from the local chart database via the participant's REST Api. + +Prerequisites for using Kubernetes participant in Istanbul version: +------------------------------------------------------------------- + +- A running Kubernetes cluster. + + Note: + + - If the kubernetes participant is deployed outside the cluster , the config file of the k8s cluster needs to be copied to the `./kube` folder of kubernetes participant's home directory to make the participant work with the external cluster. + + - If the participant needs additional permission to create resources on the cluster, cluster-admin role binding can be created for the service account of the participant with the below command. + + Example: `kubectl create clusterrolebinding k8s-participant-admin-binding --clusterrole=cluster-admin --serviceaccount=<k8s participant service account>` + + +.. image:: ../../images/participants/k8s-participant.png + +Defining a TOSCA CL definition for kubernetes participant: +------------------------------------------------------- +A *chart* parameter map describes the helm chart parameters in tosca template for a microservice that is used by the kubernetes participant for the deployment. +A Control Loop element in TOSCA is mapped to the kubernetes participant and also holds the helm chart parameters for a microservice defined under the properties of the Control Loop Element. + +Sample tosca template defining a participant and a control loop element for a control loop. :download:`click here <tosca/tosca-k8s-participant.yml>` + + +Configuring a Control Loop Element on the kubernetes participant for a Control Loop +----------------------------------------------------------------------------------- + +The user configures the following properties in the TOSCA template for the kubernetes participant: + +.. list-table:: + :widths: 15 10 50 + :header-rows: 1 + + * - Property + - Type + - Description + * - chartId + - ToscaConceptIdentifier + - The name and version of the helm chart that needs to be managed by the kubernetes participant + * - namespace + - String + - The namespace in the k8s cluster where the helm chart needs to be installed + * - releaseName + - String + - The helm deployment name that specifies the installed component in the k8s cluster + * - repository (optional) + - map + - A map of *<String, String>* defining the helm repository parameters for the chart + * - overrideParams (optional) + - map + - A map of *<String, String>* defining the helm chart parameters that needs to be overridden + +Note: The repository property can be skipped if the helm chart is available in the local chart database or +in a repository that is already configured on the helm client. The participant does a chart lookup by default. + +The *repository* type is described in the following table: + +.. list-table:: + :widths: 15 10 50 + :header-rows: 1 + + * - Field + - Type + - Description + * - repoName + - String + - The name of the helm repository that needs to be configured on the helm client + * - protocol + - String + - Specifies http/https protocols to connect with repository url + * - address + - String + - Specifies the ip address or the host name + * - port (optional) + - String + - Specifies the port where the repository service is running + * - userName (optional) + - String + - The username to login the helm repository + * - password (optional) + - String + - The password to login the helm repository + + +Kubernetes participant Interactions: +------------------------------------ +The kubernetes participant interacts with Control Loop Runtime on the northbound via DMaap. It interacts with the helm client on the southbound for performing various helm operations to the k8s cluster. + +The communication for the Control loop updates and state change requests are sent from the Control Loop Runtime to the participant via DMaap. +The participant performs appropriate operations on the k8s cluster via helm client based on the received messages from the Control Loop Runtime. + + +kubernetes participant Workflow: +-------------------------------- +Once the participant is started, it sends a "REGISTER" event to the DMaap topic which is then consumed by the Control Loop Runtime to register this participant on the runtime database. +The user can commission the tosca definitions from the Policy Gui to the Control Loop Runtime that further updates the participant with these definitions via DMaap. +Once the control loop definitions are available in the runtime database, the Control Loop can be instantiated with the default state "UNINITIALISED" from the Policy Gui. + +When the state of the Control Loop is changed from "UNINITIALISED" to "PASSIVE" from the Policy Gui, the kubernetes participant receives the control loop state change event from the runtime and +deploys the helm charts associated with each Control Loop Elements by creating appropriate namespace on the cluster. +If the repository of the helm chart is not passed via TOSCA, the participant looks for the helm chart in the configured helm repositories of helm client. +It also performs a chart look up on the local chart database where the helm charts are onboarded via the participant's REST Api. + +The participant also monitors the deployed pods for the next 3 minutes until the pods comes to RUNNING state. +It holds the deployment information of the pods including the current status of the pods after the deployment. + +When the state of the Control Loop is changed from "PASSIVE" to "UNINITIALISED" back, the participant also undeploys the helm charts from the cluster that are part of the Control Loop Element. + +REST APIs on Kubernetes participant +----------------------------------- + +Kubernetes participant can also be installed as a standalone application which exposes REST endpoints for onboarding, +installing, uninstalling helm charts from local chart database. + + +.. image:: ../../images/participants/k8s-rest.png + +:download:`Download Kubernetes participant API Swagger <swagger/k8s-participant-swagger.json>`
\ No newline at end of file diff --git a/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst b/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst index 7f6cf499..a483dfc3 100644 --- a/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst +++ b/docs/clamp/controlloop/design-impl/participants/participant-intermediary.rst @@ -10,4 +10,120 @@ state handling for participant implementations. It provides a Java API, which pa implementations implement to receive and send messages to the CLAMP runtime and to handle Control Loop Element state. -.. warning:: To be completed +Terminology +----------- +- Broadcast message: a message for all participants (participantId=null and participantType=null) +- Message to a participant: a message only for a participant (participantId and participantType properly filled) +- MessageSender: a class that takes care of sending messages from participant-intermediary +- GUI: graphical user interface, Postman or a Front-End Application + +Inbound messages to participants +-------------------------------- +- PARTICIPANT_REGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantRegister message sent from a participant +- PARTICIPANT_DEREGISTER_ACK: received as a response from controlloop runtime server as an acknowledgement to ParticipantDeregister message sent from a participant +- CONTROL_LOOP_STATE_CHANGE: a message received from controlloop runtime server for a state change of controlloop +- CONTROL_LOOP_UPDATE: a message received from controlloop runtime server for a controlloop update with controlloop instances +- PARTICIPANT_UPDATE: a message received from controlloop runtime server for a participant update with tosca definitions of controlloop +- PARTICIPANT_STATUS_REQ: A status request received from controlloop runtime server to send an immediate ParticipantStatus from all participants + +Outbound messages +----------------- +- PARTICIPANT_REGISTER: is sent by a participant during startup +- PARTICIPANT_DEREGISTER: is sent by a participant during shutdown +- PARTICIPANT_STATUS: is sent by a participant as heartbeat with the status and health of a participant +- CONTROLLOOP_STATECHANGE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopStateChange +- CONTROLLOOP_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ControlLoopUpdate +- PARTICIPANT_UPDATE_ACK: is an acknowledgement sent by a participant as a response to ParticipantUpdate + +Design of a PARTICIPANT_REGISTER message +---------------------------------------- +- A participant starts and send a PARTICIPANT_REGISTER message +- ParticipantRegisterListener collects the message from DMaap +- if participant is not present in DB, it saves participant reference with status UNKNOWN to DB +- if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of Priming) +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) +- It triggers the execution to send a PARTICIPANT_REGISTER_ACK message to the participant registered +- MessageIntercept intercepts that event, if PARTICIPANT_UPDATE message has been sent, it will be add a task to handle PARTICIPANT_REGISTER in SupervisionScanner +- SupervisionScanner starts the monitoring for participantUpdate + +Design of a PARTICIPANT_DEREGISTER message +------------------------------------------ +- A participant starts and send a PARTICIPANT_DEREGISTER message +- ParticipantDeregisterListener collects the message from DMaap +- if participant is not present in DB, do nothing +- if participant is present in DB, it triggers the execution to send a PARTICIPANT_UPDATE message to the participant registered (message of DePriming) +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data as null +- ParticipantHandler removes the tosca definitions stored +- It triggers the execution to send a PARTICIPANT_DEREGISTER_ACK message to the participant registered +- Participant is not monitored. + +Design of a creation of a Control Loop Type +------------------------------------------- +- If there are participants registered with CL-runtime, it triggers the execution to send a broadcast PARTICIPANT_UPDATE message +- the message is built by ParticipantUpdatePublisher using Tosca Service Template data (to fill the list of ParticipantDefinition) +- Participant-intermediary will receive a PARTICIPANT_UDPATE message and stores the Tosca Service Template data on ParticipantHandler + +Design of a deletion of a Control Loop Type +------------------------------------------- +- if there are participants registered, CL-runtime triggers the execution to send a broadcast PARTICIPANT_UPDATE message +- the message is built by ParticipantUpdatePublisher with an empty list of ParticipantDefinition +- It deletes the Control Loop Type from DB +- Participant-intermediary will receive a PARTICIPANT_UDPATE message and deletes the Tosca Service Template data on ParticipantHandler + +Design of a creation of a Control Loop +-------------------------------------- +- CONTROL_LOOP_UPDATE message with instantiation details and UNINITIALISED state is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_UPDATE message and sends the details of ControlLoopElements to participants +- Each participant performs its designated job of deployment by interacting with respective frameworks + +Design of a deletion of a Control Loop +-------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with UNINITIALISED state is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of ControlLoopElements to participants +- Each participant performs its designated job of undeployment by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case UNINITIALISED to PASSIVE +----------------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from UNINITIALISED to PASSIVE is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case PASSIVE to UNINITIALISED +----------------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to UNINITIALISED is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case PASSIVE to RUNNING +----------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from PASSIVE to RUNNING is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of "issues control loop commands to control loops" - case RUNNING to PASSIVE +----------------------------------------------------------------------------------- +- CONTROL_LOOP_STATE_CHANGE message with state changed from RUNNING to PASSIVE is sent to participants +- Participant-intermediary validates the current state change +- Participant-intermediary will recieve CONTROL_LOOP_STATE_CHANGE message and sends the details of state change to participants +- Each participant performs its designated job of state change by interacting with respective frameworks + +Design of a PARTICIPANT_STATUS message +-------------------------------------- +- A participant sends a scheduled PARTICIPANT_STATUS message +- This message will hold the state and healthStatus of all the participants running actively +- PARTICIPANT_STATUS message holds a special attribute to return Tosca definitions, this attribute is populated only in response to PARTICIPANT_STATUS_REQ + +Design of a CONTROLLOOP_UPDATE_ACK message +------------------------------------------ +- A participant sends CONTROLLOOP_UPDATE_ACK message in response to a CONTROLLOOP_UPDATE message. +- For each CL-elements moved to the ordered state as indicated by the CONTROLLOOP_UPDATE +- ControlLoopUpdateAckListener in CL-runtime collects the messages from DMaap +- It checks the status of all control loop elements and checks if the control loop is primed +- It updates the controlloop in DB accordingly + +Design of a CONTROLLOOP_STATECHANGE_ACK is similar to the design for CONTROLLOOP_UPDATE_ACK diff --git a/docs/clamp/controlloop/design-impl/participants/participant-simulator.rst b/docs/clamp/controlloop/design-impl/participants/participant-simulator.rst index 8f59a9f1..9ac4e735 100644 --- a/docs/clamp/controlloop/design-impl/participants/participant-simulator.rst +++ b/docs/clamp/controlloop/design-impl/participants/participant-simulator.rst @@ -5,4 +5,17 @@ Participant Simulator ##################### -To be completed. +This can be used for simulation testing purpose when there are no actual frameworks or a full deployment. +Participant simulator can edit the states of ControlLoopElements and Participants for verification of other controlloop components +for early testing. +All controlloop components should be setup, except participant frameworks (for example, no policy framework components +are needed) and participant simulator acts as respective participant framework, and state changes can be done with following REST APIs + +Participant Simulator API +========================= + +This API allows a Participant Simulator to be started and run for test purposes. + +:download:`Download Policy Participant Simulator API Swagger <swagger/participant-sim.json>` + +.. swaggerv2doc:: swagger/participant-sim.json diff --git a/docs/clamp/controlloop/design-impl/participants/swagger/k8s-participant-swagger.json b/docs/clamp/controlloop/design-impl/participants/swagger/k8s-participant-swagger.json new file mode 100644 index 00000000..b2fca37a --- /dev/null +++ b/docs/clamp/controlloop/design-impl/participants/swagger/k8s-participant-swagger.json @@ -0,0 +1,399 @@ +{ + "swagger":"2.0", + "info":{ + "description":"Api Documentation", + "version":"1.0", + "title":"Api Documentation", + "termsOfService":"urn:tos", + "contact":{}, + "license":{ + "name":"Apache 2.0", + "url":"http://www.apache.org/licenses/LICENSE-2.0" + } + }, + "host":"localhost:8083", + "tags":[ + { + "name":"k8s-participant", + "description":"Chart Controller" + } + ], + "paths":{ + "/onap/k8sparticipant/helm/chart/{name}/{version}":{ + "delete":{ + "tags":[ + "k8s-participant" + ], + "summary":"Delete the chart", + "operationId":"deleteChartUsingDELETE", + "produces":[ + "*/*" + ], + "parameters":[ + { + "name":"name", + "in":"path", + "description":"name", + "required":true, + "type":"string" + }, + { + "name":"version", + "in":"path", + "description":"version", + "required":true, + "type":"string" + } + ], + "responses":{ + "200":{ + "description":"OK", + "schema":{ + "type":"object" + } + }, + "204":{ + "description":"Chart Deleted" + }, + "401":{ + "description":"Unauthorized" + }, + "403":{ + "description":"Forbidden" + } + } + } + }, + "/onap/k8sparticipant/helm/charts":{ + "get":{ + "tags":[ + "k8s-participant" + ], + "summary":"Return all Charts", + "operationId":"getAllChartsUsingGET", + "produces":[ + "application/json" + ], + "responses":{ + "200":{ + "description":"chart List", + "schema":{ + "$ref":"#/definitions/ChartList", + "originalRef":"ChartList" + } + }, + "401":{ + "description":"Unauthorized" + }, + "403":{ + "description":"Forbidden" + }, + "404":{ + "description":"Not Found" + } + } + } + }, + "/onap/k8sparticipant/helm/install":{ + "post":{ + "tags":[ + "k8s-participant" + ], + "summary":"Install the chart", + "operationId":"installChartUsingPOST", + "consumes":[ + "application/json" + ], + "produces":[ + "application/json" + ], + "parameters":[ + { + "in":"body", + "name":"info", + "description":"info", + "required":true, + "schema":{ + "$ref":"#/definitions/InstallationInfo", + "originalRef":"InstallationInfo" + } + } + ], + "responses":{ + "200":{ + "description":"OK", + "schema":{ + "type":"object" + } + }, + "201":{ + "description":"chart Installed", + "schema":{ + "type":"object" + } + }, + "401":{ + "description":"Unauthorized" + }, + "403":{ + "description":"Forbidden" + }, + "404":{ + "description":"Not Found" + } + } + } + }, + "/onap/k8sparticipant/helm/onboard/chart":{ + "post":{ + "tags":[ + "k8s-participant" + ], + "summary":"Onboard the Chart", + "operationId":"onboardChartUsingPOST", + "consumes":[ + "multipart/form-data" + ], + "produces":[ + "application/json" + ], + "parameters":[ + { + "name":"chart", + "in":"formData", + "required":false, + "type":"file" + }, + { + "name":"info", + "in":"formData", + "required":false, + "type":"string" + }, + { + "in":"body", + "name":"values", + "description":"values", + "required":false, + "schema":{ + "type":"string", + "format":"binary" + } + } + ], + "responses":{ + "200":{ + "description":"OK", + "schema":{ + "type":"string" + } + }, + "201":{ + "description":"Chart Onboarded", + "schema":{ + "type":"string" + } + }, + "401":{ + "description":"Unauthorized" + }, + "403":{ + "description":"Forbidden" + }, + "404":{ + "description":"Not Found" + } + } + } + }, + "/onap/k8sparticipant/helm/repo":{ + "post":{ + "tags":[ + "k8s-participant" + ], + "summary":"Configure helm repository", + "operationId":"configureRepoUsingPOST", + "consumes":[ + "application/json" + ], + "produces":[ + "application/json" + ], + "parameters":[ + { + "in":"body", + "name":"repo", + "description":"repo", + "required":true, + "schema":{ + "type":"string" + } + } + ], + "responses":{ + "200":{ + "description":"OK", + "schema":{ + "type":"object" + } + }, + "201":{ + "description":"Repository added", + "schema":{ + "type":"object" + } + }, + "401":{ + "description":"Unauthorized" + }, + "403":{ + "description":"Forbidden" + }, + "404":{ + "description":"Not Found" + } + } + } + }, + "/onap/k8sparticipant/helm/uninstall/{name}/{version}":{ + "delete":{ + "tags":[ + "k8s-participant" + ], + "summary":"Uninstall the Chart", + "operationId":"uninstallChartUsingDELETE", + "produces":[ + "application/json" + ], + "parameters":[ + { + "name":"name", + "in":"path", + "description":"name", + "required":true, + "type":"string" + }, + { + "name":"version", + "in":"path", + "description":"version", + "required":true, + "type":"string" + } + ], + "responses":{ + "200":{ + "description":"OK", + "schema":{ + "type":"object" + } + }, + "201":{ + "description":"chart Uninstalled", + "schema":{ + "type":"object" + } + }, + "204":{ + "description":"No Content" + }, + "401":{ + "description":"Unauthorized" + }, + "403":{ + "description":"Forbidden" + } + } + } + } + }, + "definitions":{ + "ChartInfo":{ + "type":"object", + "properties":{ + "chartId":{ + "$ref":"#/definitions/ToscaConceptIdentifier", + "originalRef":"ToscaConceptIdentifier" + }, + "namespace":{ + "type":"string" + }, + "overrideParams":{ + "type":"object", + "additionalProperties":{ + "type":"string" + } + }, + "releaseName":{ + "type":"string" + }, + "repository":{ + "$ref":"#/definitions/HelmRepository", + "originalRef":"HelmRepository" + } + }, + "title":"ChartInfo" + }, + "ChartList":{ + "type":"object", + "properties":{ + "charts":{ + "type":"array", + "items":{ + "$ref":"#/definitions/ChartInfo", + "originalRef":"ChartInfo" + } + } + }, + "title":"ChartList" + }, + "HelmRepository":{ + "type":"object", + "properties":{ + "address":{ + "type":"string" + }, + "password":{ + "type":"string" + }, + "port":{ + "type":"string" + }, + "protocol":{ + "type":"string" + }, + "repoName":{ + "type":"string" + }, + "userName":{ + "type":"string" + } + }, + "title":"HelmRepository" + }, + "InstallationInfo":{ + "type":"object", + "properties":{ + "name":{ + "type":"string" + }, + "version":{ + "type":"string" + } + }, + "title":"InstallationInfo" + }, + "ToscaConceptIdentifier":{ + "type":"object", + "properties":{ + "name":{ + "type":"string" + }, + "version":{ + "type":"string" + } + }, + "title":"ToscaConceptIdentifier" + } + } +} diff --git a/docs/clamp/controlloop/design-impl/participants/swagger/participant-sim.json b/docs/clamp/controlloop/design-impl/participants/swagger/participant-sim.json new file mode 100644 index 00000000..79fc3011 --- /dev/null +++ b/docs/clamp/controlloop/design-impl/participants/swagger/participant-sim.json @@ -0,0 +1,478 @@ +{ + "swagger": "2.0", + "info": { + "description": "Api Documentation", + "version": "1.0", + "title": "Api Documentation", + "termsOfService": "urn:tos", + "contact": {}, + "license": { + "name": "Apache 2.0", + "url": "http://www.apache.org/licenses/LICENSE-2.0" + } + }, + "paths": { + "/onap/participantsim/v2/elements": { + "put": { + "tags": [ + "Clamp Control Loop Participant Simulator API" + ], + "summary": "Updates simulated control loop elements", + "description": "Updates simulated control loop elements, returning the updated control loop definition IDs", + "operationId": "updateUsingPUT", + "consumes": [ + "application/json" + ], + "produces": [ + "application/json", + "application/yaml" + ], + "parameters": [ + { + "in": "body", + "name": "body", + "description": "Body of a control loop element", + "required": true, + "schema": { + "$ref": "#/definitions/ControlLoopElementReq", + "originalRef": "ControlLoopElementReq" + } + }, + { + "name": "X-ONAP-RequestID", + "in": "header", + "description": "RequestID for http transaction", + "required": false, + "type": "string", + "format": "uuid" + } + ], + "responses": { + "200": { + "description": "OK", + "schema": { + "$ref": "#/definitions/TypedSimpleResponse«ControlLoopElement»", + "originalRef": "TypedSimpleResponse«ControlLoopElement»" + } + }, + "201": { + "description": "Created" + }, + "401": { + "description": "Authentication Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "403": { + "description": "Authorization Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "404": { + "description": "Not Found" + }, + "500": { + "description": "Internal Server Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + } + }, + "security": [ + { + "basicAuth": [] + } + ], + "x-interface info": { + "api-version": "1.0.0", + "last-mod-release": "Dublin" + } + } + }, + "/onap/participantsim/v2/elements/{name}/{version}": { + "get": { + "tags": [ + "Clamp Control Loop Participant Simulator API" + ], + "summary": "Query details of the requested simulated control loop elements", + "description": "Queries details of the requested simulated control loop elements, returning all control loop element details", + "operationId": "elementsUsingGET", + "produces": [ + "application/json", + "application/yaml" + ], + "parameters": [ + { + "name": "name", + "in": "path", + "description": "Control loop element name", + "required": true, + "type": "string" + }, + { + "name": "version", + "in": "path", + "description": "Control loop element version", + "required": true, + "type": "string" + }, + { + "name": "X-ONAP-RequestID", + "in": "header", + "description": "RequestID for http transaction", + "required": false, + "type": "string", + "format": "uuid" + } + ], + "responses": { + "200": { + "description": "OK", + "schema": { + "type": "object", + "additionalProperties": { + "$ref": "#/definitions/ControlLoopElementRes", + "originalRef": "ControlLoopElementRes" + } + } + }, + "401": { + "description": "Authentication Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "403": { + "description": "Authorization Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "404": { + "description": "Not Found" + }, + "500": { + "description": "Internal Server Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + } + }, + "security": [ + { + "basicAuth": [] + } + ], + "x-interface info": { + "api-version": "1.0.0", + "last-mod-release": "Dublin" + } + } + }, + "/onap/participantsim/v2/participants": { + "put": { + "tags": [ + "Clamp Control Loop Participant Simulator API" + ], + "summary": "Updates simulated participants", + "description": "Updates simulated participants, returning the updated control loop definition IDs", + "operationId": "updateUsingPUT_1", + "consumes": [ + "application/json" + ], + "produces": [ + "application/json", + "application/yaml" + ], + "parameters": [ + { + "in": "body", + "name": "body", + "description": "Body of a participant", + "required": true, + "schema": { + "$ref": "#/definitions/ParticipantReq", + "originalRef": "ParticipantReq" + } + }, + { + "name": "X-ONAP-RequestID", + "in": "header", + "description": "RequestID for http transaction", + "required": false, + "type": "string", + "format": "uuid" + } + ], + "responses": { + "200": { + "description": "OK", + "schema": { + "$ref": "#/definitions/TypedSimpleResponse«Participant»", + "originalRef": "TypedSimpleResponse«Participant»" + } + }, + "201": { + "description": "Created" + }, + "401": { + "description": "Authentication Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "403": { + "description": "Authorization Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "404": { + "description": "Not Found" + }, + "500": { + "description": "Internal Server Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + } + }, + "security": [ + { + "basicAuth": [] + } + ], + "x-interface info": { + "api-version": "1.0.0", + "last-mod-release": "Dublin" + } + } + }, + "/onap/participantsim/v2/participants/{name}/{version}": { + "get": { + "tags": [ + "Clamp Control Loop Participant Simulator API" + ], + "summary": "Query details of the requested simulated participants", + "description": "Queries details of the requested simulated participants, returning all participant details", + "operationId": "participantsUsingGET", + "produces": [ + "application/json", + "application/yaml" + ], + "parameters": [ + { + "name": "name", + "in": "path", + "description": "Participant name", + "required": true, + "type": "string" + }, + { + "name": "version", + "in": "path", + "description": "Participant version", + "required": true, + "type": "string" + }, + { + "name": "X-ONAP-RequestID", + "in": "header", + "description": "RequestID for http transaction", + "required": false, + "type": "string", + "format": "uuid" + } + ], + "responses": { + "200": { + "description": "OK", + "schema": { + "type": "array", + "items": { + "$ref": "#/definitions/ParticipantRes", + "originalRef": "ParticipantRes" + } + } + }, + "401": { + "description": "Authentication Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "403": { + "description": "Authorization Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + }, + "404": { + "description": "Not Found" + }, + "500": { + "description": "Internal Server Error", + "headers": { + "X-LatestVersion": { + "type": "string" + }, + "X-PatchVersion": { + "type": "string" + }, + "X-MinorVersion": { + "type": "string" + }, + "X-ONAP-RequestID": { + "type": "string", + "format": "uuid" + } + } + } + }, + "security": [ + { + "basicAuth": [] + } + ], + "x-interface info": { + "api-version": "1.0.0", + "last-mod-release": "Dublin" + } + } + } + } +}
\ No newline at end of file diff --git a/docs/clamp/controlloop/design-impl/participants/tosca/tosca-http-participant.yml b/docs/clamp/controlloop/design-impl/participants/tosca/tosca-http-participant.yml new file mode 100644 index 00000000..dae4c76a --- /dev/null +++ b/docs/clamp/controlloop/design-impl/participants/tosca/tosca-http-participant.yml @@ -0,0 +1,439 @@ +tosca_definitions_version: tosca_simple_yaml_1_3 +data_types: + onap.datatypes.ToscaConceptIdentifier: + derived_from: tosca.datatypes.Root + properties: + name: + type: string + required: true + version: + type: string + required: true + onap.datatype.controlloop.Target: + derived_from: tosca.datatypes.Root + description: Definition for a entity in A&AI to perform a control loop operation on + properties: + targetType: + type: string + description: Category for the target type + required: true + constraints: + - valid_values: + - VNF + - VM + - VFMODULE + - PNF + entityIds: + type: map + description: | + Map of values that identify the resource. If none are provided, it is assumed that the + entity that generated the ONSET event will be the target. + required: false + metadata: + clamp_possible_values: ClampExecution:CSAR_RESOURCES + entry_schema: + type: string + onap.datatype.controlloop.Actor: + derived_from: tosca.datatypes.Root + description: An actor/operation/target definition + properties: + actor: + type: string + description: The actor performing the operation. + required: true + metadata: + clamp_possible_values: Dictionary:DefaultActors,ClampExecution:CDS/actor + operation: + type: string + description: The operation the actor is performing. + metadata: + clamp_possible_values: Dictionary:DefaultOperations,ClampExecution:CDS/operation + required: true + target: + type: onap.datatype.controlloop.Target + description: The resource the operation should be performed on. + required: true + payload: + type: map + description: Name/value pairs of payload information passed by Policy to the actor + required: false + metadata: + clamp_possible_values: ClampExecution:CDS/payload + entry_schema: + type: string + onap.datatype.controlloop.Operation: + derived_from: tosca.datatypes.Root + description: An operation supported by an actor + properties: + id: + type: string + description: Unique identifier for the operation + required: true + description: + type: string + description: A user-friendly description of the intent for the operation + required: false + operation: + type: onap.datatype.controlloop.Actor + description: The definition of the operation to be performed. + required: true + timeout: + type: integer + description: The amount of time for the actor to perform the operation. + required: true + retries: + type: integer + description: The number of retries the actor should attempt to perform the operation. + required: true + default: 0 + success: + type: string + description: Points to the operation to invoke on success. A value of "final_success" indicates and end to the operation. + required: false + default: final_success + failure: + type: string + description: Points to the operation to invoke on Actor operation failure. + required: false + default: final_failure + failure_timeout: + type: string + description: Points to the operation to invoke when the time out for the operation occurs. + required: false + default: final_failure_timeout + failure_retries: + type: string + description: Points to the operation to invoke when the current operation has exceeded its max retries. + required: false + default: final_failure_retries + failure_exception: + type: string + description: Points to the operation to invoke when the current operation causes an exception. + required: false + default: final_failure_exception + failure_guard: + type: string + description: Points to the operation to invoke when the current operation is blocked due to guard policy enforcement. + required: false + default: final_failure_guard + org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.RestRequest: + version: 1.0.0 + derived_from: tosca.datatypes.Root + properties: + restRequestId: + type: onap.datatypes.ToscaConceptIdentifier + typeVersion: 1.0.0 + required: true + description: The name and version of a REST request to be sent to a REST endpoint + httpMethod: + type: string + required: true + constraints: + - valid_values: [POST, PUT, GET, DELETE] + description: The REST method to use + path: + type: string + required: true + description: The path of the REST request relative to the base URL + body: + type: string + required: false + description: The body of the REST request for PUT and POST requests + expectedResponse: + type: integer + required: true + constraints: + - in_range: [100, 599] + description: THe expected HTTP status code for the REST request + org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.ConfigurationEntity: + version: 1.0.0 + derived_from: tosca.datatypes.Root + properties: + configurationEntityId: + type: onap.datatypes.ToscaConceptIdentifier + typeVersion: 1.0.0 + required: true + description: The name and version of a Configuration Entity to be handled by the HTTP Control Loop Element + restSequence: + type: list + entry_schema: + type: org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.RestRequest + typeVersion: 1.0.0 + description: A sequence of REST commands to send to the REST endpoint +node_types: + org.onap.policy.clamp.controlloop.Participant: + version: 1.0.1 + derived_from: tosca.nodetypes.Root + properties: + provider: + type: string + requred: false + org.onap.policy.clamp.controlloop.ControlLoopElement: + version: 1.0.1 + derived_from: tosca.nodetypes.Root + properties: + provider: + type: string + required: false + metadata: + common: true + description: Specifies the organization that provides the control loop element + participant_id: + type: onap.datatypes.ToscaConceptIdentifier + requred: true + metadata: + common: true + participantType: + type: onap.datatypes.ToscaConceptIdentifier + required: true + metadata: + common: true + description: The identity of the participant type that hosts this type of Control Loop Element + startPhase: + type: integer + required: false + constraints: + - greater_or_equal: 0 + metadata: + common: true + description: A value indicating the start phase in which this control loop element will be started, the + first start phase is zero. Control Loop Elements are started in their start_phase order and stopped + in reverse start phase order. Control Loop Elements with the same start phase are started and + stopped simultaneously + uninitializedToPassiveTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from uninitialized to passive + passiveToRunningTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from passive to running + runningToPassiveTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from running to passive + passiveToUninitializedTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from passive to uninitialized + org.onap.policy.clamp.controlloop.ControlLoop: + version: 1.0.1 + derived_from: tosca.nodetypes.Root + properties: + provider: + type: string + required: false + metadata: + common: true + description: Specifies the organization that provides the control loop element + elements: + type: list + required: true + metadata: + common: true + entry_schema: + type: onap.datatypes.ToscaConceptIdentifier + description: Specifies a list of control loop element definitions that make up this control loop definition + org.onap.policy.clamp.controlloop.HttpControlLoopElement: + version: 1.0.1 + derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement + properties: + baseUrl: + type: string + required: true + description: The base URL to be prepended to each path, identifies the host for the REST endpoints. + httpHeaders: + type: map + required: false + entry_schema: + type: string + description: HTTP headers to send on REST requests + configurationEntities: + type: map + required: true + entry_schema: + type: org.onap.datatypes.policy.clamp.controlloop.httpControlLoopElement.ConfigurationEntity + typeVersion: 1.0.0 + description: The connfiguration entities the Control Loop Element is managing and their associated REST requests + +topology_template: + node_templates: + org.onap.controlloop.HttpControlLoopParticipant: + version: 2.3.4 + type: org.onap.policy.clamp.controlloop.Participant + type_version: 1.0.1 + description: Participant for Http requests + properties: + provider: ONAP + org.onap.domain.database.Http_PMSHMicroserviceControlLoopElement: + # Consul http config for PMSH. + version: 1.2.3 + type: org.onap.policy.clamp.controlloop.HttpControlLoopElement + type_version: 1.0.1 + description: Control loop element for the http requests of PMSH microservice + properties: + provider: ONAP + participant_id: + name: HttpParticipant0 + version: 1.0.0 + participantType: + name: org.onap.k8s.controlloop.HttpControlLoopParticipant + version: 2.3.4 + uninitializedToPassiveTimeout: 180 + baseUrl: http://consul-server-ui:8500 + httpHeaders: + Content-Type: application/json + configurationEntities: + - configurationEntityId: + name: entity1 + version: 1.0.1 + restSequence: + - restRequestId: + name: request1 + version: 1.0.1 + httpMethod: PUT + path: v1/kv/dcae-pmsh2 + body: '{ + "control_loop_name":"pmsh-control-loop", + "operational_policy_name":"pmsh-operational-policy", + "aaf_password":"demo123456!", + "aaf_identity":"dcae@dcae.onap.org", + "cert_path":"/opt/app/pmsh/etc/certs/cert.pem", + "key_path":"/opt/app/pmsh/etc/certs/key.pem", + "ca_cert_path":"/opt/app/pmsh/etc/certs/cacert.pem", + "enable_tls":"true", + "pmsh_policy":{ + "subscription":{ + "subscriptionName":"ExtraPM-All-gNB-R2B", + "administrativeState":"UNLOCKED", + "fileBasedGP":15, + "fileLocation":"\/pm\/pm.xml", + "nfFilter":{ + "nfNames":[ + "^pnf.*", + "^vnf.*" + ], + "modelInvariantIDs":[ + ], + "modelVersionIDs":[ + ], + "modelNames":[ + ] + }, + "measurementGroups":[ + { + "measurementGroup":{ + "measurementTypes":[ + { + "measurementType":"countera" + }, + { + "measurementType":"counterb" + } + ], + "managedObjectDNsBasic":[ + { + "DN":"dna" + }, + { + "DN":"dnb" + } + ] + } + }, + { + "measurementGroup":{ + "measurementTypes":[ + { + "measurementType":"counterc" + }, + { + "measurementType":"counterd" + } + ], + "managedObjectDNsBasic":[ + { + "DN":"dnc" + }, + { + "DN":"dnd" + } + ] + } + } + ] + } + }, + "streams_subscribes":{ + "aai_subscriber":{ + "type":"message_router", + "dmaap_info":{ + "topic_url":"https://10.152.183.151:3905/events/AAI_EVENT", + "client_role":"org.onap.dcae.aaiSub", + "location":"san-francisco", + "client_id":"1575976809466" + } + }, + "policy_pm_subscriber":{ + "type":"message_router", + "dmaap_info":{ + "topic_url":"https://10.152.183.151:3905/events/org.onap.dmaap.mr.PM_SUBSCRIPTIONS", + "client_role":"org.onap.dcae.pmSubscriber", + "location":"san-francisco", + "client_id":"1575876809456" + } + } + }, + "streams_publishes":{ + "policy_pm_publisher":{ + "type":"message_router", + "dmaap_info":{ + "topic_url":"https://10.152.183.151:3905/events/org.onap.dmaap.mr.PM_SUBSCRIPTIONS", + "client_role":"org.onap.dcae.pmPublisher", + "location":"san-francisco", + "client_id":"1475976809466" + } + }, + "other_publisher":{ + "type":"message_router", + "dmaap_info":{ + "topic_url":"https://10.152.183.151:3905/events/org.onap.dmaap.mr.SOME_OTHER_TOPIC", + "client_role":"org.onap.dcae.pmControlPub", + "location":"san-francisco", + "client_id":"1875976809466" + } + } + } + }' + expectedResponse: 200 + org.onap.domain.sample.GenericK8s_ControlLoopDefinition: + version: 1.2.3 + type: org.onap.policy.clamp.controlloop.ControlLoop + type_version: 1.0.0 + description: Control loop for Hello World + properties: + provider: ONAP + elements: + - name: org.onap.domain.database.Http_PMSHMicroserviceControlLoopElement + version: 1.2.3 + diff --git a/docs/clamp/controlloop/design-impl/participants/tosca/tosca-k8s-participant.yml b/docs/clamp/controlloop/design-impl/participants/tosca/tosca-k8s-participant.yml new file mode 100644 index 00000000..70bbe928 --- /dev/null +++ b/docs/clamp/controlloop/design-impl/participants/tosca/tosca-k8s-participant.yml @@ -0,0 +1,304 @@ +tosca_definitions_version: tosca_simple_yaml_1_3 +data_types: + onap.datatypes.ToscaConceptIdentifier: + derived_from: tosca.datatypes.Root + properties: + name: + type: string + required: true + version: + type: string + required: true + onap.datatype.controlloop.Target: + derived_from: tosca.datatypes.Root + description: Definition for a entity in A&AI to perform a control loop operation on + properties: + targetType: + type: string + description: Category for the target type + required: true + constraints: + - valid_values: + - VNF + - VM + - VFMODULE + - PNF + entityIds: + type: map + description: | + Map of values that identify the resource. If none are provided, it is assumed that the + entity that generated the ONSET event will be the target. + required: false + metadata: + clamp_possible_values: ClampExecution:CSAR_RESOURCES + entry_schema: + type: string + onap.datatype.controlloop.Actor: + derived_from: tosca.datatypes.Root + description: An actor/operation/target definition + properties: + actor: + type: string + description: The actor performing the operation. + required: true + metadata: + clamp_possible_values: Dictionary:DefaultActors,ClampExecution:CDS/actor + operation: + type: string + description: The operation the actor is performing. + metadata: + clamp_possible_values: Dictionary:DefaultOperations,ClampExecution:CDS/operation + required: true + target: + type: onap.datatype.controlloop.Target + description: The resource the operation should be performed on. + required: true + payload: + type: map + description: Name/value pairs of payload information passed by Policy to the actor + required: false + metadata: + clamp_possible_values: ClampExecution:CDS/payload + entry_schema: + type: string + onap.datatype.controlloop.Operation: + derived_from: tosca.datatypes.Root + description: An operation supported by an actor + properties: + id: + type: string + description: Unique identifier for the operation + required: true + description: + type: string + description: A user-friendly description of the intent for the operation + required: false + operation: + type: onap.datatype.controlloop.Actor + description: The definition of the operation to be performed. + required: true + timeout: + type: integer + description: The amount of time for the actor to perform the operation. + required: true + retries: + type: integer + description: The number of retries the actor should attempt to perform the operation. + required: true + default: 0 + success: + type: string + description: Points to the operation to invoke on success. A value of "final_success" indicates and end to the operation. + required: false + default: final_success + failure: + type: string + description: Points to the operation to invoke on Actor operation failure. + required: false + default: final_failure + failure_timeout: + type: string + description: Points to the operation to invoke when the time out for the operation occurs. + required: false + default: final_failure_timeout + failure_retries: + type: string + description: Points to the operation to invoke when the current operation has exceeded its max retries. + required: false + default: final_failure_retries + failure_exception: + type: string + description: Points to the operation to invoke when the current operation causes an exception. + required: false + default: final_failure_exception + failure_guard: + type: string + description: Points to the operation to invoke when the current operation is blocked due to guard policy enforcement. + required: false + default: final_failure_guard +node_types: + org.onap.policy.clamp.controlloop.Participant: + version: 1.0.1 + derived_from: tosca.nodetypes.Root + properties: + provider: + type: string + requred: false + org.onap.policy.clamp.controlloop.ControlLoopElement: + version: 1.0.1 + derived_from: tosca.nodetypes.Root + properties: + provider: + type: string + required: false + metadata: + common: true + description: Specifies the organization that provides the control loop element + participant_id: + type: onap.datatypes.ToscaConceptIdentifier + requred: true + metadata: + common: true + participantType: + type: onap.datatypes.ToscaConceptIdentifier + required: true + metadata: + common: true + description: The identity of the participant type that hosts this type of Control Loop Element + startPhase: + type: integer + required: false + constraints: + - greater_or_equal: 0 + metadata: + common: true + description: A value indicating the start phase in which this control loop element will be started, the + first start phase is zero. Control Loop Elements are started in their start_phase order and stopped + in reverse start phase order. Control Loop Elements with the same start phase are started and + stopped simultaneously + uninitializedToPassiveTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from uninitialized to passive + passiveToRunningTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from passive to running + runningToPassiveTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from running to passive + passiveToUninitializedTimeout: + type: integer + required: false + constraints: + - greater_or_equal: 0 + default: 60 + metadata: + common: true + description: The maximum time in seconds to wait for a state chage from passive to uninitialized + org.onap.policy.clamp.controlloop.ControlLoop: + version: 1.0.1 + derived_from: tosca.nodetypes.Root + properties: + provider: + type: string + required: false + metadata: + common: true + description: Specifies the organization that provides the control loop element + elements: + type: list + required: true + metadata: + common: true + entry_schema: + type: onap.datatypes.ToscaConceptIdentifier + description: Specifies a list of control loop element definitions that make up this control loop definition + org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement: + version: 1.0.1 + derived_from: org.onap.policy.clamp.controlloop.ControlLoopElement + properties: + chart: + type: string + required: true + configs: + type: list + required: false + requirements: + type: string + requred: false + templates: + type: list + required: false + entry_schema: + values: + type: string + required: true + +topology_template: + node_templates: + org.onap.k8s.controlloop.K8SControlLoopParticipant: + version: 2.3.4 + type: org.onap.policy.clamp.controlloop.Participant + type_version: 1.0.1 + description: Participant for K8S + properties: + provider: ONAP + org.onap.domain.database.PMSH_K8SMicroserviceControlLoopElement: + # Chart from new repository + version: 1.2.3 + type: org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement + type_version: 1.0.0 + description: Control loop element for the K8S microservice for PMSH + properties: + provider: ONAP + participant_id: + name: K8sParticipant0 + version: 1.0.0 + participantType: + name: org.onap.k8s.controlloop.K8SControlLoopParticipant + version: 2.3.4 + chart: + chartId: + name: dcae-pmsh + version: 8.0.0 + namespace: onap + releaseName: pmshms + repository: + repoName: chartmuseum + protocol: http + address: chart-museum + port: 80 + userName: onapinitializer + password: demo123456! + overrideParams: + global.masterPassword: test + + org.onap.domain.database.Local_K8SMicroserviceControlLoopElement: + # Chart installation without passing repository info + version: 1.2.3 + type: org.onap.policy.clamp.controlloop.K8SMicroserviceControlLoopElement + type_version: 1.0.0 + description: Control loop element for the K8S microservice for local chart + properties: + provider: ONAP + participant_id: + name: K8sParticipant0 + version: 1.0.0 + participantType: + name: org.onap.k8s.controlloop.K8SControlLoopParticipant + version: 2.3.4 + chart: + chartId: + name: nginx-ingress + version: 0.9.1 + releaseName: nginxms + namespace: test + org.onap.domain.sample.GenericK8s_ControlLoopDefinition: + version: 1.2.3 + type: org.onap.policy.clamp.controlloop.ControlLoop + type_version: 1.0.0 + description: Control loop for Hello World + properties: + provider: ONAP + elements: + - name: org.onap.domain.database.PMSH_K8SMicroserviceControlLoopElement + version: 1.2.3 + - name: org.onap.domain.database.Local_K8SMicroserviceControlLoopElement + version: 1.2.3 |