diff options
| author |   rameshiyer27 <ramesh.murugan.iyer@est.tech> | 2024-07-31 15:38:57 +0100 |
|---|---|---|
| committer | rameshiyer27 <ramesh.murugan.iyer@est.tech> | 2024-08-01 14:14:35 +0100 |
| commit | 3c43d25f6ed24ff8710e56253802a361d3345e6c (patch) | |
| tree | 0e16a7d22cbff344bf6bfd9378b459b5770eca23 | |
| parent | e322a4724bab02178b78594787e78612ae7a8d41 (diff) | |
Remove policy gui from onap docs
Issue-ID: POLICY-5100
Signed-off-by: zrrmmua <ramesh.murugan.iyer@est.tech>
Change-Id: I4eaf6f564a2d3285c890f861afdeb514c9b2f8a7
20 files changed, 29 insertions, 978 deletions
diff --git a/docs/apex/APEX-MyFirstPolicyExample.rst b/docs/apex/APEX-MyFirstPolicyExample.rst index 089ead02..55dd2b87 100644 --- a/docs/apex/APEX-MyFirstPolicyExample.rst +++ b/docs/apex/APEX-MyFirstPolicyExample.rst @@ -39,7 +39,10 @@ Introduction In this document we will show how APEX and APEX Policies can be used to achieve this, starting with a simple policy, building up to more complicated policy - that demonstrates the features of APEX. + that demonstrates the features of APEX. This example demonstrates + the data models, events and task logics that can be considered + for the scenario. From Oslo release, only apex cli editor can be used + for generating the policies. Data Models ^^^^^^^^^^^ @@ -270,28 +273,6 @@ New Policy Model define many Policy Models, each containing a different set of policies. - .. container:: paragraph - - So the first step is to create a new empty Policy Model - called ``MyFirstPolicyModel``. Using the APEX Policy - Editor, click on the 'File' menus and select 'New'. Then - define our new policy model called - ``MyFirstPolicyModel``. Use the 'Generate UUID' button to - create a new unique ID for the policy model, and fill in - a description for the policy model. Press the ``Submit`` - button to save your changes. - - .. container:: imageblock - - .. container:: content - - |File > New to create a new Policy Model| - - .. container:: imageblock - - .. container:: content - - |Create a new Policy Model| Events ------ @@ -300,45 +281,14 @@ Events .. container:: sect1 - .. rubric:: Create the input event ``SALE_INPUT`` and the + .. rubric:: Define the input event ``SALE_INPUT`` and the output event ``SALE_AUTH`` :name: create_the_input_event_code_sale_input_code_and_the_output_event_code_sale_auth_code .. container:: paragraph - Using the APEX Policy Editor, click on the 'Events' tab. - In the 'Events' pane, right click and select 'New': - - .. container:: imageblock - - .. container:: content - - |Right click to create a new event| - - .. container:: paragraph - - Create a new event type called ``SALE_INPUT``. Use the - 'Generate UUID' button to create a new unique ID for the - event type, and fill in a description for the event. Add - a namespace, e.g. ``com.hyperm``. We can add hard-coded - strings for the ``Source`` and ``Target``, e.g. ``POS`` - and ``APEX``. At this stage we will not add any parameter - fields, we will leave this until later. Use the - ``Submit`` button to create the event. - - .. container:: imageblock - - .. container:: content - - |Fill in the necessary information for the - 'SALE_INPUT' event and click 'Submit'| - - .. container:: paragraph + Define the new event types called ``SALE_INPUT`` and ``SALE_AUTH``. - Repeat the same steps for a new event type called - ``SALE_AUTH``. Just use ``APEX`` as source and ``POS`` as - target, since this is the output event coming from APEX - going to the sales point. .. container:: paragraph @@ -348,18 +298,6 @@ Events .. container:: paragraph - To create new item schemas, click on the 'Context Item - Schemas' tab. In that 'Context Item Schemas' pane, right - click and select 'Create new ContextSchema'. - - .. container:: imageblock - - .. container:: content - - |Right click to create a new Item Schema| - - .. container:: paragraph - Create item schemas with the following characteristics, each with its own unique UUID: @@ -411,20 +349,6 @@ Events | | | | values | +-----------------+-----------------+-----------------+-----------------+ - .. container:: imageblock - - .. container:: content - - |Create a new Item Schema| - - .. container:: paragraph - - The item schemas can now be seen on the 'Context Item - Schemas' tab, and can be updated at any time by - right-clicking on the item schemas on the 'Context Item - Schemas' tab. Now we can go back to the event definitions - for ``SALE_INPUT`` and ``SALE_AUTH`` and add some - parameter fields. .. TIP:: @@ -449,10 +373,7 @@ Events .. container:: paragraph - Click on the 'Events' tab, then right click the - ``SALE_INPUT`` row and select 'Edit Event - :literal:`SALE_INPUT’. To add a new event parameter use the 'Add Event Parameter' button at the bottom of the screen. For the `SALE_INPUT` - event add the following event parameters: + Add the following event parameters: .. table:: Table 2. Event Parameter Fields for the ``SALE_INPUT`` Event @@ -476,10 +397,6 @@ Events | notes | notes_type | *yes* | +----------------------+----------------------+-----------------------+ - .. container:: paragraph - - Remember to click the 'Submit' button at the bottom of - the event definition pane. .. TIP:: @@ -490,16 +407,10 @@ Events passed to APEX. If an *optional* field is not set for an output event then value will be set to ``null``. - .. container:: imageblock - - .. container:: content - - |Add new event parameters to an event| .. container:: paragraph - Select the ``SALE_AUTH`` event and add the following - event parameters: + Add the following event parameters for ``SALE_AUTH`` event: .. table:: Table 3. Event Parameter Fields for the ``SALE_AUTH`` Event @@ -527,10 +438,6 @@ Events | notes | notes_type | *yes* | +----------------------+----------------------+-----------------------+ - .. container:: paragraph - - Remember to click the 'Submit' button at the bottom of - the event definition pane. .. container:: paragraph @@ -569,32 +476,8 @@ New Policy .. container:: paragraph Therefore, to create a new policy we must first define - one or more tasks. - - .. container:: paragraph - - To create a new Task click on the 'Tasks' tab. In the - 'Tasks' pane, right click and select 'Create new Task'. - Create a new Task called ``MorningBoozeCheck``. Use the - 'Generate UUID' button to create a new unique ID for the - task, and fill in a description for the task. - - .. container:: imageblock - - .. container:: content - - |Right click to create a new task| - - .. container:: paragraph - - Tasks are configured with a set of *input fields* and a - set of *output fields*. To add new input/output fields - for a task use the 'Add Task Input Field' and 'Add Task - Output Field' button. The list of input and out fields to - add for the ``MorningBoozeCheck`` task are given below. - The input fields are drawn from the parameters in the - state’s input event, and the task’s output fields are - used to populate the state’s output event. The task’s + one or more tasks. Tasks are configured with a set of + *input fields* and a set of *output fields*. The task’s input and output fields must be a subset of the event parameters defined for the input and output events for any state that uses that task. (You may have noticed that @@ -651,11 +534,6 @@ New Policy | notes | notes_type | +-----------------------------------+-----------------------------------+ - .. container:: imageblock - - .. container:: content - - |Add input and out fields for the task| .. container:: paragraph @@ -687,12 +565,6 @@ New Policy Programmers Guide. - .. container:: imageblock - - .. container:: content - - |Add task logic the task| - .. container:: paragraph An alternative version of the same logic is available in @@ -701,40 +573,17 @@ New Policy .. container:: paragraph - The task definition is now complete so click the 'Submit' - button to save the task. The task can now be seen on the - 'Tasks' tab, and can be updated at any time by - right-clicking on the task on the 'Task' tab. Now that we + The task definition is now complete. Now that we have created our task, we can can create a policy that uses that task. .. container:: paragraph - To create a new Policy click on the 'Policies' tab. In - the 'Policies' pane, right click and select 'Create new - Policy': - - .. container:: paragraph - - Create a new Policy called ``MyFirstPolicy``. Use the - 'Generate UUID' button to create a new unique ID for the - policy, and fill in a description for the policy. Use - 'FREEFORM' as the 'Policy Flavour'. - - .. container:: paragraph - - Each policy must have at least one state. Since this is + Create a new Policy called ``MyFirstPolicy``.Each policy + must have at least one state. Since this is 'freeform' policy we can add as many states as we wish. Let’s start with one state. Add a new state called - ``BoozeAuthDecide`` to this ``MyFirstPolicy`` policy - using the 'Add new State' button after filling in the - name of our new state. - - .. container:: imageblock - - .. container:: content - - |Create a new policy| + ``BoozeAuthDecide`` to this ``MyFirstPolicy`` policy. .. container:: paragraph @@ -754,17 +603,11 @@ New Policy will automatically select ``SALE_INPUT`` as the 'Policy Trigger Event' for our policy. - .. container:: imageblock - - .. container:: content - - |Create a state| .. container:: paragraph In this case we will create a reference the pre-existing - ``MorningBoozeCheck`` task that we defined above using - the 'Add New Task' button. Select the + ``MorningBoozeCheck`` task that we defined above. Select the ``MorningBoozeCheck`` task, and use the name of the task as the 'Local Name' for the task. @@ -832,57 +675,6 @@ New Policy ``MorningBoozeCheck`` task directly into outgoing ``SALE_AUTH`` events.) - .. container:: imageblock - - .. container:: content - - |Add a Task and Output Mapping| - - .. container:: paragraph - - Click the 'Submit' button to complete the definition of - our ``MyFirstPolicy`` policy. The policy - ``MyFirstPolicy`` can now be seen in the list of policies - on the 'Policies' tab, and can be updated at any time by - right-clicking on the policy on the 'Policies' tab. - - .. container:: paragraph - - The ``MyFirstPolicyModel``, including our - ``MyFirstPolicy`` policy can now be checked for errors. - Click on the 'Model' menu and select 'Validate'. The - model should validate without any 'Warning' or 'Error' - messages. If you see any 'Error' or 'Warning' messages, - carefully read the message as a hint to find where you - might have made a mistake when defining some aspect of - your policy model. - - .. container:: imageblock - - .. container:: content - - |Validate the policy model for error using the 'Model' - > 'Validate' menu item| - - .. container:: paragraph - - Congratulations, you have now completed your first APEX - policy. The policy model containing our new policy can - now be exported from the editor and saved. Click on the - 'File' menu and select 'Download' to save the policy - model in JSON format. The exported policy model is then - available in the directory you selected, for instance - ``$APEX_HOME/examples/models/MyFirstPolicy/1/MyFirstPolicyModel_0.0.1.json``. - The exported policy can now be loaded into the APEX - Policy Engine, or can be re-loaded and edited by the APEX - Policy Editor. - - .. container:: imageblock - - .. container:: content - - |Download the completed policy model using the 'File' - > 'Download' menu item| Test The Policy --------------- @@ -961,7 +753,7 @@ CLI Editor File .. container:: paragraph An equivalent version of the ``MyFirstPolicyModel`` - policy model can again be generated using the APEX CLI + policy model can be generated using the APEX CLI editor. A sample APEX CLI script is shown below: .. container:: ulist @@ -1013,14 +805,8 @@ Extend Policy Model .. container:: paragraph - To create a new Task click on the 'Tasks' tab. In the - 'Tasks' pane, right click and select 'Create new Task': - - .. container:: paragraph - - Create a new Task called ``MorningBoozeCheckAlt1``. Use - the 'Generate UUID' button to create a new unique ID for - the task, and fill in a description for the task. Select + Create a new Task called ``MorningBoozeCheckAlt1``. Create a + new unique ID for the task, and fill in a description for the task. Use the same input and output fields that we used earlier when we defined the ``MorningBoozeCheck`` task earlier. @@ -1099,49 +885,13 @@ Extend Policy Model of the other supported languages please refer to APEX Programmers Guide. - .. container:: imageblock - - .. container:: content - - |Create a new alternative task - \`MorningBoozeCheckAlt1\`| - .. container:: paragraph - The task definition is now complete so click the 'Submit' - button to save the task. Now that we have created our + The task definition is now complete. Now that we have created our task, we can can add this task to the single pre-existing state (``BoozeAuthDecide``) in our policy. - .. container:: paragraph - To edit the ``BoozeAuthDecide`` state in our policy click - on the 'Policies' tab. In the 'Policies' pane, right - click on our ``MyFirstPolicy`` policy and select 'Edit'. - Navigate to the ``BoozeAuthDecide`` state in the 'states' - section at the bottom of the policy definition pane. - - .. container:: imageblock - - .. container:: content - - |Right click to edit a policy| - - .. container:: paragraph - - To add our new task ``MorningBoozeCheckAlt1``, scroll - down to the ``BoozeAuthDecide`` state in the 'States' - section. In the 'State Tasks' section for - ``BoozeAuthDecide`` use the 'Add new task' button. Select - our new ``MorningBoozeCheckAlt1`` task, and use the name - of the task as the 'Local Name' for the task. The - ``MorningBoozeCheckAlt1`` task can reuse the same - ``MorningBoozeCheck_Output_Direct`` 'Direct State Output - Mapping' that we used for the ``MorningBoozeCheck`` task. - (Recall that the role of the 'State Output Mapping' is to - select the output event for the state, and select the - next state to be executed. These both remain the same as - before.) .. container:: paragraph @@ -1164,18 +914,13 @@ Extend Policy Model logic using the ```JavaScript`` <https://en.wikipedia.org/wiki/JavaScript>`__ scripting language. Sample task selection logic code - is given here (|policy2_taskSelectionLogic_link|). Paste the script text into the 'Task - Selection Logic' box, and use "JAVASCRIPT" as the 'Task - Selection Logic Type / Flavour'. It is necessary to mark + is given here (|policy2_taskSelectionLogic_link|). It is necessary to mark one of the tasks as the 'Default Task' so that the task selection logic always has a fallback default option in cases where a particular task cannot be selected. In this case the ``MorningBoozeCheck`` task can be the default task. - - .. container:: imageblock - .. container:: content |State definition with 2 Tasks and Task Selection @@ -1183,13 +928,6 @@ Extend Policy Model .. container:: paragraph - When complete don’t forget to click the 'Submit' button - at the bottom of 'Policies' pane for our - ``MyFirstPolicy`` policy after updating the - ``BoozeAuthDecide`` state. - - .. container:: paragraph - Congratulations, you have now completed the second step towards your first APEX policy. The policy model containing our new policy can again be validated and @@ -1197,11 +935,9 @@ Extend Policy Model .. container:: paragraph - The exported policy model is then available in the - directory you selected, as **MyFirstPolicyModel_0.0.1.json**. - The exported policy can now be loaded into the APEX - Policy Engine, or can be re-loaded and edited by the APEX - Policy Editor. + Congratulations, you have now completed the second step + towards your first APEX policy.The policy can now be loaded into the APEX + Policy Engine. Test The Policy --------------- @@ -1289,7 +1025,7 @@ CLI Editor File .. container:: paragraph An equivalent version of the ``MyFirstPolicyModel`` - policy model can again be generated using the APEX CLI + policy model can be generated using the APEX CLI editor. A sample APEX CLI script is shown below: .. container:: ulist @@ -1303,23 +1039,6 @@ CLI Editor File 2.3.0-SNAPSHOT Last updated 2020-04-03 16:04:24 IST -.. |File > New to create a new Policy Model| image:: images/mfp/MyFirstPolicy_P1_newPolicyModel1.png -.. |Create a new Policy Model| image:: images/mfp/MyFirstPolicy_P1_newPolicyModel2.png -.. |Right click to create a new event| image:: images/mfp/MyFirstPolicy_P1_newEvent1.png -.. |Fill in the necessary information for the 'SALE_INPUT' event and click 'Submit'| image:: images/mfp/MyFirstPolicy_P1_newEvent2.png -.. |Right click to create a new Item Schema| image:: images/mfp/MyFirstPolicy_P1_newItemSchema1.png -.. |Create a new Item Schema| image:: images/mfp/MyFirstPolicy_P1_newItemSchema2.png -.. |Add new event parameters to an event| image:: images/mfp/MyFirstPolicy_P1_newEvent3.png -.. |Right click to create a new task| image:: images/mfp/MyFirstPolicy_P1_newTask1.png -.. |Add input and out fields for the task| image:: images/mfp/MyFirstPolicy_P1_newTask2.png -.. |Add task logic the task| image:: images/mfp/MyFirstPolicy_P1_newTask3.png -.. |Create a new policy| image:: images/mfp/MyFirstPolicy_P1_newPolicy1.png -.. |Create a state| image:: images/mfp/MyFirstPolicy_P1_newState1.png -.. |Add a Task and Output Mapping| image:: images/mfp/MyFirstPolicy_P1_newState2.png -.. |Validate the policy model for error using the 'Model' > 'Validate' menu item| image:: images/mfp/MyFirstPolicy_P1_validatePolicyModel.png -.. |Download the completed policy model using the 'File' > 'Download' menu item| image:: images/mfp/MyFirstPolicy_P1_exportPolicyModel1.png -.. |Create a new alternative task `MorningBoozeCheckAlt1`| image:: images/mfp/MyFirstPolicy_P2_newTask1.png -.. |Right click to edit a policy| image:: images/mfp/MyFirstPolicy_P2_editPolicy1.png .. |State definition with 2 Tasks and Task Selection Logic| image:: images/mfp/MyFirstPolicy_P2_editState1.png .. |taskLogicMvel_link| raw:: html diff --git a/docs/apex/APEX-Policy-Guide.rst b/docs/apex/APEX-Policy-Guide.rst index a9dad1c6..60468917 100644 --- a/docs/apex/APEX-Policy-Guide.rst +++ b/docs/apex/APEX-Policy-Guide.rst @@ -145,7 +145,7 @@ APEX Policy Model .. container:: paragraph The APEX policy model is shown in UML notation in the figure below. A policy model can be stored in JSON or XML - format in a file or can be held in a database. The APEX editor creates and modifies APEX policy models. APEX + format in a file or can be held in a database. The APEX Cli editor creates and modifies APEX policy models. APEX deployment deploys policy models, and a policy model is loaded into APEX engines so that the engines can run the policies in the policy model. @@ -327,7 +327,7 @@ Concept: ContextMap The set of context that is available for use by the policies of a *PolicyModel* is defined as *ContextMap* concept instances. The *PolicyModel* holds a map of all the *ContextMap* definitions. A *ContextMap* is itself a container for a group of related context items, each of which is represented by a *ContextItem* concept instance. *ContextMap* - concepts are keyed with an ``ArtifactKey`` key. A developer can use the APEX Policy Editor to create context maps for + concepts are keyed with an ``ArtifactKey`` key. A developer can use the APEX Policy Cli Editor to create context maps for their application domain. .. container:: paragraph diff --git a/docs/clamp/acm/acm-architecture.rst b/docs/clamp/acm/acm-architecture.rst index c3e7d568..82753c2e 100644 --- a/docs/clamp/acm/acm-architecture.rst +++ b/docs/clamp/acm/acm-architecture.rst @@ -311,7 +311,7 @@ deletions are not allowed on Automation Composition Types that have instances de The Instantiation component manages the Life Cycle Management of Automation Composition Instances and their Automation Composition Elements. It publishes a REST interface that is used to create Automation Composition Instances and set values for Common and Instance Specific properties. This REST interface is -public and is used by the ACM GUI. It may also be used by any other client via the public +public. It may also be used by any other client via the public REST interface. The REST interface also allows the state of Automation Composition Instances to be changed. A user can change the state of Automation Composition Instances as described in the state transition diagram shown in section 2 above. The Instantiation component issues update and state change @@ -496,6 +496,5 @@ The design and implementation of TOSCA Automation Compositions in CLAMP is descr #. :ref:`The CLAMP Automation Composition Runtime Server <clamp-runtime-acm>` #. :ref:`CLAMP Automation Composition Participants <clamp-acm-participants>` -#. :ref:`Managing Automation Compositions using The CLAMP GUI <clamp-gui-acm>` End of Document diff --git a/docs/clamp/acm/design-impl/clamp-gui-acm.rst b/docs/clamp/acm/design-impl/clamp-gui-acm.rst deleted file mode 100644 index 600c721d..00000000 --- a/docs/clamp/acm/design-impl/clamp-gui-acm.rst +++ /dev/null @@ -1,140 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _clamp-gui-acm: - -The Policy GUI for Automation Compositions -****************************************** - -.. contents:: - :depth: 4 - -.. _Introduction: - -1. Introduction -############### -The Policy GUI for Automation Compositions is designed to provide a user the ability to interact with the Automation Composition Runtime to perform several actions. The actual technical design of the Automation Composition Runtime is detailed in :ref:`clamp-runtime-acm`. 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 Automation Composition Definitions. -- Decommission existing Tosca Service Templates. -- Create new instances of Automation Compositions. -- Change the state of the Automation Compositions. -- Delete Automation Compositions. - -These functions can be carried out by accessing the Automation Composition Runtime alone but this should not be required for a typical user to access the system. That is why the Automation Composition GUI is required. The remainder of this document will be split into 2 main sections. The first section will show the overall architecture of Automation Composition 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. - - -2.1.2 Automation Composition GUI -================================ - -The current automation composition 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 automation composition project builds upon this GUI, it does not rely on these connected services. Instead, the Automation Composition GUI connects to the Automation Composition Runtime only. The Automation Composition Runtime then communicates with the database and all the Automation Composition participants (indirectly) over Kafka. - -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 Automation Composition 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 Automation Composition 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 "Automation Composition" directory under components where all of our Automation Composition 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 Automation Composition service communicates with just the Automation Composition Runtime Rest Api, so all of the communication code is within "ui-react/src/api/AutomationCompositionService.js". - -2.1.2.1 Services -"""""""""""""""" -The Automation Composition 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 Automation Composition related services are those responsible for making calls to the commissioning and instantiation endpoints in the Automation Composition Runtime. Another detail to note is that both the Automation Composition 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:`acm-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 Automation Composition 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 Automation Composition related functionality. Further description of non-acm Clamp and its' architecture can be found in :ref:`architecture-label`. The backend receives the calls from the frontend and forwards the requests to other relevant APIs. In the case of the Automation Composition project, the only Rest API that it currently requires communication with is the runtime Automation Composition API. Automation Composition adopts the same "request forwarding" method as the non-acm 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 Automation Composition rest endpoints that GUI requests are forwarded to are defined in acm-flows.xml. If an Endpoint is added to the runtime Automation Composition component, or some other component you wish the GUI to communicate with, a Camel XML exchange must be defined for it here. - -2.3 Automation Composition Runtime ----------------------------------- -This is where all of the endpoints for operations on Automation Compositions are defined thus far. Commissioning, decommissioning, automation composition creation, automation composition state change and automation composition deletion are all performed here. The component is written using the Springboot framework and all of the code is housed in the runtime-acm directory shown below: - - .. image:: ../images/gui/RuntimeAcmDirectory.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 Automation Composition 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 Kafka. Commissioning a automation composition definition writes it to the database but also triggers priming of the definitions over Kafka. The participants then receive those definitions and hold them in memory. Similarly, upon decommissioning, a message is sent over Kafka to the participants to trigger de-priming. - -Using Kafka, the Runtime can send; updates to the automation composition definitions, change the state of automation compositions, receive information about participants, receive state information about automation compositions and effectively supervise the automation compositions. 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 Automation Composition can be found in :ref:`clamp-runtime-acm`. - -2.4 Kafka ---------- -Kafka is component 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 Automation Composition Runtime and the Automation Composition Participants, both components publish and subscribe to a specific topic, over which data and updates from the participants and automation compositions are sent. The Automation Composition 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 Automation Composition participants is to communicate with different services on behalf of the Automation Composition Runtime. As there are potentially many different services that a Automation Composition 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 Automation Composition 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 Kafka. Tosca service template specifications, Automation Composition updates and state changes are shared with the participants via messages from runtime Automation Composition through the topic "POLICY-CLRUNTIME-PARTICIPANT". - -3. GUI Sample Flows -################### -The primary flows from the GUI to the backend, through Kafka 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/acm/design-impl/design-impl.rst b/docs/clamp/acm/design-impl/design-impl.rst index 3c56ff91..2b8a3fad 100644 --- a/docs/clamp/acm/design-impl/design-impl.rst +++ b/docs/clamp/acm/design-impl/design-impl.rst @@ -11,5 +11,4 @@ The sections below describe the components that handle TOSCA Automation Composit :maxdepth: 1 clamp-runtime-acm - clamp-gui-acm participants/participants diff --git a/docs/development/devtools/devtools.rst b/docs/development/devtools/devtools.rst index 682b9e6b..ecddbf52 100644 --- a/docs/development/devtools/devtools.rst +++ b/docs/development/devtools/devtools.rst @@ -65,7 +65,6 @@ and the A&AI Schema module. policy/drools-applications \ policy/xacml-pdp \ policy/distribution \ - policy/gui \ policy/clamp " ## @@ -156,7 +155,6 @@ Execution of the script above results in the following directory hierarchy in yo * ~/git/onap/policy/models * ~/git/onap/policy/api * ~/git/onap/policy/pap - * ~/git/onap/policy/gui * ~/git/onap/policy/docker * ~/git/onap/policy/drools-applications * ~/git/onap/policy/drools-pdp @@ -206,7 +204,6 @@ file in the directory *~/git/onap/policy*. <module>drools-pdp</module> <module>drools-applications</module> <module>distribution</module> - <module>gui</module> <module>clamp</module> </modules> </project> @@ -302,7 +299,6 @@ familiar with the Policy Framework components and test any local changes. .. toctree:: :maxdepth: 1 - smoke/policy-gui-acm-smoke.rst smoke/db-migrator-smoke.rst smoke/acm-participants-smoke.rst smoke/clamp-smoke.rst diff --git a/docs/development/devtools/smoke/policy-gui-acm-smoke.rst b/docs/development/devtools/smoke/policy-gui-acm-smoke.rst deleted file mode 100644 index cd600199..00000000 --- a/docs/development/devtools/smoke/policy-gui-acm-smoke.rst +++ /dev/null @@ -1,277 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _clamp-gui-acm-smoke-tests: - -CLAMP GUI Smoke Tests ---------------------- -1. Introduction -*************** -The CLAMP GUI for Automation Compositions is designed to provide a user the ability to interact -with the Automation Composition Runtime to perform several actions. - -- Commission new Tosca Service Templates. -- Editing Common Properties. -- Decommission existing Tosca Service Templates. -- Create new instances of Automation Compositions. -- Change the state of the Automation Compositions. -- Delete Automation Compositions. - -This document will serve as a guide to do smoke tests on the different components that are involved when working with the GUI and outline how they operate. It will also show a developer how to set up their environment for carrying out smoke tests on the GUI. - -2. Setup Guide -************** -This section will show the developer how to set up their environment to start testing in GUI with some instruction on how to carry out the tests. There are several prerequisites. Note that this guide is written by a Linux user - although the majority of the steps show will be exactly the same in Windows or other systems. The IDE used in the examples here is Intellij but most or all of what is described should be the same across IDEs. - -2.1 Prerequisites -================= -- Java 11 -- node -- npm -- Docker -- Maven 3 -- Git -- Refer to this guide for basic environment setup `Setting up dev environment <https://wiki.onap.org/display/DW/Setting+Up+Your+Development+Environment>`_ - -2.2 Assumptions -=============== -- You are accessing the policy repositories through gerrit -- You are using "git review". - -The following repositories are required for development in this project. These repositories should be present on your machine and you should run "mvn clean install" on all of them so that the packages are present in your .m2 repository. - -- policy/parent -- policy/common -- policy/models -- policy/clamp -- policy/docker -- policy/gui -- policy/api - -In this setup guide, we will be setting up all the components technically required for a working convenient dev environment. We will not be setting up all of the participants - we will setup only the policy participant as an example. - -2.3 Setting up the components -============================= - -2.3.3 MariaDB Setup -^^^^^^^^^^^^^^^^^^^ -We will be using Docker to run our mariadb instance. It will have a total of three databases running in it. - -- acm: the clampacm db -- cldsdb4: the clamp backend db -- policyadmin: the policy-api db - -The easiest way to do this is to perform a small alteration on an SQL script provided by the clamp backend in the file "runtime/extra/sql/bulkload/create-db.sql" - -.. code-block:: mysql - - CREATE DATABASE `cldsdb4`; - USE `cldsdb4`; - DROP USER 'clds'; - CREATE USER 'clds'; - GRANT ALL on cldsdb4.* to 'clds' identified by 'sidnnd83K' with GRANT OPTION; - CREATE DATABASE `clampacm`; - USE `clampacm`; - DROP USER 'policy'; - CREATE USER 'policy'; - GRANT ALL on clampacm.* to 'policy' identified by 'P01icY' with GRANT OPTION; - CREATE DATABASE `policyadmin`; - USE `policyadmin`; - DROP USER 'policy_user'; - CREATE USER 'policy_user'; - GRANT ALL on clampacm.* to 'policy_user' identified by 'policy_user' with GRANT OPTION; - FLUSH PRIVILEGES; - -Once this has been done, we can run the bash script provided here: "runtime/extra/bin-for-dev/start-db.sh" - -.. code-block:: bash - - ./start-db.sh - -This will setup all three databases. It will also ensure that the tables in cldsdb4 are created. The database will be exposed locally on port 3306 and will be backed by an anonymous docker volume. - -2.3.4 DMAAP Simulator -^^^^^^^^^^^^^^^^^^^^^ -For convenience, a dmaap simulator has been provided in the policy/models repository. To start the simulator, you can do the following: - -1. Navigate to /models-sim/policy-models-simulators in the policy/models repository. -2. Add a configuration file to src/test/resources with the following contents: - -.. code-block:: json - - { - "dmaapProvider":{ - "name":"DMaaP simulator", - "topicSweepSec":900 - }, - "restServers":[ - { - "name":"DMaaP simulator", - "providerClass":"org.onap.policy.models.sim.dmaap.rest.DmaapSimRestControllerV1", - "host":"localhost", - "port":3904, - "https":false - } - ] - } - -3. You can then start dmaap with: - -.. code-block:: bash - - mvn exec:java -Dexec.mainClass=org.onap.policy.models.simulators.Main -Dexec.args="src/test/resources/YOUR_CONF_FILE.json" - -At this stage the dmaap simulator should be running on your local machine on port 3904. - -2.3.5 Policy API -^^^^^^^^^^^^^^^^ -In the policy-api repo, you should fine the file "src/main/resources/etc/defaultConfig.json". This file must be altered slightly - as below with the restServerParameters and databaseProviderParameters shown. Note how the database parameters match-up with what you setup in Mariadb: - -.. code-block:: json - - { - "restServerParameters": { - "host": "0.0.0.0", - "port": 6970, - "userName": "healthcheck", - "password": "zb!XztG34", - "prometheus": true, - "https": false, - "aaf": false - }, - "databaseProviderParameters": { - "name": "PolicyProviderParameterGroup", - "implementation": "org.onap.policy.models.provider.impl.DatabasePolicyModelsProviderImpl", - "databaseDriver": "org.mariadb.jdbc.Driver", - "databaseUrl": "jdbc:mariadb://mariadb:3306/policyadmin", - "databaseUser": "policy_user", - "databasePassword": "policy_user", - "persistenceUnit": "PolicyMariaDb" - }, - } - -Next, navigate to the "/main" directory. You can then run the following command to start the policy api: - -.. code-block:: bash - - mvn exec:java -Dexec.mainClass=org.onap.policy.api.main.startstop.Main -Dexec.args=" -c ../packages/policy-api-tarball/src/main/resources/etc/defaultConfig.json" - -2.3.6 Clamp Backend -^^^^^^^^^^^^^^^^^^^ -The Clamp Backend can potentially make calls to policy pap, policy api, cds, sdc and others. For acm development purposes, we only need to connect with the acm runtime api. For convenience, there has been an emulator provided to respond to requests from Clamp to all those services that we do not care about. This emulator can be run by running the following bash script "runtime/extra/bin-for-dev/start-emulator.sh" - -.. code-block:: bash - - ./start-emulator.sh - -Once the emulator is running, we can then run the clamp backend. Before doing this, we need to make sure that all of the calls from the clamp backend are directed towards the correct places. We can do this by editing the application-noaaf.properties file: "src/main/resources/application-noaaf.properties". For development purposes and because we are running the components in a non-https way, this file will not need to be altered currently. The clamp backend can then be run with the script "runtime/extra/bin-for-dev/start-backend.sh". - -.. code-block:: bash - - ./start-backend.sh - -Once the clamp backend is running, we can start the acm runtime. - -2.3.7 Automation Composition Runtime -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -To start the acm runtime we need to go the "runtime-acm" directory in the clamp repo. There is a config file that is used, by default, for the acm runtime. That config file is here: "src/main/resources/application.yaml". For development in your local environment, it shouldn't need any adjustment and we can just run the acm runtime with: - -.. code-block:: bash - - mvn spring-boot:run - -2.3.8 Automation Composition GUI -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -At this point, all of the components required to test out the acm gui are running. We can start to make changes, and have those changes reflected in the UI for immediate feedback on our changes. But first, we must run the GUI. - -Firstly, go to the GUI repo and navigate to "gui-clamp/ui-react". To setup for development, we must install the dependencies of the GUI. We can do this using the npm package manager. In the directory, simply run: - -.. code-block:: bash - - npm install - -This will trigger installation of the required packages. The application is configured to proxy all relevant calls to the clamp backend. The application can be started with a simple: - -.. code-block:: bash - - npm start - -This uses nodes internal test dev web server to server the GUI. Once started, you can navigate to the server at "localhost:3000" and login with "admin/password". - -That completes the development setup of the environment. - -3. Running Tests -**************** -In this section, we will run through the functionalities mentioned at the start of this document is section 1. Each functionality will be tested and we will confirm that they were carried out successfully. There is a tosca service template that can be used for this test - -:download:`Tosca Service Template <tosca/tosca-for-gui-smoke-tests.yaml>` - - -3.1 Commissioning -================= -We can carry out commissioning using the GUI. To do so, from the main page, we can select "Upload Tosca to Commissioning" as shown in the image below: - -.. image:: images/gui/CommissioningUpload.png - -Clicking this will take us to a screen where we can upload a file. Select a file to upload and click on the upload button. - -.. image:: images/gui/CommissioningModal.png - -After clicking upload, you should get a message on the modal to tell you that the upload was successful. You can then look in the logs of the policy-participant to see that the message has been received from the runtime: - -.. image:: images/gui/CommissioningMessageOnParticipant.png - -This confirms that commissioning has been complete. - -3.2 Edit Common Properties -========================== -At this stage we can edit the common properties. These properties will be common to all instances of the automation composition definitions we uploaded with the tosca service template. Once an instance is created, we will not be able to alter these common properties again. We can simply click on "Edit Common Properties" in the dropdown menu and we will be taken to the modal shown below. - -.. image:: images/gui/CommonPropertiesModal.png - -The arrows to the left of the modal can be used to expand and contract the elements. If we expand one of the elements, we can see that the provider is one of the properties that we can edit. Edit this property to be "Ericsson Software Technologies". Press "Save" and then press "Commission". You should get a success message. Once you do, you can look at the full tosca service template to confirm the change in provider has been recorder. Click on "Manage Commissioned Tosca Template". Then click on "Pull Tosca Service Template". You should receive the full template on the screen. You should find your change as shown below. - -.. image:: images/gui/ViewEditedCommonProperties.png - -3.3 Create New Instances of Automation Compositions -=================================================== -Once the template is commissioned, we can start to create instances. In the dropdown, click on "Instantiation Management". In the modal, you will see an empty table, as shown. - -.. image:: images/gui/ManageInstancesModal.png - -Then we will click on "Create Instance". That takes us to a page where we can edit the properties of the instance. Not the common properties, but the instance properties. The last element has Provider set as an instance property. In the same way as we did for the common properties, change the provider to "Some Other Company" - then click save. You should get a success message if all went ok. You can then go back to the instantiation management table and you should now see an instance there. - -.. image:: images/gui/InstanceUninitialised.png - -Since the instance is uninitialised, the policies and policy types are not being deployed to the policy api. We can confirm this by looking at the policy-apis database. See the image below. - -.. image:: images/gui/PolicyTypeNotPresent.png - -3.3 Change the State of the Instance -==================================== -Now we will change the instance state to PASSIVE. This should trigger the deployment of the policy types onto the policy-api. To trigger the change of state, click on the "change" button on the instance in the instance management table. This will bring up another modal to allow you to change the state. - -.. image:: images/gui/ChangeState.png - -Pick PASSIVE and then click save. If we once again navigate to the Instance Management table, we can see that our actual state has become passive. - -.. image:: images/gui/PassiveState.png - -This should also mean that our policies and policy types should be written to the policy-api database. We can query that DB again. In the images below, we can see that the policies and the policy types have been written successfully. - -.. image:: images/gui/PolicyTypeSuccess.png - -and - -.. image:: images/gui/PolicySuccess.png - -Following the same procedure as changing the state to PASSIVE, we can then change to UNINITIALISED. This deletes the policies and policy types through the policy api and changes the overall state of the loop. we can then delete it from the Manage Instances table by clicking on Delete. - -Decommissioning -=============== -Finally, we can decommission the template. On the dropdown menu, click "Manage Commissioned Tosca Template" and then pull it. Clicking the "Delete Tosca Service Template" button will fully decommission the template. You will receive a success message if the deletion was successful. - -.. image:: images/gui/ViewEditedCommonProperties.png - -This concluded the required smoke tests - - diff --git a/docs/index.rst b/docs/index.rst index 8dcfef33..7922c08e 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -22,6 +22,5 @@ Policy Framework Architecture apex/apex distribution/distribution clamp/clamp - ui/ui system-attributes/system-attributes release-notes diff --git a/docs/installation/docker.rst b/docs/installation/docker.rst index 95957a02..b2b45ed5 100644 --- a/docs/installation/docker.rst +++ b/docs/installation/docker.rst @@ -35,7 +35,6 @@ After cloning the docker repository, the scripts and compose files are under the compose config -- all the components configurations metrics -- configuration for Prometheus server and Grafana dashboards - docker-compose.gui.yml -- compose file with gui services docker-compose.yml -- compose file with policy components services, including simulator, prometheus and grafana export-ports.sh -- script to export the http ports for all components and where the images are collected from get-versions.sh -- script to get the latest SNAPSHOT version of images based on branch (master is default) @@ -48,18 +47,12 @@ Start the containers automatically ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Assuming all the scripts are being executed from the compose folder. -To start all components without Policy GUI: +To start all components: .. code-block:: bash ./start-compose.sh -To start all components with Policy GUI: - -.. code-block:: bash - - ./start-compose.sh --gui - To start all components with Grafana dashboards and Prometheus server: .. code-block:: bash @@ -174,7 +167,7 @@ Use the script get-versions.sh .. code-block:: bash - ./start-compose.sh <component> [--grafana] [--gui] + ./start-compose.sh <component> [--grafana] The <component> input is any of the policy components available: diff --git a/docs/ui/designtime-ui/apex-policy-editor.rst b/docs/ui/designtime-ui/apex-policy-editor.rst deleted file mode 100644 index 6a5ecb95..00000000 --- a/docs/ui/designtime-ui/apex-policy-editor.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _apex-policy-editor-label: - -The Policy Framework Apex Policy Editor -####################################### - -.. contents:: - :depth: 4 - -The Apex Policy Editor allows a user to create and edit an Apex policy. It's UI is shown in the image below. - -.. image:: ../images/ApexPolicyEditorUI.png - -See the :ref:`My-First-Policy Example <apex-myFirstExample>` for an example of using the Apex policy editor. - diff --git a/docs/ui/designtime-ui/designtime-ui.rst b/docs/ui/designtime-ui/designtime-ui.rst deleted file mode 100644 index da9e6d98..00000000 --- a/docs/ui/designtime-ui/designtime-ui.rst +++ /dev/null @@ -1,17 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _designtime-ui-label: - -The Policy Framework Designtime User Interface -############################################## - -The Policy Framework Designtime UI is shown in the image below. It is, at present, a plain HTML page. - -.. image:: ../images/DesigntimeUI.png - -The pages below describe the elements of the Policy Framework Designtime UI. - -.. toctree:: - :maxdepth: 2 - - apex-policy-editor diff --git a/docs/ui/images/ApexPolicyEditorUI.png b/docs/ui/images/ApexPolicyEditorUI.png Binary files differdeleted file mode 100644 index 54c3b86f..00000000 --- a/docs/ui/images/ApexPolicyEditorUI.png +++ /dev/null diff --git a/docs/ui/images/DesigntimeUI.png b/docs/ui/images/DesigntimeUI.png Binary files differdeleted file mode 100644 index 16cacf10..00000000 --- a/docs/ui/images/DesigntimeUI.png +++ /dev/null diff --git a/docs/ui/images/MainUI.png b/docs/ui/images/MainUI.png Binary files differdeleted file mode 100644 index b9337834..00000000 --- a/docs/ui/images/MainUI.png +++ /dev/null diff --git a/docs/ui/images/RuntimeUI.png b/docs/ui/images/RuntimeUI.png Binary files differdeleted file mode 100644 index 1214f538..00000000 --- a/docs/ui/images/RuntimeUI.png +++ /dev/null diff --git a/docs/ui/images/UIArchitecture.drawio b/docs/ui/images/UIArchitecture.drawio deleted file mode 100644 index b715fb72..00000000 --- a/docs/ui/images/UIArchitecture.drawio +++ /dev/null @@ -1 +0,0 @@ -<mxfile host="Electron" modified="2022-11-07T16:58:18.463Z" agent="5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/19.0.2 Chrome/102.0.5005.63 Electron/19.0.3 Safari/537.36" etag="YSBAXs5JROLyrZci8Pr5" version="19.0.2" type="device"><diagram id="4LS_t8i9Lp9fYecXpLbe" name="Page-1">7Vtbb+I4FP41PLbyJddHetsZ7a3azmg7fVmZxIDVJEbGFJhfvw4xkNih0EISWk2lqvFx7MTf99nn+MTt4et08Zsgk/GfPKZJD4F40cM3PYSgEyL1J7cstQUBp7CMBIu1bWt4YD+pNgJtnbGYTis3Ss4TySZVY8SzjEayYiNC8Hn1tiFPqk+dkBG1DA8RSWzrvyyW48KKMPa2FV8oG43Xj/ZcPcCUrO/WQ5mOScznJRO+7eFrwbksrtLFNU1y+NbAFO3udtRu3kzQTB7S4K9Ykqeb78nkP9oPBk8/+0/s6wXSb/tCkpke8j1PWLRUtjtBUjrn4lldf/+a95TlqKrfqxxYKvS45HKNluCzLKb580APX83HTNKHCYny2rkSiLKNZZqoElSXQ55JTTgMVfmFCskU8v2EjTJllDxvMGRJcs0TLlZPwMPhEEWRsk+l4M+0VBN7A8/1VI0ekOqNLnZCBTcEKO1SnlIp8iHrBjjQnGnZbuQ432rAxbrbcYl+5GtdEK270abvLTPqQpPzFqKwRdTvswEVGZVqfjRKxIBLyVObCwpjl/p1XISej8mJuIAAVsmAoU0GdoFNBsagITKgxcUNneZgIfCNpfQ4OnbDX+LJs+mICQ2GtVPDiwI6GJ5oaoTg0q1ODtfmA7k1kwPCpvhAFh//zDL5yZnwAdzLw2auVBYp0NQiZa9Ra2fiJerhVwPlMrxRfnUbM8nFCReuOhpcGsROHQ0BGmDvROuTAwxf4SGbBlhDg9vUbHAtFvozpVsiGc9sJq55OuFTVl/ZBk3DIfV2uHQ/HABwGppc9E6a/KZo8iya7pjCF4GH5VTS1MJcxY+T/DJaJkyBL/B+5AcFTX8MNgYSPY9W5P09k6obqu1TTY9bQ9d5hQMuNP3Phtkyk0HduoeaotK3qNzNHhHx26eM5geBrlY516lOH9ezQa/zNRA0hXnQIeYtLVmugbnfNebh59e5Z2AedI352id9ZqH7Bug1O7yWQbd3eLsi2VKWxKzqK8c5JJG046ePPkuM/IgHOifM3gJaoNMs7ucpwRz3hEynLKrCXA1qTdDpgsnHvO7S1aUful1+fbPQzVaFpS4Ur0BjK8doAK1ek89ERF8bYHGfJGJE5b6o0iaunLh6ZS8iaKK2CS/V160jSz/hnjM1kI0uQqe6JfU9Y6dZDFO3QqVcpdlRaHQEjY4KHKyOVtrZDPsIOdk72cbk5IGgJCjwqqCUbMTysVz4sZVkXtw2W5WWpU7uqWAKFypOL07vQHGiLsXpGPkSx0yDHCpOx/EvQVj6qXYbgEvsWLVtCdfO509WjuuCTJgl4a1E4QfJtkCEjX08Ruv9YHn/h2p05DXmfOyMiwZ9okD8hKDjcwDdzp+QKL0QexO/x6PeTlRsoe6cA+p2qmM0YxdTKl5e/R54Aqm3klSH4BylfkCuozYamSpvI48JUo4INx5L0XHRCq0D5+aDZf/AgKRwl52Fy8a+1/f8tdbeGpNAYOS3fWj11XTocUB26AOo9AxF6nYpUgiNlBh2369SZKSRkY9aVul6mnxwlfpnKNNOUw8QGospPmIxRUbmHQWty9ROQL4m04znn/KuYjIdb8KtkjJz+z2Rau+frSwI4E0gtT7WhvYq+HBR7U8EdJoJgNDIXzrmR96DlWL2pFa0tpWCLKV8+fbt3s5Gc2Hb8jsfLGGp8FlWBVSNubXaygG6NhH9jThSisgTTdbH45TFcf6Y2s3AIfI7LrqH5sSGddG9VyO9xs6SITt58BEdUmv+CB3qjvxfUdPpFhk72fKp3FGnWgkNqTjhO72R2ZF14KVpldjJoV+uaIcrCs08NujaD9lJpl2fvPtxyjKmiNBHCg3OPt4ZTt/4bnn44UCnKTbsZMq7D3G2SFc7mXGTLlx38vlEdKni9l90ioVy+69O+PZ/</diagram></mxfile>
\ No newline at end of file diff --git a/docs/ui/images/UIArchitecture.png b/docs/ui/images/UIArchitecture.png Binary files differdeleted file mode 100644 index e60dd5a6..00000000 --- a/docs/ui/images/UIArchitecture.png +++ /dev/null diff --git a/docs/ui/runtime-ui/gui-server.rst b/docs/ui/runtime-ui/gui-server.rst deleted file mode 100644 index ffb0f9f9..00000000 --- a/docs/ui/runtime-ui/gui-server.rst +++ /dev/null @@ -1,143 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _gui-server-label: - -The Policy Framework GUI Server -############################### - -The **gui-server** microservice serves the GUI code to the browser for Policy Framework UI. In addition, it acts as -a single point of reference for the REST interfaces provided by **policy-api**, **policy-pap**, and **acm-runtime**. -It can also be used as a HTTPS gatewy for REST references into a Policy Framework deployment in a Kubernetes cluster. - -.. contents:: - :depth: 2 - -The **gui-server** is a regular microservice, and it is packaged, delivered and configured as a docker image. It is -a Spring application and therefore uses a normal Spring-style *applciation.yaml* approach to configuration. - -Definitive example configurations are available in the codebase: - -- `application_http.yaml <https://github.com/onap/policy-gui/blob/master/gui-server/src/test/resources/application_http.yaml>`_ - showing how to configure gui-server for HTTP access -- `application_https.yaml <https://github.com/onap/policy-gui/blob/master/gui-server/src/test/resources/application_https.yaml>`_ - showing how to configure gui-server for HTTPS access - -The configuration parameters are explained in the sections below - -Server Configuration --------------------- - -Configuration for HTTP access to gui-server:: - - server: - port: 2443 - ssl: - enabled: false - -Start gui-server on port 2443 and disable SSL. - -Configuration for HTTPS access to gui-server:: - - server: - port: 2443 - ssl: - enabled: true - enabled-protocols: TLSv1.2 - client-auth: want - key-store: file:./src/test/resources/helloworld-keystore.jks - key-store-password: changeit - trust-store: file:./src/test/resources/helloworld-truststore.jks - trust-store-password: changeit - -Start gui-server on port 2443 and enable SSL with the parameters specified above - -Note that other standard Spring **server** configuraiton parameters as -documented -`on the Spring website <https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html>`_ -are supported. - -Runtime Adaptation Configuration --------------------------------- - -You can configure the adaptation for **policy-api**, **policy-pap**, and **runtime-acm**. In other words, you can map -the URL that the GUI produced or that you want to use in a REST tool such as *postman* or *curl* in the **runtime-ui** -part of the aaplication.yaml file:: - - runtime-ui: - policy-api: - mapping-path: "/runtime-ui/policy-api/restservices/" - url: http://localhost:30440 - disable-ssl-validation: true - disable-ssl-hostname-check: true - policy-pap: - mapping-path: "/runtime-ui/policy-pap/restservices/" - url: http://localhost:30442 - disable-ssl-validation: true - disable-ssl-hostname-check: true - acm: - mapping-path: "/runtime-ui/acm/restservices/" - url: http://localhost:30258 - disable-ssl-validation: true - disable-ssl-hostname-check: true - -The parameters under the **policy-api**, **policy-pap**, and **acm** sections are identical. - -mapping-path and url -++++++++++++++++++++ - -The **mapping-path** is the root part of the path that will be replaced by the **url**, the **url** replaces the -**mapping-path**. - -Therefore, using the configuration above for policy-api, the following mapping occurs:: - - http://localhost:2443/runtime-ui/policy-api/restservices/policy/api/v1/healthcheck - - maps to - - http://localhost:30440/policy/api/v1/healthcheck - -and:: - - https://localhost:2443/runtime-ui/acm/restservices/onap/policy/clamp/acm/v2/commission - - maps to - - http://localhost:30258/onap/policy/clamp/acm/v2/commission - -disable-ssl-validation and disable-ssl-hostname-check -+++++++++++++++++++++++++++++++++++++++++++++++++++++ - -The **disable-ssl-validation** **disable-ssl-hostname-check** are boolean values. If the target server (policy-api, -policy-pap, or runtime-acm) is using http, these values should be set to **false**. If the target server is using -HTTPS, set the values as **true** so that the **gui-server** transfers and forwards certificates to target servers. - -Spring Boot Acuator Monitoring ------------------------------- - -The **gui-server** supports regular -`Spring Boot Actuator monitoring <https://docs.spring.io/spring-boot/docs/1.4.0.M2/reference/html/production-ready-monitoring.html>`_ -and monitoring over `prometheus <https://prometheus.io/>`_. - -The following section of the *application.yaml** file is an example of how to enable monitoring:: - - management: - endpoints: - web: - base-path: / - exposure: - include: health,metrics,prometheus - path-mapping.metrics: plain-metrics - path-mapping.prometheus: metrics - -The configuration above enables the following URLs:: - - # Health Check - http://localhost:2443/health - - # Plain Metrics - http://localhost:2443/plain-metrics - - # Prometheus Metrics - http://localhost:2443/metrics - - diff --git a/docs/ui/runtime-ui/runtime-ui.rst b/docs/ui/runtime-ui/runtime-ui.rst deleted file mode 100644 index b77607dc..00000000 --- a/docs/ui/runtime-ui/runtime-ui.rst +++ /dev/null @@ -1,17 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _runtime-ui-label: - -The Policy Framework Runtime User Interface -########################################### - -The Policy Framework Runtime UI is shown in the image below. It is, at present, a plain HTML page. - -.. image:: ../images/RuntimeUI.png - -The pages below describe the elements of the Policy Framework Runtime UI. - -.. toctree:: - :maxdepth: 2 - - gui-server diff --git a/docs/ui/ui.rst b/docs/ui/ui.rst deleted file mode 100644 index b4b2d33f..00000000 --- a/docs/ui/ui.rst +++ /dev/null @@ -1,43 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. - -.. _ui-label: - -The Policy Framework User Interfaces -#################################### - -The Policy Framework has a demonstration user interface that supports design time and runtime activities for the Policy -Framework. - -Design time activities are offline activities such as policy editing and ACM composition preparation. The design time UI -works with offline files, producing artifacts that can be consumed by the runtime Policy Framework APIs. - -Runtime operations include creating and updating policy types and policies, deploying policies as well as working with -Automation Compositions. The runtime UI works towards the REST APIs published by the Policy Framework. - -.. image:: images/UIArchitecture.png - -.. note:: - The policy framework UI is developed for use in demonstrations. It is a work in progress. As such, it does not cover - all the features and functions that are avaiable on the Policy Framework REST APIs. - -A Policy Framework installation in Kubernetes is shown in the figure above. The **policy-api**, **policy-pap** and -**acm-runtime** microservices publish REST interfaces. In a Service Mesh installation, these interfaces are exposed -over HTTP and are available inside the Service Mesh. Alternatively, the interfaces may be exposed publicly over HTTPS. - -The **gui-server** microservice serves the GUI code to the browser for Policy Framework UI. In addition, it acts as -a single point of reference for the REST interfaces provided by **policy-api**, **policy-pap**, and **acm-runtime**. -It can also be used as a HTTPS gatewy for REST references into a Policy Framework deployment in a Kubernetes cluster. - -The Policy Framework UI runs in a browser as a Web application. It has a **designtime** and a **runtime** part. - -.. image:: images/MainUI.png - -The Policy Framework main UI is shown in the image above. It is, at present, a plain HTML page. - -The pages below describe the elements of the Policy Framework UI. - -.. toctree:: - :maxdepth: 4 - - designtime-ui/designtime-ui - runtime-ui/runtime-ui |
