5g-era / middleware Goto Github PK

Is your feature request related to a problem? Please describe.
Help the user to automatically load into the middleware database the robot ROS information.

Describe the solution you'd like
The bash script will be run in the robot Linux system and partially complete the onboarding file for the robot. The information completed will be ROS info and basic OS and system architecture.

Describe alternatives you've considered
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like

The user may want to run a netApp from dashboard for fast testing.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
N/A

Additional context
Add any other context or screenshots about the feature request here.

Probably not a must have feature. Consider in the future if required.

Describe the bug
A clear and concise description of what the bug is.
The service model inside the actionModel input parameter to the function has null value.

To Reproduce
Steps to reproduce the behavior i.e.:
branch: AL/SimplifiedResourceDeployment (based on Main)

0. Launch docker-compose
1. Go to postman
2. endpoint: http://localhost:5047/task/plan?dryRun=true)
3. body:

{
"RobotId": "967eb8c1-3078-4210-8312-af1f8187d2c8",
"resourceReusage": false,
"ReplanActionPlannerLocked": false,
"TaskId": "a9fdafe6-9b90-48bc-a286-3f08ed0a78aa",
"TaskDescription": "",
"ContextKnown": true,
"Questions":
[
{
"relations": [
{
"initiatesFrom": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"type": "string",
"name": "string"
},
"relationName": "string",
"relationAttributes": [
{
"key": "string",
"value": "string"
}
],
"pointsTo": {
"id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"type": "string",
"name": "streing"
}
}
],
"Id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
"Question": "string",
"IsSingleAnswer": true,
"Answer": [
{
"key": "string",
"value": "string"
}
]
}
]
}

4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context

I think this error may be caused for not addapting the code to the lastest fix of object mapping between containers.

Is your feature request related to a problem? Please describe.
N/A

Describe the solution you'd like
Showcase of the new netApp with middleware and some real robots: Aisoy KiK
Usage of image recognition netApp.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
The ways of how the Middleware will communicate with the testbed. For this, we have to know the following:

• What are the capabilities of the testbed and OSM as Slice Orchestrator?
• What exactly is a Slice?
• How the Middleware has to request a new slice?
• Does create a new slice change the IP addresses of the Middleware?

The desired way of communicating from the Robot to the slice request is the following:
ROS -> Middleware (including AC/AS) -> Orchestrator (OSM)-> slice-manager (testbed) ->websocket (NetApp)

Describe the bug
In the dashboardService class, the function GetActionSequenceAsync(), the line:
var tasks = await _taskRepository.GetAllAsync();

gets a list of tasks objects which actionSequence is always null.

To Reproduce
Steps to reproduce the behavior i.e.:
Branch: AL/EndpointsDashboard_Middleware

1. Launch redis interface
2. Run: "/api/v1/actionSequence"
3. Put stop point in code in line --> var tasks = await _taskRepository.GetAllAsync();
4. See the actionSequence attribute of all obkects in result

Expected behavior
The tasks should have loaded their action Sequence.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
In Redis there are some tasks with no actions, but NOT ALL of them :)
This issue was discovered in the QA of Dasboard

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
The feedback in action server netApp instance goes up and down very fast.

To Reproduce
Steps to reproduce the behavior i.e.:
Run the BUT image recognition netApp deployed by middleware with AC/AS and look at the output of AS in console.

Expected behavior
The feedback is either up or down and does not change every second.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
This was first reported by RobotNik in the septeber 2022 integration.

Describe the solution you'd like
The new NetApp design requires the endpoint for planning in Middleware to pass the ROS topics and topics types. This is necessary for querying suitable NetApps based on the required input topics. This interface to the NetApp must be loaded in the Redis DB index of netApp as extra information that must be included.
Additionally, the AC/AS needs to be expanded to include in the ROS goal the topics of the robot. AS will be integrated with the NetApp client.

BB 27.02.2023 - based on the conversation with @Kapim the following adjustments to the Middleware must be made:
During the deployment, the Middleware has to assign a randomised port in the specified range that will not conflict with the existing NetApps (port range 49152-65535). On top of this, the range of ports (which does not have to be sequential) has to be assigned for the NetApp to utilise the Gstreamer.

This idea has changed during the development of the Relay and Inter-Relay NetApps.

Is your feature request related to a problem? Please describe.
Deploying resources using the hardcoded GUID is inefficient and is not scalable. Propose how the robot can request the specific resource to be deployed.
In the future, the request can include the semantic specification of the task that will be planned for the robot.

