threefoldtecharchive / 0-robot

Distributed live cycle management system
Apache License 2.0
0 stars 0 forks source link

Add API to deal with robot connections #25

Closed rkhamis closed 6 years ago

rkhamis commented 6 years ago

Issue migrated from [https://api.github.com/repos/zero-os/0-robot/issues/111](), opened by @zaibon

Currently the self.api object that you get in the from TemplateBase class is a wrapper on top of all the robot connection configure in the config manager.

We need to change this. In reallity, a robot will receive information about remote robot only when they need it. For example, imagine there are 3 robots. one that managed the service of a specific node(r1) and another that is responsible for capacity planning and reservation (r2) and a robot that hold the service of a client (r3)

The flow is the following:

This kind of flow and exchange of robot address needs to be possible, and the api should provide some easy interface to make sure template writter can be sure to always talks to the correct robot.

rkhamis commented 6 years ago

commented by @zaibon As a first step in that direction @muhamadazmy proposed that the self.api.templates and self.api.services objects only deals with services and templates local to the robot where the service is running. Tha would force the template writer to pass by self.api.robots to talk to a remote robot. Which makes it really explicit which I think is good. Now we still don't have a solution to allow the template writer to know what robot he needs to use. (this is disscused at https://github.com/Jumpscale/0-robot/issues/86)

rkhamis commented 6 years ago

*commented by @zaibon I've been thinking about this issue and I've an idea. If we take the same robots as in the example of the first post:

sevice of r1 will nearly always need to talk to all the rN robots cause to be able to do capacity planning he needs to get information of all the nodes using all the rN robots. This sounds a lot like a cluster of 0-robot. So the idea is to add a new RobotCluster object to the API. The cluster object will expose the same interface as self.api, so allowing to search, create, delete, ... services on different robot in one call.

The constructor of the Cluster would take the instance name of all the 0-robot client it needs to use.

cluster = self.api.cluster.create('robot1,'robot2','robot3')
services = cluster.services.find(name='foo')

We could also add some helper method to schedule actions on multiple services hosted on different robot. This could be usefull for the r1 robot when he needs to get capacity detail of all the nodes in one call. Something like


tasks = cluster.schedule_action(template_uid, action_name, args)
tasks.wait()
for task in tasks:
    # do something with task.result
```*