integration of reva and ocis

[butonic]

At ownCloud we want to integrate and orchestrate the different reva handlers as micro services. Unfortunately, the business logic inside the handlers is not reusable because they live in the internal namespace.

Another way of integrating reva and micro would be to start reva with a configuration generated by micro, eg. for the host and port names of the relevant services. However, this is currently not possible for multiple reasons:

1. reva has no way of injecting the micro.Server() into the rgrpc.NewServer(). reva always creates the underlying grpc service.
2. Same for micro. It also wants to stay in control of the grpc server because it also wants to add tracing etc.
3. For the same reason micro has no way of fetching host and port information after initializing a service that we could use to create a configuration for reva that would allows us to treat reva as a microservice.

Yet another option is to start reva as a binary, limit it to a single service and tie it to a local/unix socket. We could implement the micro service as an adapter that makes calls to the local socket then. But this is kind of the worst integration, IMO.

An option I want to avoid is forking the business logic an putting it into individual micro services. It would make it easier to get everything started, it would tie us to micro and it would allow reva and ocis to diverge ... which is the opposite of what we set out to do.

A possible solution would be to teach reva how to register handler with a micro.Server().

The core problem we see is that go-micro is trying to solve the same problems reva as a micro services framework tries to solve. In my opinion the business logic in the reva handlers is what matters. Interested parties should be able to integrate them in new ways. In the current state reva is hard to extend. Anyone wanting to integrate with reva has to submit a PR against reva.

If he does not want to do that for whatever reason the only option he has is to fall back to the CS3 api.

[butonic]

Furthermore, I was under the impression that we and every other participating party want to follow the same way of building a single binary. At the conference we started with gokit ... and moved to go-micro over the weeks. But go-micro vs gokit does not make a difference with regard how to reuse reva. While reva is trying to avoid vendor lock in ... it has become a lock in itself.

I think it can and should still be the reference implementation, but to be open and foster collaboration the handlers should be open and reusable as much as possible.

[butonic]

Current line of thinking:

1. run a reva instance per service
2. tie it to a unix socket (can be overriden via env var)
3. implement an adapter the translates the go-micro generated api to the vanilla protobuf api

This approach adds another call to every involved service. And it still duplicates the tracing functionality because the reva framework has its own way of adding tracing and logging.

To be honest we have spent a lot of time on reva as a framework and configuring the services so they work together. @labkode you should either bite the bullet and use go-micro as well so we can move on with the business logic or at least open up the handlers so we can do service registry, orchestration tracing and what not with go-micro. Trying to marry the two frameworks does not make sense.

[labkode]

I think Reva should be considered as a dependency of OCIS like MySQL or Redis would. You just do not import the MySQL or Redis libraries and run MySQL or Redis server inside your software.

You do not adapt MySQL to meet ownCloud requirements because you use framework X, but adapt OCIS to work against MySQL by using a set of APIS. Idem for Reva with the CS3APIs.

As presented various times Reva can be easily extended by implementing the necessary interfaces as the other projects in the community do.

Anyway, this requires a more high level overview and direction of the OCIS product from the ownCloud company perspective.

[felixboehm]

@labkode Why are handlers moved to internal namespace? --> This is limiting reusability a lot, while I see no advantages at all.

And as far as I understand, you want us to use REVA in this specific way, instead of using frameworks like "micro"?