As it turned out, the communication between the Middleware services is not optimal from the development perspective and cannot be easily managed. Furthermore, it creates a lot of confusion, so it will be better to code the API clients ourselves. This will give us more flexibility and allow us to efficiently manage the potential failures and behaviour of the services.

At the moment when the robot finishes work with the Middleware, it can continue to work in the Middleware because token is still active.

After the robot finishes the work in the Middleware, it should be logged out, and the token should become invalid.

Develop the Cloud Storage API Charmed Operator so later it can be managed by Juju during the deployment.

Is your feature request related to a problem? Please describe.
Research about available robot task ontologies and if not create one. This is linked to issue #79

This is neccesary for naming tasks.

Research Description
A clear and concise description of the subject to be researched.
Robot task names need to be descriptive and not Guids.

Is the research related to an already known bug or feature?
Provide the tag for the bug or feture. #79

Research related branch
Robotics ontology

Is the research directly related to an existing system component?
RedisInterface API, Orchestrator API, ML Tool, AWS, etc

Research summary
Describe your findings

Pros
List the potential benefits

Cons
List the potential drawbacks

References
List the used sources

Is your feature request related to a problem? Please describe.
This documentation will include the step-by-step flowchart of replanning resources for resource planner to complete a task_1.

Describe the solution you'd like
I am currently working on it.

Middleware lacks the full architecture documentation. To enable getting familiar with the Middleware's architecture quicker, prepare the document that will present the following things:

• Possible Middleware deployment scenario
• How the Middleware services contact each other
• Management process (Onboarding) of the NetApps (reference netApp onboarding)
• Diagrams showcasing the Architecture (Including CentralApi)

Describe the bug
For ROS developer it is very difficult to remember what the task GUID is about by looking at the GUID. It should be a task name and will be descriptive.

It must be integrated with the middleware correctly and with the Redis database.

Additional context
Reported on RobotNik september intgration 2022.

The testing templates should be defined and distributed across the team. In addition, the testing scenarios should be prepared for the testing of the Issues and QA.

The testing templates will be used not only by the QA but also by the team itself to initially test the produced features.

Describe the bug
At the moment, there is no central logging in place and the events through the system cannot be viewed other than locally.
Start back the Elasticsearch logging system or find a way to create a new solution

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Detailed Flow-chart carrying Work-Flow Analysis

Describe the solution you'd like
Step-by-step method
5 phases
Initial phase
Planning phase
Deployment phase
Life-cycle Management Phase
Completion phase

Additional context
More steps can be added if needed
https://docs.google.com/document/d/1NV1a4G7yjMvdghLHSJKVnhOQD8SsjZhb2cd1RVTFlP0/edit#

Add functionality to automatically update the json spec of the OpenApi to match the gateway specification

Is your feature request related to a problem? Please describe.
5G slicing support for middleware in terms of modeling in redis, in middleware and how planner and dedicated 5g policies apply.

Additional context
Add any other context or screenshots about the feature request here.
This is required for the next integration meeting in 2023. Get input from networking and 5g partners to model this.

Is your feature request related to a problem? Please describe.
Implement presented features in the google docs:

https://docs.google.com/document/d/1izXGbP7aVGNBEQuAwO4XehJlaUVHfrMFfML3-pQjlWY/edit#

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Trying to use the dashboard endpoints from the postman.

To Reproduce
Steps to reproduce the behavior i.e.:

1. Go to 'postman
2. https://localhost:5047/Data/Dashboard/Robots
3. Body:
   {
   "PageNumber": 1,
   "PageSize": 5
   }
4. See error

Expected behavior
Get the data required.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Are we missing something in the gateway? I think there is some feature missing to connect the new dashboard endpoints

The Redis Cluster will allow the Middleware to decrease the time it takes the Middleware to fetch the data.
The cluster replica should be placed in each Middleware location. It will be especially important with the Middleware working as a distributed system as part of #68.

On top of this, the Redis Cluster should be able to easily facilitate the new replica that could be deployed automatically with the Middleware. More thought will have to be placed into this, as this will be a critical point for Middleware in terms of accessing the planning resources.

Is your feature request related to a problem? Please describe.
Cartographer is a system that provides real-time simultaneous localization and mapping (SLAM) in 2D and 3D.
https://github.com/cartographer-project/cartographer
https://google-cartographer-ros.readthedocs.io/en/latest/

