ADDS: adding new pages

doc/FAQ.md

-# Frequently Asked Questions (FAQ)
-
-### Does the user have to develop the 3 elements of the provider (AEF, AMF and APF)?
-No, you only have to make the request to the "/onboarding" endpoint. In it you must specify a CSR for the AEF, APF and AMF and you will receive the certificates for each of them in the response.
-
-### There is one party that publishes the API and another that exposes it, what is the difference?
-There are different services, the APF, intended for publishing the APIs, and the AEF, intended so that the invoker can call it. The APF is what connects to the Capif Core Function to publish the service and when the service is up, you need the AEF service so that invokers can connect to it.
-
-
-### Before publishing an API, do you have to be registered in CAPIF?
-Yes, before publishing an API you must register using the POST /register endpoint.
-
-
-### Where is the registration done?
-Registration is done in a REST API outside of the CAPIF specification taht we have implemented.
-
-
-### Is the username and password chosen by the user when registering or is it assigned when requesting registration to CAPIF public instance?
-When you make the request to the "/endpoint" of register, you will be returned a username and a password determined by CAPIF.
-
-
-### What is a CSR?
-A CSR is a Certificate Signing Request. It is a generated data block where the certificate is planned to be installed and contains key information such as public key, organization, and location, and is used to request a certificate from a certificate authority (CA). In CAPIF, 3 CSRs are necessary to register a provider, for AEF, APF and AMF.
-
-
-### When doing the register_provider where can I find the CSRs that are generated?
-When using the "register_provider" command, if you add the "debug" option, it shows you a json with the data used to register the provider. There we can find in the body a list of 3 elements corresponding to AEF, APF and AMF. IN each of them, the apiProbPubKey field corresponds to the CSR.
-
-
-### How to use the example client (CAPIF_INVOKER_GUI)?
-First you have to make a "./run.sh host:port" indicating the address of the public CAPIF. Once the Docker containers are up, you have to do a "./terminal_to_py_netapp.sh" and then a "python main.py". At this point we will find ourselves in a console with some predefined commands to use the Client. If we press tab twice it will bring up the list of available commands.
-
-
-### Where is the CAPIF public instance located?
-The CAPIF public instance can be found at the following URLs:
-- capif.mobilesandbox.cloud:37211 (HTTPS)
-- capif.mobilesandbox.cloud:37212 (HTTP)
-
-
-### Do you have to publish 3 APIs? one for each instance?
-No, you only have to publish a single API but each component is responsible for a specific service, whether publishing or exposing.
-
-
-### Once the API is published, is it always active? Or do you have to republish it every time you want to use it?
-It is better to unsubscribe the API every time you exit the application since otherwise it could be republished and it would be double.
-
-
-### Would the same username and password be valid for different invokers?
-Yes, a user can have multiple invokers at the same time, and as such, the username and password would be the same.
-
-
-### What is the notfication destination field in the register_invoker request?
-This is the callback URL used to notify events. CAPIF has an Event service to subscribe to that notifies actions such as a subscription to an API, a change in the state of an API...
-
-
-### Is the notification_destination a required field in the register_invoker
-No, it is not mandatory, but if you do not enter it you will not receive any CAPIF events. For example, the APF may delete the API, you will not be notified that the API is no longer available.
-
-
-### What is the purpose of the "discover_service" function in the invoker client?
-The discover_service returns a json with all the services that exist exposed in CAPIF at that moment.
-
-
-### What is the purpose of the "get_security_auth" function in the invoker client?
-Sirve para pedir el token o para refrescarlo en caso de que haya caducado. You have to use that token to call the API from the invoker.
-
-
-### What is the purpose of the "register_security_context" function in the invoker client?
-To consume the API it is necessary to have a Security Context registered with the data and the authentication method.
-
-
-### Is a user the same as an exposer?
-No, a user registers in CAPIF and once done can have the role of invoker, provider or both.
-
-
-### Where can I put my endpoint?
-You have to set your endpoint when doing the "publish_service" functionality:  
-    ```
-    publish_service capif_ops/config_files/service_api_description_hello.json
-    ```
-
-In the file "service_api_description_hello.json" you configure the service that is going to be exposed and by developing one to suit you, you expose your API.
-

doc/architecture.md