OctoMap is a offline 3D representation for 3D environment
https://github.com/OctoMap/octomap
http://wiki.ros.org/octomap

Integration of Cartographer and OctoMap can help us to reuse the historical information of the environment and speed up the SLAM process

Describe the solution you'd like
Save the historical (offline) map in the OctoMap_server hosted in the Cloud
Integrating the 3D map generated online by cartographer with the pre-existing offline map
Plan based on both online and offline map

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Use online map from cartographer only

Additional context
Add any other context or screenshots about the feature request here.
https://www.youtube.com/watch?v=7iM2ynZEuf0
https://www.youtube.com/watch?v=34n1tF5OtQU

Is your feature request related to a problem? Please describe.

For every new netApp there should be created a new taskId with the redis complete graph representation (task, action, instance). This taskId is then given back to the netApp redis data index stored. It can be later retreived with the netApp search bar in the dashboard.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
There is no data for the dashboard about the status of edge/cloud defined in Redis or how to capture it.

Describe the solution you'd like
For the multiple Middleware instances deployed in the topology, there is a necessity for each of the Middleware to report the status of the platform they are running on (edge/cloud). The status should be online, CPU usage, disk space etc. This is necessary for the dashboard and resource planner.
On top of this, the ActionServer/Client in the Robot could query for all the possible locations of the Middleware through the Central TopologyAPI. The Robot could decide by itself which Middleware location suits it the best.

Is your feature request related to a problem? Please describe.
At the moment, Middleware supports only stateless NetApps. When NetApp provides functionality like image recognition, there is no problem. However, when NetApp has to provide mapping functionality, it has to store the map somewhere.

Middleware will have to provide a way to save the state of the NetApp. It can either be a Persistent Volume Claim in Kubernetes, AWS S3 or OpenStack binary storage.

Feature goes into the planning phase.
The current goal is to provide the NetApp with the persistence layer that will allow saving and reading data directly in the Pod. The Pod will access the data using Volume Claims.

The main ideas behind the implementation;

• Each piece of persisted data has its unique identifier
• Robot can request providing the specific dataset to the NetApp by passing the ID to the Middleware
• When the robot does not request a specific data ID, Middleware will provide the robot with a new data ID
• Data will be stored in AWS S3 (in the future, an alternative source will be provided)
• Middleware will fetch the data from S3 using init-container functionality in K8s
• Middleware will upload the data back to S3 during the termination of the container using preStop hooks
• Middleware will connect volume with data to the NetApp and set the Env variables pointing to the data directory
• Middleware will increase terminationGracePeriodSeconds to ensure that all the files will be uploaded to S3
• The init-container will need to be a separate container (consider Golang for development, it's easy to wait for SIGKILL signal)

Is your feature request related to a problem? Please describe.
-Model the robot tasks to:
-Not allow replan as per nature of the task may require sure.
-Allow only partial replanning.
-Allow only complete replanning

Describe the solution you'd like
N/A

Describe alternatives you've considered
N/A

Additional context
Low priority

Is your feature request related to a problem? Please describe.
When working in a real environment, the Robot cannot dynamically change the topics it publishes. Instead, it has a static pool of topics for different purposes. When working With Middleware, it should be known, either by Middleware or specified by the Robot, which topics should be used for the specific task. For example, the camera image has to be used for object recognition.

The Robot's input on which topics the NetApps should utilise should be prioritised over searching the robot configuration when the task is requested.

Is your feature request related to a problem? Please describe.
Research OpenRMF technology

Describe the solution you'd like
A clear and concise description of what you want to happen.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.

Is your feature request related to a problem? Please describe.
The dashboard requires different permissions based on roles to delete redis relationships, modify policies etc.

Describe the solution you'd like
Admin role and simple user role needed. Also, the robot is below the system admin. Show if a policy set by system admin collides with a robot reject, the policy from system admin prevails.

Modify registration and login endpoints accordingly.

The inconvenient part of working and managing the 5G-ERA Middleware development is constantly switching between Redmine for the issue tracking and Github for the rest of the software development lifecycle.

We will use the built-in GitHub Issues and Projects feature to solve this problem.

GitHub Issues allows us to monitor the state of the project and tightly integrate it with the pull requests, and present the progress on the Kanban board. In addition, the milestones planning will give us a better idea of what has to be done for each software release.

Describe the bug
In BED-Workshop, Step 3: Performance Image Functionality

1. ROS-Simulation, launch the telenot pod is not working properly
2. Measure performance of ROS2 system and topologies is also not working properly.

##Needs urgent work

Describe the bug
The Middleware lacks testing coverage. The seemingly simple changes can break multiple things across the system. Improve the testing through the system to provide a better developer experience and confidence when working with code.

Describe the solution you'd like
The middleware should be able to allow the robot to use the cloud/edge switch over if a proactive replan is triggered. Switchover is also required for 5G slicing management and usage. Check what are the implications from the planning perspective.

Additional context
Add any other context or screenshots about the feature request here.

Describe the bug
Middleware lacks clear contribution guidelines and a roadmap.

An increased focus on the documentation has to be put in.

Describe the bug
If you destroy the middleware namepace deployment files but not the services are not destroyed, the orchestrator do not deploy the other pods

To Reproduce

1. Deploy the middleware orchestrator service and deployment
2. Destroy the all the middleware deployments
3. Redploy the orchestrator deployment file

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

A clear and concise description of what the bug is.
Currently, the stale heartbeats are not removed from the list of active tasks. Instead, it causes the task update jobs to process the completed tasks.
To fix this, prepare the job traversing through the NetApp heartbeat, and the deployed action plans to identify the stale objects.
The stale objects should be removed after a specific time of inactivity.

Describe the bug
Stage 3 does not work. Container with webots simulation is working but not with ROS.
The problem seems to be the k8 is deploying an updated version of webots that is not compatible with the ROS Simulation. Fix should be to change tag lastest from deployment.yaml to the specific version working in march 2022.

To Reproduce
Steps to reproduce the behavior i.e.:
Follow

Expected behavior
ROS Webots simulation runs fine

Screenshots
N/A

Additional context
N/A

Is your feature request related to a problem? Please describe.
For complex query, we may need to adjust the baseModel to accomodate parameters to the lua query system. This is low priority.

Describe the solution you'd like
N/A

Describe alternatives you've considered
N/A

Additional context
No real usecase identified yet.

At the moment, the Middleware is tightly bound to AWS Cloud. Therefore, the Middleware has to be cloud-provider independent and allowed not to use at all.

Middleware could support not only AWS but also could support Azure or GCP. But most important, Middleware should allow for the deployment without the need to be bound to any cloud provider. It should utilise the Kubernetes-native solutions for Secret's Management, logging and Middleware container image storage.

What needs to be done:

• - allow configuration without the AWS Secrets Manager
• - Independent public 5G-ERA image registry
• - Orchestrator has to pass configured Env variables to other containers
• - Azure/GCP/OpenStack secrets management (optional)

The dashboard endpoints will cover extracting specific data from the Middleware APIs.

1. The endpoint has to present information about the cloud and the edges they're currently operating in the system.
   The endpoint has to return the following properties:

   Last Time the location updated
   Name of the Edge/Cloud
   Is it online
   Is it busy
   Number of containers it runs
   status of a cloud/edge

2. The endpoint has to present information about the robots and the tasks that they're currently executing.
   The endpoint has to return the following properties:

• Robot name/id
• Task name/id
• Date and Time it started
• Status of a task
• The date and Time finished
• status of a robot

Dashboard integration proposal document

Git branch for feature: Redis interface dashboard/157

Describe the bug
When the netApp is deployed Middleware is confused about the state of the NetApp, it constantly changes from Active to Down.

To Reproduce
Steps to reproduce the behavior i.e.:

1. Deply the NetApp
2. Watch statuses from ActionServer on the robot
3. Statuses are changing from Active to Down

Expected behavior
Middleware shows static and actual status of the NetApp

Describe the bug
Performance degradation over redis when query for an specific stored plan.

To Reproduce
Steps to reproduce the behavior i.e.:

1. Use replanning endpoint to get the lastest plan provided to an specific robot.

Expected behavior
Nice performance over query for plan stored in redis. There is a need to improve the query.

Screenshots
N/A

Additional context
Add any other context about the problem here.

Develop the Charmed Operator for Redis so it can be easier managed by Juju during deployment.

As the Middleware grows, it has to support multiple users. Robots and administrators. Each user will have different permissions on which he will be able to work within a system.
Things to consider:

• moving to a different identity provider to better support the user claims and roles
• Identify ways of signing out users after they finish the work with the Middleware and invalidate the JWT tokens