-<img src="../images/logos/TeraFlowSDN_tr.png" alt="drawing" width="200"/>
-
-# **Architecture**
-
-The CAPIF architecture has three main components, Register Service, Vault and CCF, which are represented in the following image:
-
-![New Architecture](./images/architecture/New_Architecture.png)
-
-Each component is separated into different namespaces and all communications between them use Rest APIs.
-
-Apart from the communication between components, there are 2 other entities that can use them:
-
-- **Admin/superadmin**: Responsible for managing users with the Register or carrying out special operations in the CCF.
-- **Users**: They are those who want to use CAPIF, registering as a user in the Register and as Invoker or Provider in the CCF.
-
-## **Register NS**
-
-This namespace belongs to the Register service, and we find 2 components:
-
-- **Register Service**: It is responsible for managing all users who use CAPIF, in addition to providing the necessary information for its use.
-- **Register MONGO DATABASE**: It is the Register database, in it we store all the information about registered users.
-
-## **Vault NS**
-
-This namespace belongs to Vault. 
-
-This component is responsible for managing all CAPIF certificates, so other components such as the Register or the CCF communicate with it to create new certificates or request keys.
-
-## **Mon NS**
-
-This is the main namespace of CAPIF, since it contains all the CCF services in addition to other components:
-
-- **NGINX**: Responsible for acting as a reverse proxy to distribute CAPIF requests to the different services, controlling whether or not they are authorized to access them.
-- **REDIS**: Used for internal communication of services.
-- **CAPIF MONGO DATABASE**: CAPIF database, where all information related to CAPIF services such as invokers, registered providers or published services is stored.
-- **HELPER**: Service that simplifies integration with third parties such as external management portals.
-
-## **New Architecture**
-
-You can check the details of all these changes in the conversation on the [OCF wiki](https://labs.etsi.org/rep/ocf/community/-/wikis/New%20architecture).
-

doc/index.md

@@ -13,7 +13,7 @@ See the [Release Notes](https://labs.etsi.org/rep/tfs/controller/-/releases/v3.0
 The guides and walkthroughs below make some reasonable assumptions to simplify the deployment of the TFS controller, the execution of experiments and tests, and the development of new contributions.
 In particular, we assume:
 
-- A physical server or virtual machine for running the TFS controller with the following minimum specifications (check section [Configure your Machine](https://tfs.etsi.org/documentation/develop/deployment_guide/deployment_guide/#11-configure-your-machine) for additional details):
+- A physical server or virtual machine for running the TFS controller with the following minimum specifications (check section [Configure your Machine](https://tfs.etsi.org/documentation/develop/deployment_guide/#11-configure-your-machine) for additional details):
   - 4 cores / vCPUs
   - 8 GB of RAM (10 GB of RAM if you want to develop)
   - 60 GB of disk (100 GB of disk if you want to develop)
@@ -28,8 +28,8 @@ Use the Wiki menu in the right side of this page to navigate through the various
 # Guides and Walkthroughs
 The following guides and walkthroughs are provided:
 
-- [1. Deployment Guide](https://tfs.etsi.org/documentation/develop/deployment_guide/deployment_guide/)
-- [2. Development Guide](https://tfs.etsi.org/documentation/develop/development_guide/development_guide/)
+- [1. Deployment Guide](https://tfs.etsi.org/documentation/develop/deployment_guide/)
+- [2. Development Guide](https://tfs.etsi.org/documentation/develop/development_guide/)
 - [3. Run Experiments](/3.-Run-Experiments)
 - [4. Features and Bugs](/4.-Features-and-Bugs)
 - [5. Supported SBIs and Network Elements](/5.-Supported-SBIs-and-Network-Elements)

doc/releasenotes.md

-## **Release 1.0.0**
-
-### **New Features**
-
-#### Registration Flow improved
-
-- Eliminated access from CAPIF to the Register user database when onboarding is performed.
-- Isolation between CCF and Register services, interaction now is only by HTTPS requested between Register, CCF and Vault.
-- Eliminated the "role" in user creation.
-    - Now a user can be an invoker or a provider at the same time
-- Administrator User:
-    - New entity in charge of registering and managing users of the register service.
-- UUID to identify users.
-    - When you create a user, a uuid is associated with it
-    - The uuid will be contained in the token requested by the user and will be used to relate invokers and providers with users.
-- Endpoints changed and created:
-    - Administrator endpoints:
-        - /createUser: /register endpoint changed to createUser. Used to register new users.
-        - /deleteUser: /remove endpoint changed to this. Used to delete users and all the entities they had created.
-        - /login: Allows administrator to log in to obtain the necessary tokens for their requests.
-        - /refresh: Retrieve new access token token.
-        - /getUsers: Returns the list with all registered users.
-    - Customer User:
-        - /getauth now also returns the urls needed to use CAPIF, used by customer.
-- Security improvements:
-    - /login uses basic auth with administrator credentials.
-    - /getauth uses basic auth with customer user credentials.
-    - Other requests use the administrator access token obtained from login.
-
-- Current fields on user creation by administrator:
-```
-required_fields = {
-    "username": str,
-    "password": str,
-    "enterprise": str,
-    "country": str,
-    "email": str,
-    "purpose": str
-}
-
-optional_fields = {
-    "phone_number": str,
-    "company_web": str,
-    "description": str
-}
-```
-
-- Test plan has been updated with the new register flow. Please check [OCF Registration Flow]
-- Video with explanation and demonstration of new register flow [New Registration Demo]
-
-#### New OpenCAPIF architecture
-
-- New arquitecture with separated namespaces for Vault, CCF and Register components. Communication between them now are only allowed by using REST APIs.
-- New helper service inside CCF, it will simplify integration with third parties like external management portals.
-
-- Helper endpoints:
-    - /getInvokers : Get the list of invokers from CAPIF
-    - /getProviders: Get the list of providers from CAPIF
-    - /getServices : Get the list of services published in CAPIF
-    - /getSecurityContext : Get the list of security contexts from CAPIF
-    - /getEvents : Get the list of events subscriptions from CAPIF
-    - /deleteEntities: Removes all entities registered by a user from the register
-
-- Security in the helper
-    - To make requests to the helper you will need a superadmin certificate and password.
-
-#### Events API Upgrade
-
-- The event management at CCF is improved, EventNotification include Event Details with required information.
-- Events updated:
-    - SERVICE_API_AVAILABLE and SERVICE_API_UNAVAILABLE with apiIds
-    - SERVICE_API_UPDATE with serviceAPIDescriptions
-    - API_INVOKER_ONBOARDED, API_INVOKER_UPDATED, API_INVOKER_OFFBOARDED with apiInvokerIds.
-- Events Included:
-    - SERVICE_API_INVOCATION_SUCCESS and SERVICE_API_INVOCATION_FAILURE with invocationLogs
-- Test plan include 7 new tests in order to check new events implemented and scenarios of each notification implemented, with a complete check of Event Notification.
-- Test plan documentation includes the new event tests [OCF Event test plan documentation].
-
-#### Inital implementation of CI/CD
-
-- The inital implementation of CI/CD on gitlab was performed.
-- Detailed information in the [CICD Wiki].
-- Implement initial CI/CD:
-    - Description of the CI process.
-        - In CI phase, created design, jobs and security checks when a branch is pushed.
-        - The CI has jobs as:
-            - Linting code, unit test (if needed),
-            - Build and push artifacts (images) in Git OCI register
-            - Security checks,
-            - SCA, CVS, SAST
-            - The vulnerabilities are exposed in Merge Request panel to be solved.
-    - Description of the CD process:
-        - Defined the environments to OCF.
-            - Production env.
-            - Pre-production env.
-            - Validation env.
-            - Dev-1, dev-2… envs (ephemeral)
-        - Defined the naming convention to OCF releases
-            - Tag in prod: v0.0.1-release
-            - Tag non-prod: v0.0.1-rc
-            - Other tags: v0.0.1-test, v0.0.1-smt
-        - Defined the jobs of CD
-            - CD ensures the deployment in multiple envs. Therefore, the CD pipeline has deploy-ocf, delete-ocf (if needed) jobs
-    - ETSI HIVE Labs:
-        - Designed, created and the Kuberntes OCF cluster is running to support OCFs deployments.
-        - Iterating with ETSI HIVE’s support to solve computing issues.
-            - CPU compatibilities with OCF services (MongoDB): Fixed
-
-
-### **Documentation**
-
-#### Improvements on documentation
-
-- Documentation stored in [OCF Documentation Repository]
-- Continuous Integration included at repository for web documentation:
-    - Develop version of documentation is automatically generated on each merge to develop branch.
-    - Tagged version from main create documentation with related tag as version.
-
-### **Technical Debt Solved**
-
-#### Improved Testing with Robot in order to cover
-
-- Support of new Register flows.
-- Allow different URLs for register, ccf and vault services.
-- New Variables included to manage new architecture under test.
-- Mock server developed to add the functionality of write tests involving notification from Service Under Test.
-- Docker image improved generation and libraries upgraded to Robot Framework 7.
-
-#### Improved security on DB
-
-- Credentials requested to access mongo databases.
-- Credentials requested also by mongo-express.
-
-#### Scripts upgraded
-
-- Docker compose version 2 used on them.
-- New cleaning script developed.
-- Scripts upgraded:
-    - **check_services_are_running.sh**: Checks if all essential services (Vault, CCF and Register) are running.
-    - **clean_capif_docker_services.sh**: Shutdowns and removes all services essential services.
-    - **clean_capif_temporary_files.sh**: Removes temporaly files from local repository. 
-    - **run.sh**: Launch Essential services locally using docker compose, also monitoring can be launched.
-    - **run_capif_tests.sh**: Launch Robot Framwork Tests.
-    - **show_logs.sh**: Show locally logs of Services running.
-    - **run_mock_server.sh**: Launch mock server locally on all interfaces. This axiliary server is only used by tagged mockserver tests on Robot Framework.
-    - **clean_mock_server.sh**: Remove mock server local deployment.
-    - **deploy.sh**: This script simplify the way to download capif repository.
-
-#### Codebase Improvements
-
-- Documentation is now on splitted repository [OCF Documentation Repository]
-- Test plan was moved to [OCF Documentation Repository]
-- Obsolote data is removed.
-- Repository Reorganization: Enhanced structure and maintainability with a better directory layout and clearer module separation.
-- Code Quality Enhancements: Refactored code and fixed known issues
-
-#### Migration to GUNICORN
-
-- Include production server on each microservice: Release 0 use Flask developer server, now we use GUNICORN.
-
----
-
-## **Release 0.0**
-
-The APIs included in Release 0.0 are:
-
-- JWT Authentication APIs
-- CAPIF Invoker Management API
-- CAPIF Publish API
-- CAPIF Discover API
-- CAPIF Security API
-- CAPIF Events API
-- CAPIF Provider Management API
-
-This Release also includes a Robot Test Suite for all those services and a Postman Test Suite for simple testing.
-
-
-[OCF Documentation Repository]: https://labs.etsi.org/rep/ocf/documentation "OCF Documentation Repository"
-[OCF Event test plan documentation]: https://ocf.etsi.org/documentation/latest/testing/testplan/api_events_service/ "OCF Event test plan documentation"
-[OCF Registration Flow]: https://ocf.etsi.org/documentation/latest/testing/testplan/common_operations/ "OCF Registration Flow"
-[New Registration Demo]: https://www.youtube.com/watch?v=sn-tN6eRvv8 "New Registration Demo"
-[CICD Wiki]: [https://](https://labs.etsi.org/rep/ocf/community/-/wikis/OCF-CICD)   "CI/CD Wiki"
-[Upgrade Release 17 to 18 Wiki]: [https://](https://labs.etsi.org/rep/ocf/community/-/wikis/?¿?¿?¿?¿?)   "Upgrade Release 17 to 18 Wiki"

mkdocs.yml

@@ -77,5 +77,11 @@ extra:
 # Page tree
 nav:
   - 0. Home : ./index.md
-  - 1. Deployment Guide: ./deployment_guide/deployment_guide.md
-  - 2. Development Guide: ./development_guide/development_guide.md
+  - 1. Deployment Guide: ./deployment_guide.md
+  - 2. Development Guide: ./development_guide.md
+  - 3. Run Experiments: ./run_experiments.md
+  - 4. Feature and bugs: ./features_and_bugs.md
+  - 5. Supported SBIs and Network Elements: ./supported_sbis_and_network_elements.md
+  - 6. Supported NBIs: ./supported_nbis.md
+  - 7. Supported Service Handlers: ./supported_service_handlers.md
+  - 8. Troubleshooting: ./troubleshooting.md